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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: helloworld922 (helloworld922_at_[hidden])
Date: 2013-04-23 20:45:10

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 <d.frey_at_[hidden]> wrote:

> 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
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Andrew Ho