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

C++20 Concepts: The Definitive Guide

thecodepad.com

Post reply on HN
Print view View original

51–60 of 102 posts

Re: C++20 Concepts: The Definitive Guide

#51

Post by jcelerier »

banachtarski wrote: post #34
tialaramex wrote: post #14

I feel like one of the things a "Definitive Guide" to this feature needs to make clear, and maybe even emphasise, is a key way these are different than say Rust type Traits. Concepts, just like the SFINAE and constrexpr hacks you should discard in their favour, are about only what will compile and you, the C++ programmer, are always responsible for shouldering the burden of deciding whether that will do what you mean…

How can floats be totally ordered. This isn’t even a matter of NaNs or not. A set of floats where two or more floats compare equal does not permit a total ordering.

IEEE754 provides a total ordering algorithm actually, but it's not used when you do double a, b; ... a < b

Re: C++20 Concepts: The Definitive Guide

#52

Post by jcelerier »

nrclark wrote: post #11

Another language-changing paradigm added to C++. I haven't even finished learning the old ones yet. Sometimes I think C++ would be better off if the committee stopped accepting proposals that add new features.

> Another language-changing paradigm added to C++

no, people were writing "concept-like" code since C++98 in a very bloated way with e.g. sfinae, this is just standardizing existing practice (while improving it of course)

Re: C++20 Concepts: The Definitive Guide

#53

Post by ncmncm »

gompertz wrote: post #43
gumby wrote: post #37

Earlier quoted context omitted.

I think there's more to it (changing the language) than you are crediting it. First, you don't have to use the new features (though eventually you'll be reading the code of people who did, so this is only half-valuable). There is new c++11 code being written every day -- in volume (a hard to pin down amount) it's sadly more than 50%. The usage surveys don't really capture this clearly (and it's not clear they could).…

I think you hit it on head, that most new features are for library writers who need to capture every edge case succinctly. As someone who has used c++98 and only a little c++11, for nearly 15 years, and writes no libraries; I've had little real need for any new features.

The less you use the new features, the less benefit you get from them. You could stick to K&R C and get no benefit at all, but that would be equally as foolish as what you are doing.

The new features are there to improve your experience, and to make your code more reliable. When you have a choice between old and new, new is usually better.

Sticking to K&R, you would have as many bugs and crashes as other K&R code. Sticking to modern C++ makes most of such bugs impossible. That is progress.

You can stop learning and take up complaining at any time, as you have done.

But you can also start learning again at any time. Now is always a good time for that.

Re: C++20 Concepts: The Definitive Guide

#54

Post by ncmncm »

gmueckl wrote: post #24
eeegnu wrote: post #13

Something about type constraining auto just seems funny. I can see how it's useful from an error minimization / code clarity standpoint, but it almost seems counter to the point of even using auto.

I belive that you do not sufficiently understand the giant footgun that is unconstrained auto, especially in the context of very template-heavy code. Concepts solve the issue that judicious use of auto will allow template instantiations to succeed that are plain wrong in that they will happily do the wrong thing just because the types involved fit the constraints by mere chance and not because they were meant to be u…

Unconstrained auto is unwise in globally accessible templates that participate in overload resolution, but is fine in lambda literals.

Re: C++20 Concepts: The Definitive Guide

#55

Post by [deleted] »

ncmncm wrote: post #40

