Syntax Error with Q_ASSERT

kshegunov

@mrjj said in Syntax Error with Q_ASSERT:

one should think preprocess at least accepts valid
syntaxes

Why should anyone think that?

@Wieland said in Syntax Error with Q_ASSERT:

That's really pretty stupid.

The preprocessor is basically a copy-paste-made-easy, it's a very, very simple program. It does string replacements only, it cares not for any syntax or any language for that matter. You can run the preprocessor independently of the compiler (whether it's C, C++, Java, FORTRAN or w/e), and actually some fortran code (used with gfortran) makes use of the gcc's preprocessor.

? Offline

@kshegunov The preprocessor is part of the C++ language specification and I would expect that, besides all the other smart things it also can do, it is able to handle such situations in a sane way. Anyways, I got used to C++ coming up with nasty surprises.

Edit: Next time maybe better Write in Go ;-)

kshegunov

@Wieland said in Syntax Error with Q_ASSERT:

The preprocessor is part of the C++ language specification

It is? I've never known that.

Anyways, I got used to C++ coming up with nasty surprises.

Eh, yeah. More syntax means more pitfalls. But tell that to the standards committee ... as you said, just write in Go! ;)

Chris Kawa

The preprocessor only understands ( and , in this case (as it's a pre processor i.e. no symbols, namespaces or templates exist at this point), so this is basically parsed as Q_ASSERT(STUFF, OTHER_STUFF); When you put the extra parentheses it becomes Q_ASSERT(STUFF_IN_PARENTHESES).

Here's a cute gotcha for the extra parentheses trick:
Because the general rules for type deduction in c++ were pretty boring, c++11 brought such wonders as decltype to make it more fun:

int foo;
bool nudge_nudge_wink_wink = std::is_same<decltype(foo), decltype((foo))>::value; //gives "false"... obviously :P

This marvel is sponsored by the fact that foo is an lvalue and (foo) is an expression ;)

So if in your macro you happen to try to deduce the type of the expression passed to it you might have a joyful debugging session.
This is one such super-simplified pattern commonly found in macro based property systems:

#define FOO(bar, bazz) decltype(bar) hello = bazz;

int foo;

FOO(foo, 42); //works fine
FOO((foo), 42); //error: invalid initialization of non-const reference of type 'int&' from an rvalue of type 'int'

@kshegunov
C++ standard includes C standard by reference. One of the talks at this year's CppCon mentioned that there was a cleanup effort in C++17 made to remove some of the more obscure or irrelevant C headers.

? Offline

@Chris-Kawa Thank you for this! Every day a new surprise. Or two.

kshegunov

@Chris-Kawa
Yes, I suppose so, I just never thought about it. I don't often think about what the standard does or doesn't include, but I always thought the preprocessor is just a "common non-standardized extension", the language doesn't require it to function. And seeing that code, which I'm happy to say I understand not one iota of, I must reiterate my despise for C++11. :)

Chris Kawa

@kshegunov

I must reiterate my despise for C++11. :)

There there... <pat on the back> :)

kshegunov

C++11 always evokes this feeling in me:

and by the way I'm an atheist ... :]

? Offline

I just came up with something that looks like a solution for this to me. What do guys think?

#if !defined(MY_ASSERT)
#  ifndef QT_NO_DEBUG
#    define MY_ASSERT_FIRST_ARGUMENT(A, ...) A
#    define MY_ASSERT(...) ((!MY_ASSERT_FIRST_ARGUMENT(__VA_ARGS__)) ? qt_assert(#__VA_ARGS__,__FILE__,__LINE__) : qt_noop())
#  else
#    define MY_ASSERT(...) qt_noop()
#  endif
#endif

mrjj

@Wieland
where is the docs? ;)
Looks cool. its cryptic enough that it might actually work :)

koahnig

@mrjj said in Syntax Error with Q_ASSERT:

Looks cool. its cryptic enough that it might actually work :)

:D :D

? Offline

It's almost the same as the current implementation of Q_ASSERT, just with a variadic macro. So it's C++11 only.

Chris Kawa

@mrjj good one :)
@Wieland Could you explain how it is suppose to work? From what I can decrypt it just checks the first argument passed, so for your original exampleMY_ASSERT(std::is_same<int, int>::value); it would expand to something like ((!std::is_same<int) ? ... which doesn't make much sense? Or am I missing something?

Btw. I get compiler errors for this:
with gcc: in definition of macro MY_ASSERT_FIRST_ARGUMENT wrong number of template arguments (1, should be 2)
with clang: error: expected > MY_ASSERT(std::is_same<int, int>::value);
it compiles in VS2015 U3 although their macro expansion is broken to bits so I wouldn't trust it does what it should.

? Offline

@Chris-Kawa Damn, I only tested it with MSVC and it works there :-(

? Offline

@Chris-Kawa My ~~idea~~ hope was that the preprocessor would be smarter when I confront it with a variadic macro.

Chris Kawa

@Wieland I don't think it works. It just compiles ;)
Well you could use something simpler:

define MY_ASSERT(...) (!(__VA_ARGS__) ? qt_assert(#__VA_ARGS__,__FILE__,__LINE__) : qt_noop())

and that should be ok, but it has the same drawback I described earlier - it changes the expression it tests by adding extra () around it. Admittedly it's not a big deal and it should work as expected most of the time.

? Offline

@Chris-Kawa Yes it works; funny that it doesn't work for you. Who knows why..

Chris Kawa

@Wieland Maybe I messed up something. http://ideone.com/XKJUnV

? Offline

@Chris-Kawa Ha! Just found out that #define FIRST(A, ...) A doesn't work as expected (with MSVC): It doesn't give us the first argument only, instead it just gives all arguments (like __VA_ARGS__). Maybe I'm wrong here again, but that looks like a bug in MSVC to me and it also explains why the code works.

Edit: Maybe it's really a bug in VC's preprocessor, at least someone on SO says so. And the workaround he presents actually seems to fix it, so now my code doesn't compile with MSVC anymore.

? Offline

Thanks everyone for watching me stumbling around like a clown :)