C vs C++ ... or whatever language

[Daytona675x]

@Einstein
Well, the whole C/C++ syntax is pretty perverted...
Actually I find the &-reference-syntax to be quite consistent with other C syntax madness (e.g. try to explain the * madness to a C (or C++) student )
It's just a matter of getting used to it, some practice, nothing else.

[Einstein]

@Einstein
Well, the whole C/C++ syntax is pretty perverted...
Actually I find the &-reference-syntax to be quite consistent with other C syntax madness (e.g. try to explain the * madness to a C (or C++) student )
It's just a matter of getting used to it, some practice, nothing else.

Yes, both '*' and '&' already serve more than 1 usage, references only add yet another usage to '&'.

[kamelito]

@Dayntona, Hand & Thor
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer. Check his YouTube channel or better ask him directly on Twitter.
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?

[guest11527]

It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?

Unfortunately, that seems to be correct and fits my experience. There is the Stroustrup, but even though it is the standard reference, I would not generally recommend the book because it is too big and tries to be too much at the same time. There are certainly very good C++ books around (I liked "Exceptional C++" by Herb Sutter a lot), but not a single one that covers all of C++ and that is "entry level". Probably because there is more than one way how a good C++ program may look like, and there is more than one way how C++ can be ideally used.

Concerning the STL: I also tend to agree, despite people advocating it. I find the STL bulky, and needlessly hard to use, and prefer my own data structures. But this is probably only a "me" thing, and because C++ makes it so easy to come up with your own structures. For example, in Java, I happily use the standard java classes like ArrayList and friends.

My C++ style looks more like "C with classes plus template-enabled super-powers". But that is exactly what I like about the language: Nobody forces me to use the parts of the language that do not quite fit to my application domain (which is, these days, mostly image processing/signal processing related).

[Daytona675x]

@kamelito

I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer

You are wrong if you think that the one (shipping successfully) must have any relationship to the other (being a good or bad C++ programmer / the game's code quality (and I know exactly what I'm talking about )).
Again: if somebody claims that it's the fault of the programming language XYZ that he didn't get his job done in time, then that's a very very strong indication that this guy simply is no good in language XYZ or that he chose the wrong tool for the job in the first place (which also makes him a non-expert for XYZ automatically) or that the true reasons are others.

It seems that not a single C++ book did a good job teaching how to program properly in C++

You simply picked the wrong books it seems.
To get you started pretty much any C / C++ for dummies book should do.
After you have practiced and have become more or less familiar with it, then I recommend the following pretty thin and to the point books:
"Effective C++" line of books by Scott Meyers. If you understood those, then go for
"Modern C++ Design" by Alexandrescu and finally
"C++ Templates" by Vandevoorde / Josuttis.
Those guys really know what they are talking about!
Yes, some of those books / chapters are tough stuff, without doubt. But that's how it is with a language that offers such a high amount of features and possibilities to exploit. It's no Kindergarten, and if you think that you can master C++ just like that, then you're mistaken.

Why big games companies need to wrote their own STL implementation to have good performance?

Most likely most of them don't.
However, the STL is made to be a standard for every day use. Which also means it is made to perform well in the avg. usecase.
It's a shoe that should fit okay, it's not a shoe that you can expect to always fit *perfectly*, especially not in corner cases or your very very specific scenario X.
But actually it's in *no way* different with the C standard library, e.g. the whole 0-terminated-C-string functions: okay for small stuff, but insanely slow and inefficient in other usecases. Or qsort: okay for many cases, but useless as soon as you need a stable sort (yes, yes, before somebody starts nitpicking: it's an example and I asume that you cannot just make the comparison function stable :rolleyes: ).

[Mr_Capehill]

@Dayntona, Hand & Thor
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer. Check his YouTube channel or better ask him directly on Twitter.
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?

Which game companies rewrite the STL lib in 2015-2018? What exactly was the reason?

Something like std::vector is as fast as the C array.

C++ is a complex topic, that cannot be denied. But C++ today is also quite different to what it used to be. Check constexpr, auto, unique_ptr and ranged-for...

[Mr_Capehill]

