Syntax Error with Q_ASSERT
-
It's almost the same as the current implementation of Q_ASSERT, just with a variadic macro. So it's C++11 only.
-
@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. -
@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.@Chris-Kawa Damn, I only tested it with MSVC and it works there :-(
-
@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.@Chris-Kawa My
ideahope was that the preprocessor would be smarter when I confront it with a variadic macro. -
@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.
-
@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.
@Chris-Kawa Yes it works; funny that it doesn't work for you. Who knows why..
-
@Wieland Maybe I messed up something. http://ideone.com/XKJUnV
-
@Wieland Maybe I messed up something. http://ideone.com/XKJUnV
@Chris-Kawa Ha! Just found out that
#define FIRST(A, ...) Adoesn'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.
-
Thanks everyone for watching me stumbling around like a clown :)
-
Thanks everyone for watching me stumbling around like a clown :)
@Wieland
Well to be fair, fooling around with Variadic Macros takes more balls than entertaining
clueless children - so it was educational to see that even in 2016, you cannot trust the preprocessor
to work the same across compilers. :)
