«

Hi!

I am for defensive programming and am working on a code stuffed with
quite a lot of assert-like statements, like

Asserts(pos[i]==pos[i],"Position #"+to_string(i)+" is NaN");

where Asserts is

#define Asserts(expr,s) \
if(!(expr))
Framework::Asserts_Fail(__STRING(expr),__FILE__,__ LINE__,__PRETTY_FUNCTION__,s)

and Asserts_Fail() displays a bunch of info and terminates the
program.

My question: a typical assert falls through 99.999% of the time as
if(!(expr)) is false. Am I guaranteed though, that the std::string
"Position #number is NaN" would not be constructed in vain _every
time_ this assert is checked? My understanding is that since this is a
macro, not a function call, then it is only constructed when the
assert actually clicks and Asserts_Fail() is called. If Asserts() was
made to be a function call instead of a macro, then I might not be as
lucky.

Can anyone confirm or contradict this?

TIA,
- J.

writes:

> Hi!
>
> I am for defensive programming and am working on a code stuffed with
> quite a lot of assert-like statements, like
>
> Asserts(pos[i]==pos[i],"Position #"+to_string(i)+" is NaN");
>
> where Asserts is
>
> #define Asserts(expr,s) \
> if(!(expr))
> Framework::Asserts_Fail(__STRING(expr),__FILE__,__ LINE__,__PRETTY_FUNCTION__,s)
>
> and Asserts_Fail() displays a bunch of info and terminates the
> program.
>
> My question: a typical assert falls through 99.999% of the time as
> if(!(expr)) is false. Am I guaranteed though, that the std::string
> "Position #number is NaN" would not be constructed in vain _every
> time_ this assert is checked? My understanding is that since this is a
> macro, not a function call, then it is only constructed when the
> assert actually clicks and Asserts_Fail() is called. If Asserts() was
> made to be a function call instead of a macro, then I might not be as
> lucky.
>
> Can anyone confirm or contradict this?

Yes, emacs can.


Put your source in some buffer named test.c:
------------------------------------------------------------------------
#define Asserts(expr,s) \
if(!(expr)) Framework::Asserts_Fail(__STRING(expr),__FILE__,__ LINE__,__PRETTY_FUNCTION__,s)


Asserts(pos[i]==pos[i],"Position #"+to_string(i)+" is NaN");
------------------------------------------------------------------------

Select it and type C-x C-e ; it will open another buffer containing
the code with the macros expanded:
------------------------------------------------------------------------




if(!(pos[i]==pos[i])) Framework::Asserts_Fail(__STRING(pos[i]==pos[i]),"a.c",5,__PRETTY_FUNCTION__,"Position #"+to_string(i)+" is NaN");
------------------------------------------------------------------------

If you don't have emacs, you can run the c preprocessor on the source:

gcc -E -o test.e test.c && cat test.e


So you can see that indeed, the expansion of the macro is purely
textual, and the the concatenation will occur only when the assertion
is false.

--
__Pascal Bourguignon__

On Sep 24, 9:45 am, jacek.dzied...@gmail.com wrote:

> I am for defensive programming and am working on a code
> stuffed with quite a lot of assert-like statements, like

> Asserts(pos[i]==pos[i],"Position #"+to_string(i)+" is NaN");

> where Asserts is

> #define Asserts(expr,s) \
> if(!(expr))
> Framework::Asserts_Fail(__STRING(expr),__FILE__,__ LINE__,__PRETTY_FUNCTION__,s)

> and Asserts_Fail() displays a bunch of info and terminates the
> program.

That's a very unusual definition. I've generally seen something
more like:

((expr) || Framework::Asserts_Fail( ... ))

The idea being that the expansion of the macro is a pure
expression, and can be used anywhere an expression can be used
(and if there is support for turning it off, the macro expands
to something like "((void)0)").

> My question: a typical assert falls through 99.999% of the time as
> if(!(expr)) is false.

More often than that, one would hope. In production code, it
should fall through 100% of the time.

> Am I guaranteed though, that the std::string "Position #number
> is NaN" would not be constructed in vain _every time_ this
> assert is checked?

Obviously. With both versions above. Including if the macro
was passed a string expression.

> My understanding is that since this is a macro, not a function
> call, then it is only constructed when the assert actually
> clicks and Asserts_Fail() is called. If Asserts() was made to
> be a function call instead of a macro, then I might not be as
> lucky.

> Can anyone confirm or contradict this?

Macros are, well, macros. They are expanded textually by the
compiler. What happens after that depends on the results of the
textual expansion.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Sep 24, 10:42*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> So you can see that indeed, the expansion of the macro is purely
> textual, and the the concatenation will occur only when the assertion
> is false.

Thank you.

On Sep 24, 11:06*am, James Kanze <james.ka...@gmail.com> wrote:
> That's a very unusual definition. *I've generally seen something
> more like:

Yes, I rolled my own without seeing how it's typically done.

>
> * * ((expr) || Framework::Asserts_Fail( ... ))
>
> The idea being that the expansion of the macro is a pure
> expression, and can be used anywhere an expression can be used
> (and if there is support for turning it off, the macro expands
> to something like "((void)0)").

Yes, I can see the advantage.

> > My question: a typical assert falls through 99.999% of the time as
> > if(!(expr)) is false.
>
> More often than that, one would hope. *In production code, it
> should fall through 100% of the time.

I'm very far from production code .

> Macros are, well, macros. *They are expanded textually by the
> compiler. *What happens after that depends on the results of the
> textual expansion.

Right, thanks for the confirmation.