A Perspective on C++ Standardization in 2018 | Hacker News Reader

A Perspective on C++ Standardization in 2018

thephd.github.io

76 pointsingve29 comments

The problem is that C++ is already too much bloated (in its complex rules and the standard library) and some people (primarily gamedev) would want things more to be removed, changed, and simplified rather than continuously added to the pile. But the philosophy of C++ standards development was always about adding new things while maintaining backward compatibility. So even if the gamedev people ask the committee to change its philosophy and remove the bloat, I feel that it would only result in tribal wars between developers and not constructive change.

So right now there are two kinds of gamedev: the ones who would suck it up and just use C++ (although not the modern one), or the ones who move to greener pastures. I've heard some gamedev people are moving to Rust (although having the potential to rival C++ in complexity, is nicer because of its fresher base). And Jonathan Blow is currently creating Jai, so maybe that could be a hope of light for gamedev people...

Maintaining backward compatibility is very important because C++ is used in many places for software that have very high development costs, since generally, C++ code that is written, doesn't get written to be thrown away, like I'm sure it's the case for other languages. Like it or not, C++ is much harder to write than other languages, so of course applications in php or js, since they are more easily written, can be tossed away since they're cheaper to write.

Breaking C++ backward compatibility would induce an immense cost on the industry.

New languages don't have that problem, obviously, and it's hard to see if they would have that problem if they would have the level of adoption of C++.

Not to mention that even if it's decided to break backward compatibility, it might be decided to do it not once, but several times, and it would further induce more costs.

C++ is also one of those languages that is used by many big companies, because it's actually well standardized (how many languages are that well standardized, and used for sensitive software, like C++ is). You don't have that many languages like this one.

Like always, "there are languages people complain about, and languages nobody uses".

Although I agree that things should be removed, but I honestly am not expert enough to understand which and why. Also those companies are still able to use their own compilers if they wish, and break compatibility if they want to.

So right now there are two kinds of gamedev: the ones who would suck it up and just use C++ (although not the modern one)

Why can't there be a third kind: the ones who suck it up and just use C++ including modern features? (honest question: I don't know anything at all about 'gamedev')

This is what probably 95% of us do. Don't like a C++ feature, don't use it. You can have a better C than C (at least for gamedev needs), or the bells and whistles from the functional languages. Yeah, some of them are ugly, but to be honest, after the first 5-6 times I see them, I no longer care.

Jon Blow says a language with less friction would make him much more productive. Let me tell you -- rockstar programmers at our company have tried that again, and again, and again. I spent the last 2 months trying to purge one such attempt from the codebase, because it ended up introducing all kinds of nasty bugs and unexpected limitations.

I still occasionally binge Jai videos and hope Jon proves my scepticism misplaced though :)

Using modern C++ with STL in gamedev is quite difficult because it results in atrocious compile times and slow debug build performance (For making a game, iteration speed and debuggability can be pretty important.) Also if you want to develop for consoles there are some limitations: most notably you are forbidden to use exceptions, and the platform's compiler usually doesn't even support the latest C++ standard...

That said, I think a third kind might also exist, although rare for AAA studios and more common with mid-size/indie game developers...

The compiler for Xbox one is MSVC which supports modern c++ quite quickly, and the compiler for PS4 is based on Clang which also supports modern c++ very quickly.

Exceptions are supported and we use them for any non-gameplay code paths. That is to say, you can and should use exceptions for all loading/initialisation paths unless they are during actual gameplay.

This ends up feeling quite natural as that is mostly what exceptions are good for, and honestly, they would practically never fire in a non-development scenario because they are almost always some kind of error in data files.

People have been talking about Jai for years. It’s always something everyone is looking forward to, but is anything actually happening with it?

There's been a pretty significant amount of progress, but it's all private, except for when Jon makes a video. So in some sense yes, but not anything that you can really try, yet.

A very thorough breakdown of the trials and tribulations of getting things through the C++ Standardization Committee.

The article leaves us with the advice that if we care what goes into C++, then, whether we like it or not, we'll need to get involved somehow.

This could mean joining things fully, or just communicating your needs to existing members who are aligned with you in some fashion.

Sadly, I don't think we'll see much of an uptick in C++ Standards participation in relation to C++ standards complaints.

  > Use C++98
  > Complain it's too simple to be expressive.
  > Get C++17
  > Complain it's too expressive to be simple.

Sometimes I think the real goal behind these complaints is not learning anything new or programming anything interesting.

Oh I absolutely love C++11, 14 and 17. It's just that there are always some really dumb parts that are shipped together with the good parts. Like mandatory begin and end iterators for list comprehension, iota, unreadable syntax of C++20 ranges, etc.

Well, one objective part I can see in these complaints, is that it seems to be hard to assemble a sufficiently big team of sufficiently qualified C++ developers, for what the project requires. C++ skills are scarce and expensive. This seems to be confirmed by my own experience in my waters.

And then people proceed to put all blame on the language alone, and this does not match the reality anymore. Again, in my waters.

What, precisely, are the warts that folks want to get rid of in C++ but cannot?

Depends who you talk to. Here’s one take by the great Scott Meyers:

http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in...

The preprocessor: Bjarne Stroustrup has been willing to get rid of it for a long time. C++20 modules are a step in this direction. However - as pointed out by John Lakos - you still need macros to build zero-cost logging facilities.

I don't think that's necessarily true, using constexpr facilities you could make a function do nothing according to a compile-time variable value

I agree ; however, the tricky part - I believe - is not computing the message string in case you're not going to print/record it.

Is IO allowed in constexpr functions?

I don't think so, but for zero-cost logging you just need the conditional for your branch to be constexpr. If the branch is known not to be taken at compile time, the compiler can just throw it away.

Something like:

  void MyDebugLog(text) {
    if (<constepxr check if logging enabled>) {
      // actually log...
    }
  }

Corresponding citation from John Lakos about why macros could be necessary: https://www.youtube.com/watch?v=K_fTl_hIEGY&t=3140

Just off the top of my head, it would be nice to remove std::initializer_list from the standard to make uniform initialization truly uniform, and to remove to the 'explicit' keyword to make it the default behaviour.

There's also stuff from C that can be surprisingly complicated, like integer promotion rules, but if you change that sort of thing you might as well design a new language from scratch.

The biggest one for me is the preprocessor. The preprocessor is THE reason C++ has such horrendous compilation times compared to basically any other language.

Others have mentioned uniform initialization, which I definitely agree with.

I believe templates make for slower compilation times.

These are one and the same issue. Templates have to be in headers and cannot be in source. The preprocessor requires that headers be repeatedly reparsed and recompiled. So, templates get repeatedly recompiled.

From my tiny spot on the metaverse, copy-paste compatibility with C's security flaws.

To what extent is the creator of C++ involved with its Standardization process these days?

He's the Evolution Working Group Chair. https://isocpp.org/wiki/faq/wg21#bjarne-stroustrup

And Chair of Direction Group in 2018. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p093...

He was previously. The current EWG Chair is Ville Voutilainen.

Reply on news.ycombinator.com