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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Andrew Ho (helloworld922_at_[hidden])
Date: 2013-04-23 15:56:51

> I don't see how it would make the implementation any easier, you still 
need to commutative and the
> non-commutative version and they can't really re-use each other's code. It 
also means you end up with a
> terrible interface, consider
> 
> addable1< T >
> addable1< T, true > // true what? that doesn't speak for itself
> 
> vs.
> 
> commutative_addable< T > // ah, this is a commutative operator!
> addable< T > // does not have commutative in the name -> doesn't 
require/exploit it! The safe, although
> slightly less efficient default

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>

> 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.

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?