Sometimes I think C++ would be better off if the committee stopped accepting proposals that add new features.
C++20 Concepts: The Definitive Guide
11–20 of 102 posts
Re: C++20 Concepts: The Definitive Guide
#12Amazing that this took ~20 years to design and it still had to be rushed through to get into c++20…
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 creators is long forgotten now.
(If you want, you can still experience it with the Tiny C Compiler that seems to continue to understand K&R C code just fine.)
Re: C++20 Concepts: The Definitive Guide
#13Re: C++20 Concepts: The Definitive Guide
#14Concepts, 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.
Example: In C++ the floating point type "float" matches a concept std::totally_ordered. You can, in fact, compile code that treats any container of floats as totally ordered. But of course if some of them are NaN that won't work, because NaNs in fact don't even compare equal to themselves. You, the C++ programmer were responsible for knowing not to use this with NaNs.
Whereas, Rust's floating point type f32 implements PartialOrd (saying you can try to compare these) but not Ord (a claim that all of them are totally ordered). If you know you won't use NaNs you can construct a wrapper type, and insist that is Ord and Rust will let you do that, because now you pointed the gun at your foot, and it's clearly your fault if you pull the trigger.
This is a quite deliberate choice, it's not as though C++ could have just dropped in Rust-style traits, but I think a "Definitive Guide" ought to spell this out so that programmers understand that the burden the concept seems to be taking on is in fact still resting firmly on their shoulders in C++.
The other side of this is, if you wrote a C++ type say Beachball that implements the necessary comparison operators the Beachball is std::totally_ordered in C++ 20 with no further work from you to clear up this fact. Your users might hope you'll document whether Beachballs are actually totally ordered or not though...
I think this will likely prove to be a curse, obviously its proponents think it will work out OK or even a blessing.
Re: C++20 Concepts: The Definitive Guide
#15Amazing that this took ~20 years to design and it still had to be rushed through to get into c++20…
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…
You will enjoy Go.
Go can be understood as an improved, modernized C that doesn't abandon C's simplicity.
Re: C++20 Concepts: The Definitive Guide
#16Another 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.
Re: C++20 Concepts: The Definitive Guide
#17I 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…
[0]: https://en.cppreference.com/w/cpp/utility/compare/partial_or...
Re: C++20 Concepts: The Definitive Guide
#18Is 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…
One of clang’s stated goals is “expressive diagnostics” See https://clang.llvm.org/diagnostics.html ; that page is not dated, but compares to gcc 4.9, which is from April 22, 2014. gcc also has worked on improving its error messages (most likely because of competition with clang), so that comparison probably isn’t accurate anymore.
Re: C++20 Concepts: The Definitive Guide
#19Another 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.
I agree. Somewhere in the piled-high-and-deeper complexity of C++ there is one excellent, modern language that could be carved out.
Maybe it is only the subset since C++17.
Re: C++20 Concepts: The Definitive Guide
#20Another 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.