Re: [boost] Re: Empty base optimization and operators.hpp

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-04-30 16:39:58

Dave Abrahams <abrahams_at_[hidden]> wrote:
> Unfortunately, Microsquish actually distinguishes between 'class' and
> 'struct' in its link names, or it wouldn't matter. Once you call something
a
> struct or class, if you want maximum compatibility you have to keep it.
>
> On the other hand, I don't mind shaking things up for Microsquish users
once
> in a while ;)
> Using 'struct' everywhere would make things much cleaner.
>
I also think so. Does anybody have a strong opinion against that change?

> I have two questions remaining:
> 1. Is this worth all the complication (it is *very* complex)?

It's the hardest question, I think. I think the answer depends on how
painful for users will be removal of two-type templates' versions with the
names without '2' at the end. Probably we should ask them publicly and then
take a decision.

> 2. What if there's no partial specialization? What are we left with? All
the
> same stuff without the 2-operand templates named without the trailing '2'?
>
Yes. BOOST_OPERATORS_TEMPLATE local macro takes care of it in that case. The
following code compiles successfully on MSVC 6.3:

class Y : addable<Y> {
public:
 Y& operator+=( const Y& ) { return *this; }
};

class X : addable<Y, multipliable2<X, Y> > {
public:
 X& operator+=( const X& ) { return *this; }
 X& operator*=( const Y& ) { return *this; }
 };

(With one small fix to the version of 'operators.hpp' I've posted
yesterday - I forgot to add '#ifndef
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION', '#endif ' brackets to the
specialization of 'is_boost_operators_template' for 'indexable'; I've
attached the fixed version to this message.)

--Aleksey