Re: Verify and expression
* Dave Harris:
alfps@start.no (Alf P. Steinbach) wrote (abridged):
Featurism! ;-)
As Andrei says, vertical space is precious.
Bah, my monitor can be turned 90 degrees. Not that I use that feature.
To save vertical space & typing I just leave the strong arguments
against side-effect operators & terse code, and ditto strong arguments
for clarity and readability, to the reader's imagination.
[snip]
Please elaborate -- a specific, clear example would be nice
How about:
return VERIFY( p->value(), "bad value from: " << p->dump() );
where:
(a) p->value() should be evaluated exactly once regardless of
whether checks are enabled.
(b) The type and value returned should be the same as the type and
value of p->value(). (You can return 0 on failure, but it'd be
even better if that wasn't necessary.)
(c) p->value() may also use VERIFY.
(d) p->dump() may also use VERIFY.
(e) The code should be thread-safe.
(f) p->dump() is evaluated only if the check fails.
That's listed in my personal order of importance. (f) is the one I would
drop. The ideal VERIFY would satisfy them all.
Hopefully there will now not be a follow up requesting higher speed
and/or no turbo device and/or only three wheels or whatever. ;-)
Let's start with (f) then, that's the conditional operator, which is
nice enough to only evaluate the selected result sub-expression:
(valueExpr? true : (log << logExpression, std::terminate(), true))
Now the goal is to replace the first 'true' with the valueExpr's value,
and here it doesn't suffice to delegate the whole expression to a
function, because the function arguments would be evaluated, including
logExpression, which by (f) shouldn't be evaluated in all cases. But a
function can store and retrieve the valueExpr value. Then it looks like
(setTempValue<TYPEOF(valueExpr)>( valueExpr, ASSERTIONID )
? tempValue<TYPEOF(valueExpr)>( ASSERTIONID )
: (
log << logExpression,
std::terminate(),
dummyTempValue<TYPEOF(valueExpr)>( ASSERTIONID )
)
)
where ID is a unique id formed from __FILE__ and __LINE__, and the
functions used, setTempValue<>(), tempValue<>() and dummyTempValue<>(),
provide static thread local storage to satisfy requirement (e).
Thread locale storage is outside the scope of the current language, but
evidently there is a fairly portable implementation in the Boost
library, a class boost::thread_specific_ptr.
Since this is evaluated from left to right, top to bottom, (d) is also
satisified, and so is (c), (b) and (a). Another feature of that
evaluation sequence is that an ASSERTIONID to identify the relevant temp
variable is really superflous. There is pure stack behavior for the
simulated temporary variables, and so the expression can be both
simplified & optimized:
(setTempValue<TYPEOF(valueExpr)>( valueExpr )
? tempValue<TYPEOF(valueExpr)>( valueExpr )
: (
log << logExpression,
std::terminate(),
dummyTempValue<TYPEOF(valueExpr)>()
)
)
Of course that TYPEOF in there is a bit suspicious. For compilers that
don't support de facto standard 'typeof' nor the newfangled C++0x
some-unreadable-designator-of-the-same, true TYPEOF can be simulated by
registering the relevant types via a declarative macro, e.g.
REGISTER_TYPEOF_TYPE. That's my turbo device this time. ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]