Re: Verify and expression
* Dave Harris:
alfps@start.no (Alf P. Steinbach) wrote (abridged):
but this evaluates the condition twice, which is unacceptable if it
has side effects.
Well, as I mentioned (and exemplified) elsethread, that's easy to fix
technically,
If I understand what you are referring to, you fixed it by throwing away
the type and value of the expression, and simply returned true if it
succeeded. Which is reasonable because it was what the original poster's
code did in debug builds. I, on the other hand, was influenced by
Frederick Gotham's code, which used a template to preserve the type and
value. I think it would be OK to return 0 or false on failure, but if it
preserved the value on success it could be used like:
char *s = VERIFY( strdup( "test" ), "out of memory" );
which would be more useful.
Featurism! ;-)
Well, a broadening of scope, because now it's very unclear what the
requirements are.
Anyway, the above is very possible, but I'd prefer
char const* s = strdup( "test" );
!!s || TERMINATE( "out of memory" );
(You mention also using a global variable to store the condition's value,
but I think that suffers from not being re-entrant or thread-safe. If you
had something else in mind, I missed it.)
Irrelevant! ;-)
Note that
std::cout << "uh, well" << std::endl;
is not thread safe.
In short, the argument seems to be, "because C++ does not currently
support threading, nothing can be implemented in C++ (it would not be
thread safe)", which smacks of fallacy, at least to my tongue's taste
buds. As I've mentioned elsethread, the part you looked at for the
above comments, solutions to threading issues must be sought outside the
language. And at least on the system I'm most familiar with, it's no
problem.
but as I also mentioned there, the better solution IMO is
to require the condition to not have side effects.
The original poster wanted a replacement (or upgrade) for the MFC VERIFY.
The whole point of the MFC version is that it allows side effects in the
condition - otherwise you would just use ASSERT. (The MFC version does not
return the result, so if the expression has no side effects and no result
there's no need to include it in release builds.) So I see allowing side
effects in the condition as crucial part of the specification.
Yeah, well, no problem! ;-)
However, personally I think it would be OK to forbid side effects in the
report argument.
#define VERIFY( condition, report ) \
verify( (condition), (VerifyArgs() << report),\
__FILE__, __LINE__ )
where VerifyArgs is a class with template members which capture the types
and values of report, and verify itself is a template function which
returns the type and value of condition. I would expect the report
argument to be just a list of strings values and values:
int c = VERIFY( a+b, "a=" << a << " b=" << b );
so it shouldn't need side effects - provided, of course, the values aren't
displayed or logged or whatever if the check succeeds. I expect the author
of ModAssert would disagree with me.
Repeat above comment, + that this is an example of invalid code, but
what's the point of that?
I posted the invalid code to illustrate the problem: to show the kind of
thing we need to do, but can't.
Need to? Can't? Please elaborate -- a specific, clear example would
be nice (so that we don't get into "It's impossible to drive faster than
80 kph!" "Yeah? I just did." "No, you used the forbidden turbo device."
"Yeah? Here's footage from 100 kph sans turbo device." "No, it must be
100 kph!" "Yeah? Here's that." "With only three wheels!" "Yeah? ...")
--
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! ]