5 ms·

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

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.

AlexCoventry 5y ago
Scott Meyers thinks similarly, I think. https://www.youtube.com/watch?v=KAWA1DuvCnQ https://www.youtube.com/watch?v=KAWA1DuvCnQ
- ncmncm 5y ago
  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.
  - AlexCoventry 5y ago
    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.
    - ncmncm 5y ago
      His difficulties are characteristic of someone not seeking solutions to actual daily engineering problems, and instead getting lost in a maze of language lawyering. If you approach features in terms of how they can be useful when coding, almost all of his difficulties never arise, or are easily sidestepped. For working coders that becomes second nature.
heresie-dabord 5y ago
> Another language-changing paradigm added to C++ 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.
steveklabnik 5y ago
While on one hand, I hear you, but on the other, on some level, the design goes all the way back to 1994: https://programowaniezpasja.pl/wp-content/uploads/2019/05/Cpp_Concepts_-_complete_overview_-_Jakub_Cislo.pdf https://programowaniezpasja.pl/wp-content/uploads/2019/05/Cp...
in3d 5y ago
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.
- gumby 5y ago
  > 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 API changes?
  - ncmncm 5y ago
    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".
    - gumby 5y ago
      > 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.
FpUser 5y ago
C++23 vs C++20 seem to be less drastic. So maybe they will slow down to a slow trickle at some point ;)
- ncmncm 5y ago
  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.
gumby 5y ago
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). Second: often new features are for library writers, or are out there for library writers to use (e.g. coroutines, which probably will not be appropriate for many users before c++23, but pretty much need to be available for people to experiment with). Third: the new features tend to be additive. For example you don't need to use many of the stuff in <algoritm> -- stick to a for loop unless you want to take advantage of some new capability (e.g. policies, which are't ubiquitous). Concepts are the same way: they will improve error messages and reduce bugs, but if you don't use them your code will in 99.9% work just fine. When you see a very simple example that uses concepts, it's not surprising that the concepts don't really improve a simple add function -- the case is deliberately simple for explanatory purposes. Languages move forward. Even go recently caved and added in generics.
- gompertz 5y ago
  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.
  - ncmncm 5y ago
    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.
pjmlp 5y ago
Just like Java, VB and C# are getting theirs.
gpderetta 5y ago
Concepts have existed informally since the original C++ STL. For the last 25 years people have been trying to make them a language construct. The current design is the one compromise people could agree on while being implementable and backward compatible. I haven't used it much yet, but I would still say it is pretty good although far from a proper template type system.
jcelerier 5y ago
> 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)
otabdeveloper4 5y ago
Concepts are just nice syntactic sugar for stuff that already existed in the wild for decades, hardly "language-changing".

AlexCoventry 5y ago

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

ncmncm 5y ago
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.
- AlexCoventry 5y ago
  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.
  - ncmncm 5y ago
    His difficulties are characteristic of someone not seeking solutions to actual daily engineering problems, and instead getting lost in a maze of language lawyering. If you approach features in terms of how they can be useful when coding, almost all of his difficulties never arise, or are easily sidestepped. For working coders that becomes second nature.

heresie-dabord 5y ago

> Another language-changing paradigm added to C++ 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.

steveklabnik 5y ago

While on one hand, I hear you, but on the other, on some level, the design goes all the way back to 1994: https://programowaniezpasja.pl/wp-content/uploads/2019/05/Cpp_Concepts_-_complete_overview_-_Jakub_Cislo.pdf https://programowaniezpasja.pl/wp-content/uploads/2019/05/Cp...

in3d 5y ago

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.

gumby 5y ago
> 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 API changes?
- ncmncm 5y ago
  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".
  - gumby 5y ago
    > 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.

FpUser 5y ago

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

ncmncm 5y ago
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.

gumby 5y ago

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). Second: often new features are for library writers, or are out there for library writers to use (e.g. coroutines, which probably will not be appropriate for many users before c++23, but pretty much need to be available for people to experiment with). Third: the new features tend to be additive. For example you don't need to use many of the stuff in <algoritm> -- stick to a for loop unless you want to take advantage of some new capability (e.g. policies, which are't ubiquitous). Concepts are the same way: they will improve error messages and reduce bugs, but if you don't use them your code will in 99.9% work just fine. When you see a very simple example that uses concepts, it's not surprising that the concepts don't really improve a simple add function -- the case is deliberately simple for explanatory purposes. Languages move forward. Even go recently caved and added in generics.

gompertz 5y ago
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.
- ncmncm 5y ago
  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.

pjmlp 5y ago

Just like Java, VB and C# are getting theirs.

gpderetta 5y ago

Concepts have existed informally since the original C++ STL. For the last 25 years people have been trying to make them a language construct. The current design is the one compromise people could agree on while being implementable and backward compatible. I haven't used it much yet, but I would still say it is pretty good although far from a proper template type system.

jcelerier 5y ago

> 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)

otabdeveloper4 5y ago

Concepts are just nice syntactic sugar for stuff that already existed in the wild for decades, hardly "language-changing".