A quick primer on type traits in modern C++

https://www.internalpointers.com/post/quick-primer-type-traits-modern-cpp

by tblr • 6 years ago

118 34 6 years ago

That was an excellent article, thank you.

eps• 6 years ago

algorithm_signed() and algorithm_unsigned() in the conditional compilation example need to be templated functions for the example to make (more) sense.

saagarjha3• 6 years ago

Is algorithm being templated not enough?

Jaxan• 6 years ago

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.

RossBencina2• 6 years ago

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

jcelerier2• 6 years ago

I found the use of 'if constexpr' in the example pretty nasty.

For new code it is to be preferred - it generates less symbols than enable_if, compiles faster (by a noticeable margin from my own experience) and makes for more readable code as you don't have to go look everywhere for the various enable_if cases.

gpderetta3• 6 years ago

Enable if is fine if you have mutually exclusive choices (although the way it work is pure magic), but it quickly becomes very complex for overlapping cases as you have to somehow hack the partial ordering in. A chain of constexpr if is significantly easier to write and understand.

The right solution are of course concepts.

skrebbel3• 6 years ago

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

RossBencina2• 6 years ago

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.

rjeli2• 6 years ago

The amount of background knowledge you need to understand what’s happening here... I don’t envy people who have to catch up

becoming more and more convinced that when sfinae opened the Turing hatch it doomed c++

jcelerier2• 6 years ago

I think that it's pretty easy if you just consider that what's happening between `template<` and `>` is a simple LISP whose values are types.

rjeli2• 6 years ago

more like a prolog with obtuse syntax and complicated semantics

AlexCoventry• 6 years ago

Scott Meyers' next Effective C++ is going to be a doozy. Is it even possible to usefully categorize all the edge cases anymore?

jchb• 6 years ago

Scott Meyers has retired from C++ (his own blog post: http://scottmeyers.blogspot.com/2015/12/good-to-go.html?m=1) so the next C++ bible has to come from somewhere else. Maybe he saw it coming :)

Nursie• 6 years ago

It just looks kinda wrong to me - If your generic template has to switch on what type it's been passed, surely you've made it too generic somewhere? Adding back conditional compilation or execution afterwards strikes me as the same sort of code-smell as checking if something is an instance of a given class before then casting it and calling a member - you've lost information and using some sort of reflection to get it back looks like poorly thought out code. Sure, there are times when you more or less have to, but you ought to try to avoid them.

But what do I know, I haven't done C++ for about 5 years and was never that into it.

ahartmetz• 6 years ago

I have an example for you. A serialization library that supports container classes. It has a generic way to fill lists (vectors), but not all list containers support resize and default-initialize new elements. So somewhere inside a generic template function there is a switch to use or replicate that function.

gpderetta3• 6 years ago

You do not switch on types, you switch on groups of tuoes having certain properties. It is not a new thing this sort of thing has been doable for the last 20 years in a form or another.

gumby3• 6 years ago

Think of it the other way around: there’s a generic method/template, but the developer has a special implementation for a specific case. The compiler already does this for things like memmove() that is properly aligned and sized; this allows user code to cleanly do the same thing.

p0nce• 6 years ago

traits + "constexpr if" replace SFINAE.

gpderetta3• 6 years ago

You often need sfinae to implement the trait itself, but concepts (and the 'requires' keyword itself) will finally get rid of sfinae.

saagarjha3• 6 years ago

The amount of background knowledge you need to understand what’s happening here...

Not a whole lot, actually. You can go from C to this in about a week if you’re focused. (I did this a few years ago when learning C++. Now if you want to talk about initialization, that’s a whole ‘nother story…)

tomnj• 6 years ago

You don’t need sfinae to get Turing completeness of templates. Template specialization (a crude form of pattern matching) is the main driver for Turing completeness. For example, here’s a toy project to implement a subset of scheme lisp in templates which needs no sfinae: https://github.com/tdp2110/TmpLisp

lenkite• 6 years ago

I seriously don't understand this. I am a developer learning Modern C++ and this article was perfectly clear to me. I was using `enable_if` before, but the new `if constexpr` does make things clear and idiomatic.

gumby3• 6 years ago

…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 they want to happen is supported but not the first possibility examined.

skrebbel3• 6 years ago

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 exactly that, which went fine until their colleagues (or users of open source libraries) did something unexpected and got screenfuls of errors.

Wikipedia's sfinae page has a nice story about how it added compile-time introspection and conditionals to the language: https://en.wikipedia.org/wiki/Substitution_failure_is_not_an...

skrebbel3• 6 years ago

I'm not sure, I last coded C++ about 8 years ago and that was all C++03, yet I had no trouble to follow along.

I mean, even if you never saw a "constexpr" before, isn't it pretty clear from the example and the name, well, "constexpr" want's going on? Same for the other newish C++ features.

I thought it was a nice little primer.

A quick primer on type traits in modern C++

Related Stories