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

61–70 of 102 posts

Re: C++20 Concepts: The Definitive Guide

#61

Post by contravariant »

godelski wrote: post #48
contravariant wrote: post #7

I guess this is somewhat besides the point but checking if something can be multiplied by -1 is not great as a definition of subtraction. You'll typically want to use the additive inverse directly. I mean sure you can extend any commutative group into a module over the integers but you probably don't want to make this a hard requirement just to have subtraction.

Why would this be an issue? I'm under the impression that this is fine if we're operating with the standard addition operator and the standard field that everyone is used to working under. Isn't that the definition of the inverse? I understand that in different fields you have different operators but is that relevant here?

If you were working with the standard field then why would you need to bother defining the general concept of subtraction?

If you want to define the concept of subtraction then you probably don't want to assume you can multiply elements with an integer. Not that it can't be done but in general it will be a lot easier to define the additive inverse directly (if one exists).

Re: C++20 Concepts: The Definitive Guide

#62

Post by quietbritishjim »

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.

I think that's the parent comment's point. Floats are not totally ordered but C++'s type system is weak enough that it appears they are.

Re: C++20 Concepts: The Definitive Guide

#63

Post by MauranKilom »

godelski wrote: post #48
contravariant wrote: post #7

I guess this is somewhat besides the point but checking if something can be multiplied by -1 is not great as a definition of subtraction. You'll typically want to use the additive inverse directly. I mean sure you can extend any commutative group into a module over the integers but you probably don't want to make this a hard requirement just to have subtraction.

Why would this be an issue? I'm under the impression that this is fine if we're operating with the standard addition operator and the standard field that everyone is used to working under. Isn't that the definition of the inverse? I understand that in different fields you have different operators but is that relevant here?

Random example: In geometry code, you might distinguish between points and vectors, where point + vector = point, point - point = vector etc.

It can then also be convenient to have a special type/value Origin, which (while functionally identical to point(0, 0)) allows you to e.g. write vector = point - origin to clearly express your intent of turning a vector into a point.

-1 * origin is not meaningful, but point - origin is (while point + origin is not).

Re: C++20 Concepts: The Definitive Guide

#64

Post by gompertz »

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…

I'm not sure how you drew a line from my discussion of c++98/11, to K&R C.

Re: C++20 Concepts: The Definitive Guide

#65

Post by AlexCoventry »

ncmncm wrote: post #44
AlexCoventry wrote: post #16

Earlier quoted context omitted.

Scott Meyers thinks similarly, I think. https://www.youtube.com/watch?v=KAWA1DuvCnQ

Scott Meyers was never a production coder. His schtick was teaching, and he got tired. The additions since he bowed out improve the experience of production coders.

He got tired because of the insane complexity of the language, and in the video I linked he supports his complaint with extensive and damning examples.

Re: C++20 Concepts: The Definitive Guide

#66

Post by creativeCak3 »

Am I going insane or does the following does NOT work(?):

template T mul(T a, T b) { return ab; }

template T mul(T a, int b) { std::string ret_val{std::move(a)}; a.reserve(a.length() b); auto start_pos{a.begin()}; auto end_pos{a.end()}; for(int i = 0; i

I knew it looked odd to me for some reason...I had to re-write it as follows:

template T mul(T a, T b) { return ab; }

template T mul(T a, int b) { std::string ret_val{}; ret_val.reserve(a.length() b); auto start_pos{a.begin()}; auto end_pos{a.end()}; for(int i = 0; i

Did I miss something??

Re: C++20 Concepts: The Definitive Guide

#67

Post by secondcoming »

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.

What use would that be to a C++ developer who doesn't know rust?

Re: C++20 Concepts: The Definitive Guide

#68

Post by secondcoming »

s-luv-j wrote: post #2

Is it just me, or have C++ errors gotten a lot better? Below example from guide seems a lot more ergonomic than in years past. test.cpp: In instantiation of ‘T add(T, T) [with T = std::basic_string ]’: test.cpp:17:21: required from here test.cpp:11:22: error: static assertion failed 11 | static_assert(std::is_integral_v ); | ~~~~~^~~~~~~~~~~~~~~~ test.cpp:11:22: note: ‘std::is_integral_v >’ evaluates to false Build f…

Yes. I had build failures related to LTO on our production code that uses gcc 7.5 (Ubuntu 18.04). I had to build it with gcc 9.1 (Ubuntu 20.04) in order to get a useful error message that saved me an hour or two of faffing about.

Re: C++20 Concepts: The Definitive Guide

#69

Post by godelski »

MauranKilom wrote: post #63
godelski wrote: post #48

Earlier quoted context omitted.

Why would this be an issue? I'm under the impression that this is fine if we're operating with the standard addition operator and the standard field that everyone is used to working under. Isn't that the definition of the inverse? I understand that in different fields you have different operators but is that relevant here?

Random example: In geometry code, you might distinguish between points and vectors, where point + vector = point, point - point = vector etc. It can then also be convenient to have a special type/value Origin, which (while functionally identical to point(0, 0)) allows you to e.g. write vector = point - origin to clearly express your intent of turning a vector into a point. -1 * origin is not meaningful, but point - o…

But in this case I don't think you're working on the standard field. I mean you're working in different coordinates. I do understand that the example only works in R1 space with standard addition, but that's kinda the point of my question. That the "error" isn't really an error unless you're being pretty pedantic.

Re: C++20 Concepts: The Definitive Guide

#70

Post by godelski »

contravariant wrote: post #61
godelski wrote: post #48

Earlier quoted context omitted.

Why would this be an issue? I'm under the impression that this is fine if we're operating with the standard addition operator and the standard field that everyone is used to working under. Isn't that the definition of the inverse? I understand that in different fields you have different operators but is that relevant here?

If you were working with the standard field then why would you need to bother defining the general concept of subtraction? If you want to define the concept of subtraction then you probably don't want to assume you can multiply elements with an integer. Not that it can't be done but in general it will be a lot easier to define the additive inverse directly (if one exists).

I mean but under the example that the author is doing they are working with standard integers (integrals). So this appears to me to still be the standard addition and subtraction. And with standard R1 subtraction it is the same as inverse of addition.

I mean if we move into different coordinates and different fields, then yeah things change, but I don't see what the issue is with the example given here.

Post reply on HN