kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 26/05/2016 à 08:59, Maciej Sumiński a écrit :
> Thank you Cirilo. I am trying to be really careful here, that is why I
> am asking for more details. I would like to make the code simpler, so
> there are no more doubts about whether to use operator = or Copy() (for
> some classes it is exactly the same code).
> 
> For the scenario you described, there is EDA_ITEM::Clone() method.
> Copy() is defined only for a few classes, and others are copied using
> operator=, so it is a bit confusing to me.
> 
> Regards,
> Orson

Usually, Copy() is used when you do not want to copy all members.
Typically when you do not want to change Pback, Pnext, m_Parent, time stamp and a few other pointers
and flags.

If these members are reinitialized (or have the right value) after copy, using Copy() or = (for
classes which do not define Copy() and can be copied by = ) can give the same result.

> 
> On 05/26/2016 01:23 AM, Cirilo Bernardo wrote:
>> Be very careful; Copy() may exist because a Base Class copy constructor
>> might not perform the desired task and an Abstract Class definitely cannot
>> perform the desired task. For example:
>>
>> class A0; (abstract or base class)
>> class A1 : public A0;
>> class A2 : public A0;
>>
>> void bar( A0* var );
>>
>> void foo()
>> {
>>   A1 a1;
>>   A2 a2;
>>
>>  bar( a1 );
>>  bar( a2 );
>> }
>>
>> bar( A0* bar )
>> {
>>   // now we want a copy of *bar - how do we do that?
>>
>>  // the typical solution:
>>  A0* newItem = bar->NewCopy();
>> }
>>
>>
>> On Thu, May 26, 2016 at 12:03 AM, Maciej Sumiński <maciej.suminski@xxxxxxx>
>> wrote:
>>
>>> I am trying to understand the meaning of Copy() method defined for some
>>> of BOARD_ITEMs. I would like to replace the method with operator= to
>>> make the code clearer, and then give it consistent behavior. I have
>>> noticed that Copy() implementations differ in:
>>>
>>> - clearing Pback/Pnext fields
>>> - setting a new timestamp
>>> - copying pointer to parent object
>>>
>>> I guess we should not change parent & DLIST related fields, as they are
>>> expected to be already set to valid values (might be NULL for standalone
>>> objects, but it is still OK). I suspect timestamp has to be set to a new
>>> value to distinguish the objects.
>>>
>>> Regards,
>>> Orson
>>>


-- 
Jean-Pierre CHARRAS