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

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

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 rather than extending addable. Likewise similar specifications must be made for any other template tracked parameters (addable). 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?