kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/13/2010 11:29 AM, Dick Hollenbeck wrote:
> On 09/13/2010 09:47 AM, Wayne Stambaugh wrote:
>> Is there a set criteria for the Boost include files that are part of Kicad?
>> The reason I ask is I wanted to use boost::shared_ptr to solve an issue I was
>> having while working on the new component library code an found that there are
>> some missing header files that prevent using boost::shared_ptr.  This was
>> easily solved by adding the missing files to the Kicad source.  I had just
>> assumed (mistake on my part) that we were using the full Boost header install.
>>  Obviously that is not the case.  I just wanted to make sure there is no
>> technical (or philosophical) reason not to include the additional headers
>> required to use boost::shared_ptr before I make any commits.  Maybe we should
>> just include all of the Boost headers rather than a subset even though it would
>> add quite a bit of code to the Kicad source.  Anyone else have any thoughts on
>> this?
>>
>> Wayne
>>   
> 
> 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.

I'ld rather not get off topic but I think I may have found one as I have
wrestled with a problem for several weeks and with at least two false starts.
The problem stems from the current design of CMP_LIBRARY and it's ownership of
LIB_ALIAS and LIB_COMPONENT objects and the interdependency between them.  My
original attempt was to make CMP_LIBRARY own LIB_COMPONENT objects and
LIB_COMPONENT own it's associated LIB_ALIAS objects.  This made both searching,
indexing, and modifying the library and editing components much more complex
than the current design so I abandoned it as one of my goals was to simplify
the current design.  I finally decided that CMP_LIBRARY should only own
LIB_ALIAS objects.  I created an addition LIB_ALIAS object for the root
LIB_COMPONENT(more on this below).  I added a boost::shared_ptr for the
LIB_COMPONENT pointer in each LIB_ALIAS that references it and I added code in
the LIB_ALIAS destructor to keep the LIB_COMPONENT name up to date.  When the
last LIB_ALIAS that references the shared LIB_COMPONENT is deleted, the
LIB_COMPONENT object goes out of scope and is automatically deleted.  This
makes sense to me as LIB_ALIAS objects no meaning without an associated
LIB_COMPONENT.  It also made the code for updating the CMP_LIBRARY object very
simple.  Access to the underlying LIB_COMPONENT object is always done though
LIB_ALIAS::GetComponent().  I know your thinking why create an alias with the
same name as the component?  This change will allow for future expansion, if we
want to support custom fields in aliases for the so called heavy weight
libraries (if I am correctly understanding what the library development folks
are requesting).  This will probably make more sense when I submit the
blueprint for the new component library file format which should be in the next
week or so.  Except for the additional boost header files, the changes to the
current BZR version are pretty minimal in keeping with my preference to making
small incremental changes to the existing code.  I could submit a patch or
publish my branch if you would like to take a look at it.  If you have any
suggestions that can improve this design, I would be more than happy take a
look at it.

Wayne

> 
> Object ownership is something to keep one's eye on.
> 
> 
> 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
>