5 ms·

I've been saying this for quite a while - new C++ features seem to be added by people who don't actually use the language for any real job, or who do but who wi

I've been saying this for quite a while - new C++ features seem to be added by people who don't actually use the language for any real job, or who do but who wish they were using C# instead. I work in games development and the rate of adoption of new C++ features is incredibly slow. Only in the last couple of years it sort of became ok to use auto(although still frowned upon). Foreach loops are still out of the question though. I don't see the need for higher and higer and higher levels of abstraction in C++. If you need that then we just use C#.

jcelerier 5y ago
I mean, here is the tradeoff really bad ? The central point of this article is "c++ coroutines may allocate". Except Rust's, are there are a lot of languages where you can enforce that coroutines don't ? I'm confident that this is not the case for any JVM or .Net based-languages ; let's not even talk about Python or functional-ish languages. For me for instance, as bad as C++ coroutines may be, doing the same thing in C# than what I'd do in C++ is literally not even on the radar ; we just set a much higher bar for what is "good" in C++ which leads to a lot of depreciating-tone articles but one must not loose sight of the whole picture ; almost no coroutine implementation in the world sparks joy when the same criterion than this article uses is applied.
- gpderetta 5y ago
  Amen. As I said elsethread, what we got is better than nothing (and a huge amount of work was put in by Gor et al.). It is a shame we could have gotten much more.
snovv_crash 5y ago
C++ is trying to cater to every usecase. You don't need to use every feature, and if you move to a different field you may encounter different subsections of C++ usage. For example, C# doesn't run on 16bit microcontrollers, and many things in the language make it unsuitable for this. If you added this as another of the design constraints on C# then it would be more complicated for desktop application devs, or server devs. C++ handles all of these cases, so is necessarily more complex. IMO what C++ needs is compiler support for warnings when "old" bad practices are used, which would allow the language to remain flexible and backwards compatible, while still providing guidance for the future.
- pjmlp 5y ago
  Check netduino.
