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

Did some more testing, I was able to reproduce the object bloat size with VS2012, I suspect my previous tests were likely too simple so they got optimized away, but in the general case (especially with what is used by boost operators) this doesn't happen. Out of curiosity, does anyone know if this has been suggested to MS as a bug/enhancement already? On Tue, Apr 23, 2013 at 3:15 PM, Daniel Frey wrote:

On 23.04.2013, at 21:56, Andrew Ho 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 addable1 addable1

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

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

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Andrew Ho