Ideas for something that looks like metaprogramming
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... --John (sorry about the footer; it's not my idea) TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
On Thu, Apr 23, 2009 at 4:58 PM, John Dlugosz
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
participants (2)
-
Emil Dotchevski
-
John Dlugosz