Re: [boost] [operators] The future of Boost.Operators

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Daniel Frey (d.frey_at_[hidden])
Date: 2013-04-23 17:15:13

On 23.04.2013, at 21:56, Andrew Ho <helloworld922_at_[hidden]> wrote:

> Fair enough, though using an enum would be able to capture commutative, 
> non_commutative_right, and non_commutative_left.
> 
> addable1<T> // default to non_commutative_right or some behavior which works 
> best for the particular operator
> addable1<T, non_commutative_right>
> addable1<T, non_commutative_left>
> addable1<T, commutative>

That wouldn't work so easily, as left/right only makes sense for the two-argument version. You'd need something like

addable1< T, non_commutative >
addable1< T, commutative >
addable2< T, U, non_commutative_left >
addable2< T, U, non_commutative_right >
addable2< T, U, commutative >

and you need specializations with static_asserts for invalid cases like

addable2< T, U, non_commutative > // no _left or _right -> invalid

>> Note that I'd like to get rid of the addable1/addable2 distinction as 
> well, just addable< T > or addable< T, U > is IMHO easier.
> 
> I like this idea, though I think this would mean that the current system of 
> using single chain inheritance unwieldy. To specify a specific chain, the 
> user would have to extend addable<T, T, B> rather than extending addable<T, 
> B>. Likewise similar specifications must be made for any other template 
> tracked parameters (addable<T, T, commutative>). Using different structs 
> all-together (addable/addable_left/addable_commutative) and multiple 
> inheritance would avoid this.

Granted, chaining is quite invasive here. Which is why I'd like to avoid it, see the next paragraph:

> There was a note in the current docs about significant code bloat involving 
> multiple inheritance with multiple empty classes, though I haven't been able 
> to reproduce their claims in vc++ 2012. IMO the multiple inheritance route 
> makes more sense conceptually, but I wouldn't want to have object sizes grow 
> unnecessarily. There weren't any notes as to what specific compilers 
> exhibited this behavior, but the comment was made circa ~2000 so perhaps 
> this has been addressed by now. Is this still a significant concern now?

I wish MS would have fixed it. AFAIK the only compiler/ABI that has this problem is VC++/Windows and I already have one user reporting that the problem still exists. If you say you can't reproduce it, I'd like to find out why! What have you tried and which settings do you use? (Note I don't have access to VC++ or Windows, so I need some help).

Daniel