"Effective C++" line of books by Scott Meyers. If you understood those, then go for
"Modern C++ Design" by Alexandrescu and finally
"C++ Templates" by Vandevoorde / Josuttis.

Yay for mentioning Scott Meyers! Can't go wrong with his advice.

Check also ETL: https://github.com/ETLCPP/etl

[Hans_]

@Dayntona, Hand & Thor
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer. Check his YouTube channel or better ask him directly on Twitter.
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?

In no way was I slagging off any particular developer's skill. I simply disagree with claims that C++ is so horrible that people "suffer from" it.

I'm sure that Jon Blow is a competent programmer, and I like his games (got The Witness). I also wish him well with developing his own programming language. After taking a quick look at his new language, it's pretty clear that he's spent some time tinkering with Haskell...

He may well be able to make some innovative improvements over existing languages, creating one that suits his programming style and game development well. However, like every programming language ever written, it's highly likely that his language will solve the shortcomings that frustrated him with other languages, but end up with a new set of compromises and limitations. Others will get frustrated with how it can't do certain things they want as easily as they'd like, and they'll start dreaming about creating their own programming language...

Hans

[guest11527]

Something like std::vector is as fast as the C array.

Actually, when I tested, it was not. There is another layer of indirection, and at least the GNU C++ compiler is not good at removing the overhead even in optimized mode. There is also the "valarray", but that is neither any faster. Yes, it almost all cases it does not matter. But if you do raw signal processing, then the best C++ offers you is the raw pointer (well, except if you have compiler intrinsics for vectorized operations, of course), and this particular case, it does matter.

The C++ vector shows also what I do not like about the STL. If I would design a library, then operator[] of the vector would be range-checked by default, there would be no "at" function (which is range-checked). In optimized mode, the range-change would disappear, and it would run into an assert in debug mode if I'm out of bounds, but it would not throw an exception. What is not right here is that the default mode is "unsafe", and that "exceptions" are used to capture "programming defects" for which we have assertions, and that checked/unchecked is a decision of the function, but not of the compilation mode.

[nicholas]

@Kamelito

A good workman never blames his tools is as true today as it was in the bronze age.

[kamelito]

Which game companies rewrite the STL lib in 2015-2018? What exactly was the reason?

Something like std::vector is as fast as the C array.

C++ is a complex topic, that cannot be denied. But C++ today is also quite different to what it used to be. Check constexpr, auto, unique_ptr and ranged-for...

Performance was the reason, EA for example their implementation is now open source.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

[kamelito]

Which game companies rewrite the STL lib in 2015-2018? What exactly was the reason?

Something like std::vector is as fast as the C array.

C++ is a complex topic, that cannot be denied. But C++ today is also quite different to what it used to be. Check constexpr, auto, unique_ptr and ranged-for...

Reasons explained in the link below, EA for example their implementation is now open source.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

[bison]

https://www.youtube.com/watch?v=rX0ItVEVjHc
https://www.youtube.com/watch?v=443UNeGrFoM

Thanks for that second link; I probably never would have found it otherwise.

[Mr_Capehill]

Performance was the reason, EA for example their implementation is now open source.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

Posted in 2007.

But hey, the more the merrier. People can use STL, ETL, EASTL or roll their own. It's just a toolbox, not religion.

[Mr_Capehill]

Actually, when I tested, it was not. There is another layer of indirection, and at least the GNU C++ compiler is not good at removing the overhead even in optimized mode. There is also the "valarray", but that is neither any faster. Yes, it almost all cases it does not matter. But if you do raw signal processing, then the best C++ offers you is the raw pointer (well, except if you have compiler intrinsics for vectorized operations, of course), and this particular case, it does matter.

What sort of test case? I have used std::vector to take care of memory management and just passed the pointer (myVector.data()) to OpenGL, for example.

[guest11527]

What sort of test case? I have used std::vector to take care of memory management and just passed the pointer (myVector.data()) to OpenGL, for example.

In that case, of course, the speed is quite the same. No, I'm talking about a wavelet filter, in particular. No "pointer access", but then access to vector elements by operator[]. That is slower than doing it by pointers directly, even though, in principle, the compiler could optimize everything away. In reality, it does not.