And _Generic is still somewhat ugly: it has the awkward property that all the branches must pass the type checker even if they are not used. This is mostly OK for numerical functions where you get some help from C’s implicit conversions making the checker more lenient, but if you try to apply _Generic in other contexts you soon encounter problems.
The ternary operator is indeed special as it (is the only one AFAIK that) introduces in the language some type constraints between the two result branches, that affect the way one or the other is interpreted.
> You may be thinking this is needlessly convoluted. After all, couldn't we just use encode_type(container) without the conditional operator and get the same result? No, because that would have caused container to be evaluated. With the conditional operator, only one branch of the condition is ever executed. In this case, since the condition is always true, the first branch will always be taken. The second branch is "dead code"—it will never execute—yet it extends a ghostly finger into the land of the living and exerts its influence on the conditional expression's type. Spooky!
23 comments
[ 3.0 ms ] story [ 42.6 ms ] threadFor the curious, here's an implementation of tgmath.h on top of _Generic:
https://github.com/NuxiNL/cloudlibc/blob/master/src/include/...
'Add type generic interfaces for string functions to the C library, see N2068' has been mentioned as a possible C2x addition https://gustedt.wordpress.com/2018/11/12/c2x/
A similar trick in C++ is explained on https://www.artima.com/cppsource/foreach2.html and allows to return the type of an expression without evaluating it.
From the link:
> You may be thinking this is needlessly convoluted. After all, couldn't we just use encode_type(container) without the conditional operator and get the same result? No, because that would have caused container to be evaluated. With the conditional operator, only one branch of the condition is ever executed. In this case, since the condition is always true, the first branch will always be taken. The second branch is "dead code"—it will never execute—yet it extends a ghostly finger into the land of the living and exerts its influence on the conditional expression's type. Spooky!
https://code.woboq.org/qt5/qtbase/src/corelib/global/qglobal...
"But there already is a C++ facility whose sole purpose is determining the type of an expression [or entity] without evaluation it?"
decltype() only exists since C++11 (and the above article is from 2006).
https://en.cppreference.com/w/cpp/language/decltype
https://en.wikipedia.org/wiki/Setjmp.h
Any sufficiently complicated C program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of C++.
[1] https://www.amazon.com/Wenger-16999-Swiss-Knife-Giant/dp/B00....
Is that the maximum you can charge on Amazon? Seems strange that they'd want to put a limit on it.
(Are there enough knives in the entire swiss army to make this work?)
(Ah no..., wrong thread. This is actually about C. /s)
Discussed in 2011: https://news.ycombinator.com/item?id=3392728