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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
