Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A quick primer on type traits in modern C++

internalpointers.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: A quick primer on type traits in modern C++

#31

Post by gumby »

skrebbel wrote: post #29
gumby wrote: post #26

Earlier quoted context omitted.

> …when sfinae opened the Turing hatch it doomed c++… I think that’s unfair. While “sfinae’ itself is a mouthful, what it says in practice is that template expansion observes the principle of “least surprise” which is inherently user friendly. You certainly don’t need to know the acronym, or even of the idea, to benefit from it. I stead, the developer won’t be presented with a confusing error message when the thing t…

I just learned about sfinae by googling it, so correct me if I'm wrong, but I think you're misreading the GP's comment. The argument is I think, that because sfinae effectively added an "if" statement to C++ templates, it made templates turing complete. It made it possible to write all kinds insane, undebuggable programs purely at compile-time, in the most terrible purely functional language imaginable. People did ex…

Any powerful language (lisp, c++) has plenty of sharp knives in its toolbox. My point was that this tool made it easier to write code that behaves the way the end user expects. Primarily library writers (c++ is full of weirdo constructs that I never use in my code but which people writing libraries use to valuable effect — and which make my code better). While people complain that “c++ has this hard to understand feature” the real question is “does that feature make writing user code easier” and the committee (in ‘17 and ‘20) I hunk have taken that approach.

Sure you can write spaghetti code, but you can do that in almost any language. And there are popular languages that had explici design goals of limiting expressiveness in the hope of reducing spaghetti code (Pascal, in its time, and go today). I consider it like a balloon: without that power you end up with more boilerplate and repeated code, which to me makes following the code harder. But other people reasonably disagree.

Re: A quick primer on type traits in modern C++

#32

Post by dirtydroog »

edflsafoiewq wrote: post #7
Jaxan wrote: post #5

Earlier quoted context omitted.

Two points. 1) Currently, the code could be written with normal overloading (one for int and one for unsigned). No traits required. 2) The current code relies on an implicit cast to int or unsigned int. I’m not sure that’s good.

> Currently, the code could be written with normal overloading (one for int and one for unsigned). No traits required f( (uint8_t)0 ) will dispatch to the overload f(int) with overloads. The type-trait code will dispatch to f_unsigned(unsigned).

I didn't believe you but you're right. The uint8_t gets promoted to int, not unsigned int.

https://godbolt.org/z/icQHw3

Re: A quick primer on type traits in modern C++

#33

Post by saagarjha »

dirtydroog wrote: post #32
edflsafoiewq wrote: post #7

Earlier quoted context omitted.

> Currently, the code could be written with normal overloading (one for int and one for unsigned). No traits required f( (uint8_t)0 ) will dispatch to the overload f(int) with overloads. The type-trait code will dispatch to f_unsigned(unsigned).

I didn't believe you but you're right. The uint8_t gets promoted to int, not unsigned int. https://godbolt.org/z/icQHw3

C’s integer promotion rules aren’t the best.

Re: A quick primer on type traits in modern C++

#34

Post by RossBencina »

skrebbel wrote: post #30
RossBencina wrote: post #10

I found the use of 'if constexpr' in the example pretty nasty. I would have thought it more idiomatic to use std::enable_if to enable different implementations of 'algorithm' as in the example of 'construct' and 'destroy' given here: https://en.cppreference.com/w/cpp/types/enable_if

Most of this is pretty new to me. Why is it nasty? It looks neat to me!

I consider it nasty (compared to the std::enable_if example that I linked) because it does not express the programmer's intent.

When you use enable_if to enable specific algorithm variants for specific trait predicates, you're saying "here is the specialised algorithm to use when this predicate is satisfied". Both the predicate and the algorithm code that relies on the predicate being satisfied are part of the template specialization definition. There's no chance of missing a precondition: it's stated right in the definition. Another advantage is that it's completely modular -- you can add or remove specializations at will.

On the other hand, the example in the post using 'if constexpr' wraps the algorithm in an extra layer of indirection (a generic wrapper) with a bunch of constexpr if-else spaghetti used to dispatch to the correct implementation. Even if the if-else spaghetti is pristine, the fact remains that the predicate and the specialized code that depends on the predicate as a precondition have been separated out into two independent code sites.

Re: A quick primer on type traits in modern C++

#35

Post by otabdeveloper2 »

skrebbel wrote: post #29
gumby wrote: post #26

Earlier quoted context omitted.

