The Ugliest C Feature: tgmath.h | Hacker News Reader

The Ugliest C Feature: tgmath.h

web.archive.org

107 pointsbcaa7f3a8bbc21 comments

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.

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!

That's just C++ wishing that it could have a type system closer to Haskell's.

Qt apparently does something similar to implement Q_FOREACH: https://stackoverflow.com/a/10522384/5230900

That was pre-c++11. Now using C++11, it is much simpler (using 'auto'). And the C++17 version is even simpler

https://code.woboq.org/qt5/qtbase/src/corelib/global/qglobal...

That sort of operator is often tough, just look at section 15.25 in the Java language specification (https://docs.oracle.com/javase/specs/jls/se13/html/jls-15.ht...) in the type of such expressions.

For those wondering (like I did)

"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

With apologies to Philip Greenspun:

Any sufficiently complicated C program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of C++.

Sure, but the C++ STL is to code as this [1] is to knives.

[1] https://www.amazon.com/Wenger-16999-Swiss-Knife-Giant/dp/B00....

For the low low price of $9999.99.

Is that the maximum you can charge on Amazon? Seems strange that they'd want to put a limit on it.

Now let's see boost in this metaphor :P

(Are there enough knives in the entire swiss army to make this work?)

Yes, but it's most of the good 1/5 of it, with just a little bit of the atrocious 1/3, and the rest taken from the "who cares" 7/15.

I always thought it was setjmp.

https://en.wikipedia.org/wiki/Setjmp.h

setjmp isn’t really that ugly, IMO.

Yeah, low level and rare isn't the same as "bizarrely ripped from the design of another language"

C11 obscoleted this with the _Generic macro

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.

C11 doesn't obsolete it, right? It only permits it to be implemented portably.

For the curious, here's an implementation of tgmath.h on top of _Generic:

https://github.com/NuxiNL/cloudlibc/blob/master/src/include/...

Far from obsolete.. more is coming :)

'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/

(2005)

Discussed in 2011: https://news.ycombinator.com/item?id=3392728

Has C jumped the shark?

... and this is why I will never touch C++ and stay with simple C.

(Ah no..., wrong thread. This is actually about C. /s)

Reply on news.ycombinator.com