The most important thing to say about this "definitive guide" is that it delays to the end presenting the overwhelmingly most important detail about Concepts: how to use them. The right place to put a concept name, in production code, is in place of "typename" in a template definition, or even better in place of "T" in the function argument declaration. That is, instead of template T add(T a, T b) requires addable (…

[deleted]

Re: C++20 Concepts: The Definitive Guide

#56

Post by robocat »

tialaramex wrote: post #33
svalorzen wrote: post #17

Earlier quoted context omitted.

Are you sure about this? In my tests floating points are always considered partially ordered, not totally ordered. This page [0] even mentions this in the notes towards the bottom. [0]: https://en.cppreference.com/w/cpp/utility/compare/partial_or...

Note that std::totally_ordered is a concept (this topic is about "C++ 20 Concepts: The Definitive Guide") whereas you're talking about std::partial_ordering which is a class, also introduced in C++ 20. Specifically these ordering classes are the result of the spaceship operator and the concept doesn't care whether you have a spaceship operator.

spaceship operator: Good article on the C++20 three-way comparison operator: https://devblogs.microsoft.com/cppblog/simplify-your-code-wi...

Re: C++20 Concepts: The Definitive Guide

#57

Post by CodeMage »

tialaramex wrote: post #14

I feel like one of the things a "Definitive Guide" to this feature needs to make clear, and maybe even emphasise, is a key way these are different than say Rust type Traits. Concepts, just like the SFINAE and constrexpr hacks you should discard in their favour, are about only what will compile and you, the C++ programmer, are always responsible for shouldering the burden of deciding whether that will do what you mean…

> I feel like one of the things a "Definitive Guide" to this feature needs to make clear, and maybe even emphasise, is a key way these are different than say Rust type Traits.

> Concepts, just like the SFINAE and constrexpr hacks you should discard in their favour, are about only what will compile and you, the C++ programmer, are always responsible for shouldering the burden of deciding whether that will do what you meant even if you have no insight into the types involved.

To be fair, that's not what makes them different from Rust. Unless there's something in Rust that I missed, it offers no guarantees that the implementation of the trait is consistent with its semantics.

Whether it's traits or concepts, it's still about compile-time type-checking, not actual contracts.

Re: C++20 Concepts: The Definitive Guide

#58

Post by CodeMage »

ncmncm wrote: post #40

The most important thing to say about this "definitive guide" is that it delays to the end presenting the overwhelmingly most important detail about Concepts: how to use them. The right place to put a concept name, in production code, is in place of "typename" in a template definition, or even better in place of "T" in the function argument declaration. That is, instead of template T add(T a, T b) requires addable (…

> Most often it is not necessary, and not wanted, to enforce a and b having the same type.

That really depends on what you're trying to do. Presenting these two different declarations as somehow equivalent is very misleading and I'm glad that the author didn't do that.

Re: C++20 Concepts: The Definitive Guide

#59

Post by robocat »

ncmncm wrote: post #53
gompertz wrote: post #43

Earlier quoted context omitted.

I think you hit it on head, that most new features are for library writers who need to capture every edge case succinctly. As someone who has used c++98 and only a little c++11, for nearly 15 years, and writes no libraries; I've had little real need for any new features.

The less you use the new features, the less benefit you get from them. You could stick to K&R C and get no benefit at all, but that would be equally as foolish as what you are doing. The new features are there to improve your experience, and to make your code more reliable. When you have a choice between old and new, new is usually better. Sticking to K&R, you would have as many bugs and crashes as other K&R code. St…

You don’t know what domain the person you are answering works in, so you cannot make such sweeping statements. Implying someone is foolish is plain rude. https://news.ycombinator.com/newsguidelines.html

Re: C++20 Concepts: The Definitive Guide

#60

Post by throw_m239339 »

37ef_ced3 wrote: post #15
Koshkin wrote: post #12

Earlier quoted context omitted.

You can take K&R C from my cold, dead hands. There was no header file hell. Often you didn't need a single header to be included in your code: most functions returned int (or nothing), and if you needed something that returned double, you could just say so. I remember being excited about function prototypes, but something was irretrievably lost at that point. The primal elegance of C as it was conceived by its creato…

I think you're trying to say you like C but dislike C++'s complexity. You will enjoy Go. Go can be understood as an improved, modernized C that doesn't abandon C's simplicity.

> Go can be understood as an improved, modernized C that doesn't abandon C's simplicity.

This is false, because Go has a garbage collector by default. This isn't an "improvement" in anyway but for those who don't care about memory management and predictable and deterministic performances.

Post reply on HN