From: Ulrich Eckhardt on
Vladimir Grigoriev wrote:
> Ulrich, I forgot to add that in the derived class the constructor for the
> base class must be.
>
> B( const A & );
>
> In this case two conversions can be: B ==> A and A ==> B and an ambiguous
> reference can occur.

Make it explicit, or maybe don't use public derivation.


>> Think of this:
>>
>> b some_b;
>> a& a_ref = some_b;
>> a_ref+a_ref; // now what?
>>
>> struct c: b {...};
>> c some_c;
>> b& b_ref = some_c;
>> b_ref+b_ref; // and here?

Did you think about those cases? How should those two cases behave?

Again, please don't quote anything up to the signature, it's rude and it
makes communication much harder, as people have to guess what you're
referring to. Thank you.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Bo Persson on
Vladimir Grigoriev wrote:
> Ulrich, I forgot to add that in the derived class the constructor
> for the base class must be.
>
> B( const A & );
>
> In this case two conversions can be: B ==> A and A ==> B and an
> ambiguous reference can occur.

If you can always construct a B from an A, what is the difference? Why
are they different classes in the first place?


Bo Persson



>
> Vladimir Grigoriev
> .
> "Ulrich Eckhardt" <eckhardt(a)satorlaser.com> wrote in message
> news:i42037-u4l.ln1(a)satorlaser.homedns.org...
>> Vladimir Grigoriev wrote:
>>> However try to provide that a + a will not compute when a + b, b
>>> + a, and b + b will compute for two classes when one is derived
>>> from another..
>>
>> Simple, provide these three overloads and no others:
>>
>> b operator+(a const& l, b const& r);
>> b operator+(b const& l, a const& r);
>> b operator+(b const& l, b const& r);
>>
>> However, I can't think of a reason for this either. Think of this:
>>
>> b some_b;
>> a& a_ref = some_b;
>> a_ref+a_ref; // now what?
>>
>> struct c: b {...};
>> c some_c;
>> b& b_ref = some_c;
>> b_ref+b_ref; // and here?
>>
>> Generally, operator+ is something that rather fits for value
>> types. Public inheritance usually means the type is rather an
>> entity type, which don't like being treated as a value.
>>
>> Uli
>>
>> --
>> C++ FAQ: http://parashift.com/c++-faq-lite
>>
>> Sator Laser GmbH
>> Geschaftsfuhrer: Thorsten Focking, Amtsgericht Hamburg HR B62 932



From: Vladimir Grigoriev on
If you will make it explicit you get another problem with declaring objects.
For example you can not write

A a;
B b = a;

And even you do not bother about this restriction adding template
constructor will destroy your set of operators.

Vladimir Grigoriev

"Ulrich Eckhardt" <eckhardt(a)satorlaser.com> wrote in message
news:sth037-orl.ln1(a)satorlaser.homedns.org...
> Vladimir Grigoriev wrote:
>> Ulrich, I forgot to add that in the derived class the constructor for the
>> base class must be.
>>
>> B( const A & );
>>
>> In this case two conversions can be: B ==> A and A ==> B and an ambiguous
>> reference can occur.
>
> Make it explicit, or maybe don't use public derivation.
>
>
>>> Think of this:
>>>
>>> b some_b;
>>> a& a_ref = some_b;
>>> a_ref+a_ref; // now what?
>>>
>>> struct c: b {...};
>>> c some_c;
>>> b& b_ref = some_c;
>>> b_ref+b_ref; // and here?
>
> Did you think about those cases? How should those two cases behave?
>
> Again, please don't quote anything up to the signature, it's rude and it
> makes communication much harder, as people have to guess what you're
> referring to. Thank you.
>
> Uli
>
> --
> C++ FAQ: http://parashift.com/c++-faq-lite
>
> Sator Laser GmbH
> Geschaftsfuhrer: Thorsten Focking, Amtsgericht Hamburg HR B62 932


From: Vladimir Grigoriev on
Not always but you allow such possibility. A derived class can add new
features to a base class. And the problem is that the base class do not have
new features of the derived class.

Vladimir Grigoriev

"Bo Persson" <bop(a)gmb.dk> wrote in message
news:7s5uorF1bqU1(a)mid.individual.net...
> Vladimir Grigoriev wrote:
>> Ulrich, I forgot to add that in the derived class the constructor
>> for the base class must be.
>>
>> B( const A & );
>>
>> In this case two conversions can be: B ==> A and A ==> B and an
>> ambiguous reference can occur.
>
> If you can always construct a B from an A, what is the difference? Why are
> they different classes in the first place?
>
>
> Bo Persson
>
>
>
>>
>> Vladimir Grigoriev
>> .
>> "Ulrich Eckhardt" <eckhardt(a)satorlaser.com> wrote in message
>> news:i42037-u4l.ln1(a)satorlaser.homedns.org...
>>> Vladimir Grigoriev wrote:
>>>> However try to provide that a + a will not compute when a + b, b
>>>> + a, and b + b will compute for two classes when one is derived
>>>> from another..
>>>
>>> Simple, provide these three overloads and no others:
>>>
>>> b operator+(a const& l, b const& r);
>>> b operator+(b const& l, a const& r);
>>> b operator+(b const& l, b const& r);
>>>
>>> However, I can't think of a reason for this either. Think of this:
>>>
>>> b some_b;
>>> a& a_ref = some_b;
>>> a_ref+a_ref; // now what?
>>>
>>> struct c: b {...};
>>> c some_c;
>>> b& b_ref = some_c;
>>> b_ref+b_ref; // and here?
>>>
>>> Generally, operator+ is something that rather fits for value
>>> types. Public inheritance usually means the type is rather an
>>> entity type, which don't like being treated as a value.
>>>
>>> Uli
>>>
>>> --
>>> C++ FAQ: http://parashift.com/c++-faq-lite
>>>
>>> Sator Laser GmbH
>>> Geschaftsfuhrer: Thorsten Focking, Amtsgericht Hamburg HR B62 932
>
>
>