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
> 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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk