Re: Verify and expression
* Mark Van Peteghem:
To be able to use the << operator for the expressions [in an
assertion macro] that I want to
be evaluated and shown, I use an object on the stack like this:
ModAssert::ParameterList parList; \
parList.SetExpressions(#params); \
parList << params; \
I could replace it with
&((*new ModAssert::ParameterList(#params)) << params)
and have the function that takes that object, delete it. Creating
objects on the heap is slower, but anyway. Or I could make it a
global object, but then I would have to make it threadsafe, not
optimal but possible.
Note: threading is currently outside the language. It's necessary to go
outside the current language to have threading. Thus, solutions to
threading issues must in general be sought outside the current language.
If the above code is all that this variable is used for, however, why
don't you do
ModAssert::ParameterList(#params) << params
which is a nice little expression, with no extra costly dynamic allocation?
;-)
So the problem is not in adding expressions.
A real showstopper is the line
static bool modassert_display = true;\
which can be set to false if the assertion is repeatedly failing and
starts to get on your nerves, so the assertion is no longer shown.
This means I can't even use my simplest assertions as expressions.
That looks like a global to me.
Very easy to fix.
Just move the definition elsewhere, e.g. to an implementation file or
inside a function that you call.
Another showstopper is the optional action. The way I do it now it is
possible to have more than one statement by separating them with a
semicolon. You can even have braces (although it looks strange in a
macro). I don't think that is possible inside a ? : expression.
Right, there are restrictions. E.g. a loop is not an expression, but a
function call is. So a direct C++ loop construct can't be supplied by
the client code (although something like foreach can (where the Boost
library has some possibly useful "functional language" functionality)).
Anyway, it seems the problem has been reduced to or identified as: an
expression (e.g. an assert macro that should work as expression) must be
an expression, consisting in turn of expressions, and so on, which
prevents the client code from supplying /directly/ the most imperative
constructs, like loops, as side-effect macro arguments; in essence,
paraphrasing you, "you can't have braces in an expression", it must
stand on its own unsupported by braces.
I think that's a desirable feature, not an undesirable restriction.
So, IMHO that's good, not ungood.
But again, we're not discussing MOD_ASSERT_P (where the ability to serve
as an expression isn't really useful, as far as I can see), we're
discussing the general implications -- an earlier unspecified problem
-- of being able to use a "doer" macro as an expression. And as it
turned out it seems the unspecified problem was really a feature, also
for MOD_ASSERT_P, namely, that even if MOD_ASSERT_P wouldn't benefit
directly from being able to be used as an expression, it would benefit
indirectly, by offering a more reasonable interface to the client code.
Cheers,
- Alf
--
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! ]