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

91–100 of 102 posts

Re: C++20 Concepts: The Definitive Guide

#91

Post by tialaramex »

volta83 wrote: post #87
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…

Rust traits are opt-in, C++ concepts are opt-out; you can think of C++ concepts as having a "blanket" implementation for all types, so you'd need to opt out using negative reasoning. For example, in C++, you can declare a trait: template struct totally_ordered : std::false_type {}; and opt-in implement it for some types, but not for floats. Then you can define a TotallyOrdered concept that requires the trait. The C++…

I think this might have been a better way to explain it than my attempt (since it looks like that confused some readers). However, you say C++ concepts are "opt-out", how does a Class opt out ?

If your Delicious concept mistakenly applies to my Desert, how do I as the author of the Desert tell C++ "No, no, when people ask if a Desert is Delicious tell them it isn't?".

Re: C++20 Concepts: The Definitive Guide

#92

Post by OskarS »

CogitoCogito wrote: post #41
jeffbee wrote: post #38

Earlier quoted context omitted.

-0.0 and +0.0?

Are those floats actually distinct? I mean you could represent 3.0 + 4.0 = 7.0 as well. Are "-0.0" and "0.0" actually different? (This is a serious question I honestly don't know.)

As other users mentioned, the most relevant part is when you divide by 0, you get different infinities depending on if you're dividing by +0.0 or -0.0. But even beyond that: the binary representation of floating point numbers [1] necessarily means that there are two values for zero with distinct bit patterns.

Floating point numbers have a dedicated sign bit that specifies the sign, which means that you can flip the sign of any floating point number and get a float with a different bit pattern (and opposite sign). That means that you get necessarily get both +0.0 and -0.0, and they have different internal representation in bits.

This is one of the major advantages of two's complement notation for representing integers: it doesn't have a dedicated sign bit in the same way, so you only get one representation for 0. You can still check the sign by looking at the top bit, but if you flip it for the number 0, you don't get -0 (which doesn't really exist), you get -128 (for 8 bit signed integers).

[1]: https://en.wikipedia.org/wiki/Double-precision_floating-poin...

Re: C++20 Concepts: The Definitive Guide

#94

Post by agumonkey »

pjmlp wrote: post #46
agumonkey wrote: post #23

Earlier quoted context omitted.

clang kinda started the race

And now lags behind in C++20 support, as apparently not everyone is keen to upstream whatever they are doing. Clang concepts were implemented by one guy. https://cppcast.com/saar-raz-clang-hacking/

Strange

Re: C++20 Concepts: The Definitive Guide

#95

Post by ncmncm »

FpUser wrote: post #36
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.

C++23 vs C++20 seem to be less drastic. So maybe they will slow down to a slow trickle at some point ;)

C++98 was big. C++11 was big. C++20 was big. Probably expect C++29 to be big.

Nine to twelve years seems like it should be enough time to adjust.

Re: C++20 Concepts: The Definitive Guide

#96

Post by ncmncm »

gumby wrote: post #71
in3d wrote: post #25

Earlier quoted context omitted.

It’s true that C++ is huge but the complaint should be about the lack of epochs that would let us simplify the language instead of about very useful new features such as concepts, modules, or constexpr. If you’re already programming in C++ and you can’t take a few days every 3 years to learn about new additions, you’ll have even more problems with other languages.

> but the complaint should be about the lack of epochs Rather than something as coarse as epochs, C++ includes a lot of fine grained feature test preprocessor definitions such as (to pick one at random) '__cpp_lib_constexpr_algorithms'. It's harder to make this work with breaking API changes of course. I assume non-preprocessor versions that work with modules will be available in C++23...and perhaps they will support…

Epochs would be more usable. Nobody can afford to litter their code with hundreds of feature tests.

API changes that change semantics are forbidden in Standard interfaces, although APIs can be extended, backward-compatibly. To make an actual change, we need to introduce a new name. Thus, when we get around to modernizing std::vector, the fixed version will have a different name, maybe std::vec, but conceivably std2::vector.

I don't know of any plans for feature test macro analogs that would integrate with modules.

To be usable, epochs would have to apply locally to a file, not to anything #included into that file, nor to any file #including it. And, it should be possible to tie them to modules, to say "you can use this module only from code in epoch C++XX or later".

Re: C++20 Concepts: The Definitive Guide

#97

Post by ncmncm »

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.

This is correct. The expression tested in the concept definition should not be "-1*x", but "x-x".

Re: C++20 Concepts: The Definitive Guide

#98

Post by pjmlp »

agumonkey wrote: post #94
pjmlp wrote: post #46

Earlier quoted context omitted.

And now lags behind in C++20 support, as apparently not everyone is keen to upstream whatever they are doing. Clang concepts were implemented by one guy. https://cppcast.com/saar-raz-clang-hacking/

Strange

Actually not that strange.

Apple doesn't really care about C++20. Their LLVM efforts are focused on Objective-C and Swift.

C++ as used on Apple platforms is mostly related to the Metal Shading Language (a C++14 subset) and IO/Driver Kit (an Embedded C++ variant).

Google has their style guide, only recently updated to C++, isn't a compiler vendor and apparently losing on the ABI vote has made several employees move away from their clang involvement.

Then the other vendors like Intel, Embarcadero, IBM, Codeplay, Sony, Nintendo, ARM, NVidia, AMS have their own agendas and do not upstream everything.

Re: C++20 Concepts: The Definitive Guide

#99

Post by gumby »

ncmncm wrote: post #96
gumby wrote: post #71

Earlier quoted context omitted.

> but the complaint should be about the lack of epochs Rather than something as coarse as epochs, C++ includes a lot of fine grained feature test preprocessor definitions such as (to pick one at random) '__cpp_lib_constexpr_algorithms'. It's harder to make this work with breaking API changes of course. I assume non-preprocessor versions that work with modules will be available in C++23...and perhaps they will support…

Epochs would be more usable. Nobody can afford to litter their code with hundreds of feature tests. API changes that change semantics are forbidden in Standard interfaces, although APIs can be extended, backward-compatibly. To make an actual change, we need to introduce a new name. Thus, when we get around to modernizing std::vector, the fixed version will have a different name, maybe std::vec, but conceivably std2::…

> Thus, when we get around to modernizing std::vector, the fixed version will have a different name, maybe std::vec, but conceivably std2::vector.

Let us hope that if such a name transition ever happens that the hideous plague of multi-case identifiers does not infect the standard. Leave that to (a subset of) user code.

Either std26::vector or std::vec would work for me. `std26::vec` would probably be better because of possible confusion (as to which vector implementation is desired) due to use of `using` directives.

Re: C++20 Concepts: The Definitive Guide

#100

Post by gumby »

ncmncm wrote: post #96
gumby wrote: post #71

Earlier quoted context omitted.

> but the complaint should be about the lack of epochs Rather than something as coarse as epochs, C++ includes a lot of fine grained feature test preprocessor definitions such as (to pick one at random) '__cpp_lib_constexpr_algorithms'. It's harder to make this work with breaking API changes of course. I assume non-preprocessor versions that work with modules will be available in C++23...and perhaps they will support…

Epochs would be more usable. Nobody can afford to litter their code with hundreds of feature tests. API changes that change semantics are forbidden in Standard interfaces, although APIs can be extended, backward-compatibly. To make an actual change, we need to introduce a new name. Thus, when we get around to modernizing std::vector, the fixed version will have a different name, maybe std::vec, but conceivably std2::…

> I don't know of any plans for feature test macro analogs that would integrate with modules.

What is the plan, if any, for deciding at compile time whether the format module is available or if I would still have to use fmtlib/fmt?

Post reply on HN