kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/28/2010 2:20 PM, Dick Hollenbeck wrote:
> On 09/28/2010 12:09 PM, Wayne Stambaugh wrote:
>> On 9/28/2010 12:43 PM, Dick Hollenbeck wrote:
>>   
>>>     
>>>> I probably would never personally use shared_ptr because in my mind it
>>>> is slightly beyond what an average C++ programmer uses on a day to day
>>>> basis, and it obscures the clear notion of "object ownership".
>>>>
>>>> I have never (I am old, this is a long long time, and countless lines of
>>>> code) been in a position where I could not assign object ownership
>>>> clearly to one container over another.  If ever this became obscure, I
>>>> would probably backup and take another look.
>>>>
>>>> Object ownership is something to keep one's eye on.
>>>>
>>>>
>>>> Dick
>>>>   
>>>>       
>>>
>>> This was an opinion I expressed about shared_ptr, which hopes to relieve
>>> me of having to think clearly about object ownership.  I have no problem
>>> thinking about object ownership, so I have this opinion about
>>> shared_ptr.  IMO, shared_ptr is a solution without a sufficiently large
>>> problem.  Managing object ownership is not a significantly difficult
>>> design responsibility, and has always been part of C/C++ programming.
>>>
>>>
>>> I don't feel the same way about auto_ptr, which is *one* reasonable way
>>> to deal with heap allocated objects in the face of exceptions.  If no
>>> exceptions can occur, auto_ptr is not useful.  If exceptions, then this
>>> is a sufficiently large problem to justify auto_ptr, but it is not the
>>> only solution.  auto_ptr is one reasonable and simple solution.  Another
>>> one that can also work is to simply stash the pointer soon after heap
>>> instantiation into the object's eventual owner, and then the problem
>>> gets moved to the owner.  When the owner's destructor gets called, it
>>> deletes the newly instantiated owned object.  Either solution is better
>>> than simply leaving the pointer on the heap and not copying it to the
>>> owner and not using auto_ptr, and then experiencing a thrown exception
>>> in that function that leaves the object exposed to a memory leak.
>>>
>>>
>>> Just wanted to clarify: 
>>>
>>>   auto_ptr: good sometimes,
>>>      if you cannot copy pointer to the eventual owner soon enough,
>>>
>>>   shared_ptr: not worth the cost.
>>>     
>> Dick,
>>
>> I have already changed my code to not use shared_ptr.  It isn't quite as clean,
>> but it is close.  I just have a bit more validation to do before I commit the
>> changes.  This also means that I will not be changing the included boost headers.
>>
>> Wayne
>>   
> 
> 
> Way cool.   Looking forward to self documenting library files dude.

Me too.  I wish I had more time to knock this quickly but I'm afraid it will be
slow incremental implementation that will take me a few months.  I know it is
the corner stone for a lot of the other improvements we would like to make to
EESchema but I have a limited amount of time I can commit to the project.
Since the discussion has died down on the library structure, I will do my best
put together an overview and submit the preliminary file format document by the
end of the weekend.

Wayne

> 
> WRT my last message, mostly I was trying to give auto_ptr a green light
> when needed, and to narrow the expression of my concern to shared_ptr. 
> But I had also previously said I would yield to your considerable
> experience and judgment.
> 
> 
> Dick
> 
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>