Re: [Boost-users] Ideas for something that looks like metaprogramming

Subject: Re: [Boost-users] Ideas for something that looks like metaprogramming
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-04-23 20:09:31

On Thu, Apr 23, 2009 at 4:58 PM, John Dlugosz <JDlugosz_at_[hidden]> wrote:
> I'm revamping my atomic_counter template (see <
> http://www.dlugosz.com/Repertoire/refman/Classics/atomic_counter_whitepa
> per.html#toptop>) and plan on exposing all the available "magic" (e.g.
> things you can't do in C++) op-codes in the atomic read-modify-write
> department, as primitives.  Then, use those in the template class.
>
> But, I have gained a deeper appreciation for some of the LOCKable
> instructions I never thought were interesting.  For example, you can
> LOCK ADD, which changes the value in memory but doesn't return back what
> it was or became.  What good is that?  Directly translating to C++, none
> at all.  But... you do get back some information.  In assembly language,
> you see the flags.  So, a thread can add something to the location, and
> although doesn't know what it became in general, at least know if this
> thread is the one that made it zero.  Or, overflowed, or whatever.
> Those flags are the basis of if-statements in assembly language.  So,
> given primitive calls that return the whole set of flags, it occurs to
> me to be able to harness that with a metaprogramming-like interface.
>
> For example, I'm hesitant to implement something called operator &= that
> doesn't return the new value, but "something else" instead.  I think the
> only interesting flag here is whether the result is zero.  So bool
> operator&=(left,right) returning whether the result was non-zero would
> be very confusing, even if it did work right when used in an 'if'
> condition!
>
> So, just brainstorming, x&=y would return something not directly usable,
> but does work with an overloaded ==, so if you were to write (x&=y)==0
> the result would be what you expect from C++.  Maybe it's not worth the
> effort.  But if anyone wants to discuss it...

I see no reason to implement this as operator overload.

Instead, I'd suggest using a namespace-scope function with a name that
spells out what it does as clearly as possible.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode