kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

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