kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 02/10/2014 13:29, LordBlick a écrit :
> In response to a message written on 02.10.2014 01:26, from Wayne Stambaugh:
>> On 10/1/2014 3:08 PM, jp charras wrote:
>>> Le 01/10/2014 20:42, Daniel Dawid Majewski a écrit :
>>>> On 01.10.2014 16:25, Wayne Stambaugh wrote:
>>>>> They do.  It is automatically generated by the compiler just like the
>>>>> source code comment explains.  Unless you need some special copy
>>>>> semantics (not just a direct copy of every class member which is what
>>>>> the compiler will generate), you do not need to write your own copy
>>>>> constructor.
>>>> Ok, so where are nested following python methods ?:
>>>> Copy(MODULE self, MODULE src)
>>>> Copy(ZONE_CONTAINER self, ZONE_CONTAINER src)
>>>> How I could make ?:
>>>> Copy(TRACK self, TRACK src)
>>>> Copy(VIA self, VIA src)
>>>
>>> Seems there is a mistake between a copy constructor and the Copy method
>>> which exists for some BOARD_ITEMS, but not all (because currently this
>>> method is not needed in C++ Kicad code for track/vias)
>>>
>>> The Copy method copy only some values from an existing source to an
>>> existing target.
>>>
>>> The default copy constructor creates a clone (a new item) of an item.
>>> This is very different.
>>>
>>> I'll add a Copy method (mainly for python scripts) for tracks/vias soon.
>>
>> Please don't unless there is no other solution.  There is no reason to
>> create a custom copy method when the default copy constructor is more
>> reliable.  I promise you someone will add another class member that they
>> will forget to add to the copy method.  We've been bit by this several
>> times in the past.  It's a poor design pattern that I do not want to
>> repeat.  The only time I can think of the use a custom copy constructor
>> is when dynamically allocated memory is involved.  Are we using copyctor
>> feature flag in SWIG when generating the C++ source files?  If not, then
>> an explicit copy constructor must be defined.  You can read about it
>> here http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus_nn7.  Let see if
>> we can get SWIG to do it for us before we travel down the bad design path.
> IMHO JP Charas is not going to do with any coping class. That's misunderstanding.
> I suggest to rename all python „Copy” methods to „paramCopy”(or sth similar),
> cause in fact they are only coping values of elements between instances of same
> class.
> Python formula „newItem = Item.__class__(pcb)” makes new instance of the same
> class, so we no need class copy or sth similar…
> Apart from this, we have python method „Clone”, which seems unusable - returns
> some bogus instance of pcbnew.EDA_ITEM. It's possible to make it workable by
> overloading method with creating new instance of the same class
> [Item.__class__(pcb)] and then coping values from old to new instance.
> 

Can you test the existing method:
new_item=Cast_to_BOARD_ITEM(item.Clone()).Cast()

to create a copy of an item ?

-- 
Jean-Pierre CHARRAS