> …when sfinae opened the Turing hatch it doomed c++… I think that’s unfair. While “sfinae’ itself is a mouthful, what it says in practice is that template expansion observes the principle of “least surprise” which is inherently user friendly. You certainly don’t need to know the acronym, or even of the idea, to benefit from it. I stead, the developer won’t be presented with a confusing error message when the thing t…

I just learned about sfinae by googling it, so correct me if I'm wrong, but I think you're misreading the GP's comment. The argument is I think, that because sfinae effectively added an "if" statement to C++ templates, it made templates turing complete. It made it possible to write all kinds insane, undebuggable programs purely at compile-time, in the most terrible purely functional language imaginable. People did ex…

> ...all kinds insane, undebuggable programs purely at compile-time ... in the most terrible purely functional language imaginable

It's a clean, minimal, purely functional Lisp-like language. Nothing 'insane' or 'undebuggable' about it.

(Well, maybe if you're the kind of person who only ever coded Qt-style OOP C++98 in your life you might be shocked, but for the rest of us there is nothing surprising or special about C++ templates.)

Re: A quick primer on type traits in modern C++

#36

Post by TeMPOraL »

otabdeveloper2 wrote: post #35
skrebbel wrote: post #29

Earlier quoted context omitted.

I just learned about sfinae by googling it, so correct me if I'm wrong, but I think you're misreading the GP's comment. The argument is I think, that because sfinae effectively added an "if" statement to C++ templates, it made templates turing complete. It made it possible to write all kinds insane, undebuggable programs purely at compile-time, in the most terrible purely functional language imaginable. People did ex…

> ...all kinds insane, undebuggable programs purely at compile-time ... in the most terrible purely functional language imaginable It's a clean, minimal, purely functional Lisp-like language. Nothing 'insane' or 'undebuggable' about it. (Well, maybe if you're the kind of person who only ever coded Qt-style OOP C++98 in your life you might be shocked, but for the rest of us there is nothing surprising or special about…

Having worked a lot in both C++ and Lisp, I object to calling C++ templating "clean" and "minimal". C++ is a mess. I still love it though.

Re: A quick primer on type traits in modern C++

#37

Post by TeMPOraL »

skrebbel wrote: post #29
gumby wrote: post #26

Earlier quoted context omitted.

> …when sfinae opened the Turing hatch it doomed c++… I think that’s unfair. While “sfinae’ itself is a mouthful, what it says in practice is that template expansion observes the principle of “least surprise” which is inherently user friendly. You certainly don’t need to know the acronym, or even of the idea, to benefit from it. I stead, the developer won’t be presented with a confusing error message when the thing t…

I just learned about sfinae by googling it, so correct me if I'm wrong, but I think you're misreading the GP's comment. The argument is I think, that because sfinae effectively added an "if" statement to C++ templates, it made templates turing complete. It made it possible to write all kinds insane, undebuggable programs purely at compile-time, in the most terrible purely functional language imaginable. People did ex…

AFAIR Turing hatch was opened before SFINAE; I remember playing with early template metaprogramming examples as a kid (computing a factorial, etc.) which amounted to what the adult me now recognizes as Lisp's cond, that is generalized if-elseif-else. SFINAE only added more places into which you could shove compile-time conditionals.

Re: A quick primer on type traits in modern C++

#38

Post by TeMPOraL »

gumby wrote: post #31
skrebbel wrote: post #29

Earlier quoted context omitted.

I just learned about sfinae by googling it, so correct me if I'm wrong, but I think you're misreading the GP's comment. The argument is I think, that because sfinae effectively added an "if" statement to C++ templates, it made templates turing complete. It made it possible to write all kinds insane, undebuggable programs purely at compile-time, in the most terrible purely functional language imaginable. People did ex…

Any powerful language (lisp, c++) has plenty of sharp knives in its toolbox. My point was that this tool made it easier to write code that behaves the way the end user expects. Primarily library writers (c++ is full of weirdo constructs that I never use in my code but which people writing libraries use to valuable effect — and which make my code better). While people complain that “c++ has this hard to understand fea…

I think there's a point in rjeli's and skrebbel's comments though. This wasn't designed in from the get go; it started as a hack that got papered over with abstractions and accepted as a standard practice. Despite later improvements, the whole thing still has the aftertaste of a clever hack.

Using a modern example, the way template metaprogramming started feels like return-oriented programming, or those "MOV is Turing-complete" or "MPU error handling is Turing-complete tricks". Someone figured out the standard unintentionally lets you make a conforming compiler do computations, and it ended up becoming an accepted feature, instead of updating the language to something resembling modern constexprs, or Common Lisp's compiler macros.

Post reply on HN