MauranKilom 5y ago
> Foreach loops are still out of the question though For real? What's the argument there? I've never seen anyone complain about range-for, so I'm curious what the perceived problem there is...
- gambiting 5y ago
  We use our own game engines which still use lots of custom containers which won't necessarily work with a for each loop. In the best case you will get a cryptic error message, worst case it will look like it's working but actually be very inefficient or crash(that's what happens when games programmers start overriding Count to mean something else depending on the usage basically). It's a self inflicted wound basically.
  - CodesInChaos 5y ago
    Doesn't foreach expand to the same `for(it = collection.begin(); it != collection.end(); ++it)` loop you'd otherwise write manually? Or are iterator based loops also avoided in that codebase?
- duped 5y ago
  My complaint is that it sucks to write your own iterators that can be used in a range-for loop, unlike rust where it is a single interface. You even have a standard library function that converts a closure into an iterator.
afranchuk 5y ago
This is sometimes evident in the standard library. I think they chose just about the most developer-unfriendly interface for `std::visit` of variants. Yes that interface covers some edge cases that I've _never_ seen in practice (visiting two variants at once??), and results in users writing ugly, verbose code. Then they proceeed to have an `overloaded` example on cppreference that's a useful template to at least make that more palatable for the common case, but naturally that's not in the standard library. It annoyed me so much I implemented what I consider the sane/common interface: `cvisit(variant, [](Type1) {...}, [](Type2) {...}, etc)`. Yes, I realize my usage might not match with everyone's, but from my own experience and code I've read, this covers almost every usage (visiting sum types).
- jcelerier 5y ago
  > Yes that interface covers some edge cases that I've _never_ seen in practice (visiting two variants at once??), heh, this was literally one of my first uses of C++ variants: that job needed a generic set of mathematical functions in a way that emulated a weaker type system (with automated conversions left and right), while preserving the original types as far as possible, and did meaningful conversions otherwise e.g. more-or-less using value = variant<int, float, string, vector<float>>; value clamp(value x, value a, value b);
  - afranchuk 5y ago
    Ah yeah numeric sort of variants totally make sense for that! In all of my use cases they have been types that don't have operations defined among each other. But really I'd just appreciate the standard library providing at least a convenience function for the common case over their more powerful but obtuse std::visit.
- gpderetta 5y ago
  See overload in the example[1] at cpp reference. overload is an extremely useful helper that it should be in any c++ programmer toolbox. [1] https://en.cppreference.com/w/cpp/utility/variant/visit https://en.cppreference.com/w/cpp/utility/variant/visit
adrian_b 5y ago
These 2 might not be the best examples, because "auto" and "foreach" are, without doubt, among the important improvements of C++ 2011. There are many other more obscure new C++ features, whose usefulness is doubtful. Having to write again the type, when the type is already provided by an initialization value, does not provide any kind of useful redundancy. The word "auto" is also redundant, but there is no way to eliminate it without breaking the traditional syntax. "foreach" also provides a long-needed simplification. It makes no sense to waste time with writing iteration limits and also expressions with either pointers or indices for accessing the elements of a data aggregate, when all these are things that the compiler knows better. When C (1974) introduced its more powerful "for" syntax, instead of the traditional "for" with arithmetic progressions, that was a partial mistake. The C "for" allows 2 features that were not available with traditional "for", assigning to multiple loop variables (using the comma operator) and other loop variable updating operations besides addition/subtraction, e.g. indirect addressing through pointer links. Nevertheless, these 2 features are needed infrequently, but the programmer is forced in 99% of the cases, when a simple "for" is needed, to write a lot of redundant information in comparison with the traditional "for" (e.g. "for i in 0 to 100 by 3 do" vs. "for (i = 0; i < 100; i += 3) {" ) (with traditional "for", the most frequent simpler loops can be written in a simplified way, e.g. "for i to 100 do", when the initial value is 0 and the increment is 1, while in the corresponding C "for" you can only replace "+= 3" by "++"). For the 2 special cases, a better syntax could be found, without altering the syntax for the common case. At around the time when C was developed, the concept of iterators was introduced in Alphard and CLU, which is a better solution than the extended syntax of the C "for". Introducing "foreach" in C++ 2011, has corrected a mistake dating from C 1974, by providing a simple syntax for the simple common case, so that the complex syntax can be used only when really needed. The correction is not total, because there still are many "for" loops that cannot be written with "foreach" but which C "for" is still an overkill, e.g. the loops that access multiple arrays. Nevertheless, not using "foreach" nowadays would be a weird choice (notwithstanding the fringe cases with RHS functions returning references to temporaries, which were discussed on HN some time ago).
- chrsig 5y ago
  In the average case, it's generally not an issue, but in a game loop, i could see it being a source of issues. It's really easy to make a mistake and accidentally make a copy of a reference, or obfuscate any conversions...which, I can imagine in the game engine world being quite a massive footgun.
nmeofthestate 5y ago
If c++ is being designed by people who wish they were using c# then at least we know the designers of c++ are a sensible bunch of folk :)
72deluxe 5y ago
Why is for-each out of the question? for(const thingy &x : myContainer) What's so illegal about that??? Are you also not writing your own move constructors and assignment operators?
- gambiting 5y ago
  Nothing is illegal about it, I'm just saying that in games our engines have tonnes of various containers, some of which don't work with a for each loop because they require iterators to be implemented and we don't have them, or containers which are containers but which aren't actually meant to ever be iterated upon. Again, there's nothing wrong about foreach loops in general. I'm just saying that in my industry and in the engines that we work with even the "basic" features of modern C++ are frowned upon for <reasons>.
  - 72deluxe 5y ago
    Very odd and amusing at the same time!

jcelerier 5y ago

I mean, here is the tradeoff really bad ? The central point of this article is "c++ coroutines may allocate". Except Rust's, are there are a lot of languages where you can enforce that coroutines don't ? I'm confident that this is not the case for any JVM or .Net based-languages ; let's not even talk about Python or functional-ish languages. For me for instance, as bad as C++ coroutines may be, doing the same thing in C# than what I'd do in C++ is literally not even on the radar ; we just set a much higher bar for what is "good" in C++ which leads to a lot of depreciating-tone articles but one must not loose sight of the whole picture ; almost no coroutine implementation in the world sparks joy when the same criterion than this article uses is applied.

gpderetta 5y ago
Amen. As I said elsethread, what we got is better than nothing (and a huge amount of work was put in by Gor et al.). It is a shame we could have gotten much more.

snovv_crash 5y ago

C++ is trying to cater to every usecase. You don't need to use every feature, and if you move to a different field you may encounter different subsections of C++ usage. For example, C# doesn't run on 16bit microcontrollers, and many things in the language make it unsuitable for this. If you added this as another of the design constraints on C# then it would be more complicated for desktop application devs, or server devs. C++ handles all of these cases, so is necessarily more complex. IMO what C++ needs is compiler support for warnings when "old" bad practices are used, which would allow the language to remain flexible and backwards compatible, while still providing guidance for the future.

pjmlp 5y ago
Check netduino.

MauranKilom 5y ago

> Foreach loops are still out of the question though For real? What's the argument there? I've never seen anyone complain about range-for, so I'm curious what the perceived problem there is...

gambiting 5y ago
We use our own game engines which still use lots of custom containers which won't necessarily work with a for each loop. In the best case you will get a cryptic error message, worst case it will look like it's working but actually be very inefficient or crash(that's what happens when games programmers start overriding Count to mean something else depending on the usage basically). It's a self inflicted wound basically.
- CodesInChaos 5y ago
  Doesn't foreach expand to the same `for(it = collection.begin(); it != collection.end(); ++it)` loop you'd otherwise write manually? Or are iterator based loops also avoided in that codebase?
duped 5y ago
My complaint is that it sucks to write your own iterators that can be used in a range-for loop, unlike rust where it is a single interface. You even have a standard library function that converts a closure into an iterator.

afranchuk 5y ago

This is sometimes evident in the standard library. I think they chose just about the most developer-unfriendly interface for `std::visit` of variants. Yes that interface covers some edge cases that I've _never_ seen in practice (visiting two variants at once??), and results in users writing ugly, verbose code. Then they proceeed to have an `overloaded` example on cppreference that's a useful template to at least make that more palatable for the common case, but naturally that's not in the standard library. It annoyed me so much I implemented what I consider the sane/common interface: `cvisit(variant, [](Type1) {...}, [](Type2) {...}, etc)`. Yes, I realize my usage might not match with everyone's, but from my own experience and code I've read, this covers almost every usage (visiting sum types).

jcelerier 5y ago
> Yes that interface covers some edge cases that I've _never_ seen in practice (visiting two variants at once??), heh, this was literally one of my first uses of C++ variants: that job needed a generic set of mathematical functions in a way that emulated a weaker type system (with automated conversions left and right), while preserving the original types as far as possible, and did meaningful conversions otherwise e.g. more-or-less using value = variant<int, float, string, vector<float>>; value clamp(value x, value a, value b);
- afranchuk 5y ago
  Ah yeah numeric sort of variants totally make sense for that! In all of my use cases they have been types that don't have operations defined among each other. But really I'd just appreciate the standard library providing at least a convenience function for the common case over their more powerful but obtuse std::visit.
gpderetta 5y ago
See overload in the example[1] at cpp reference. overload is an extremely useful helper that it should be in any c++ programmer toolbox. [1] https://en.cppreference.com/w/cpp/utility/variant/visit https://en.cppreference.com/w/cpp/utility/variant/visit

adrian_b 5y ago

These 2 might not be the best examples, because "auto" and "foreach" are, without doubt, among the important improvements of C++ 2011. There are many other more obscure new C++ features, whose usefulness is doubtful. Having to write again the type, when the type is already provided by an initialization value, does not provide any kind of useful redundancy. The word "auto" is also redundant, but there is no way to eliminate it without breaking the traditional syntax. "foreach" also provides a long-needed simplification. It makes no sense to waste time with writing iteration limits and also expressions with either pointers or indices for accessing the elements of a data aggregate, when all these are things that the compiler knows better. When C (1974) introduced its more powerful "for" syntax, instead of the traditional "for" with arithmetic progressions, that was a partial mistake. The C "for" allows 2 features that were not available with traditional "for", assigning to multiple loop variables (using the comma operator) and other loop variable updating operations besides addition/subtraction, e.g. indirect addressing through pointer links. Nevertheless, these 2 features are needed infrequently, but the programmer is forced in 99% of the cases, when a simple "for" is needed, to write a lot of redundant information in comparison with the traditional "for" (e.g. "for i in 0 to 100 by 3 do" vs. "for (i = 0; i < 100; i += 3) {" ) (with traditional "for", the most frequent simpler loops can be written in a simplified way, e.g. "for i to 100 do", when the initial value is 0 and the increment is 1, while in the corresponding C "for" you can only replace "+= 3" by "++"). For the 2 special cases, a better syntax could be found, without altering the syntax for the common case. At around the time when C was developed, the concept of iterators was introduced in Alphard and CLU, which is a better solution than the extended syntax of the C "for". Introducing "foreach" in C++ 2011, has corrected a mistake dating from C 1974, by providing a simple syntax for the simple common case, so that the complex syntax can be used only when really needed. The correction is not total, because there still are many "for" loops that cannot be written with "foreach" but which C "for" is still an overkill, e.g. the loops that access multiple arrays. Nevertheless, not using "foreach" nowadays would be a weird choice (notwithstanding the fringe cases with RHS functions returning references to temporaries, which were discussed on HN some time ago).

chrsig 5y ago
In the average case, it's generally not an issue, but in a game loop, i could see it being a source of issues. It's really easy to make a mistake and accidentally make a copy of a reference, or obfuscate any conversions...which, I can imagine in the game engine world being quite a massive footgun.

nmeofthestate 5y ago

If c++ is being designed by people who wish they were using c# then at least we know the designers of c++ are a sensible bunch of folk :)

72deluxe 5y ago

Why is for-each out of the question? for(const thingy &x : myContainer) What's so illegal about that??? Are you also not writing your own move constructors and assignment operators?

gambiting 5y ago
Nothing is illegal about it, I'm just saying that in games our engines have tonnes of various containers, some of which don't work with a for each loop because they require iterators to be implemented and we don't have them, or containers which are containers but which aren't actually meant to ever be iterated upon. Again, there's nothing wrong about foreach loops in general. I'm just saying that in my industry and in the engines that we work with even the "basic" features of modern C++ are frowned upon for <reasons>.
- 72deluxe 5y ago
  Very odd and amusing at the same time!