[=TDoro;156788]
@Krixa
C/C+ is not here for games, and was not made only for games dev. And is fast enough, if you want the ONLY fastest route over C/C++, go ASM and good luck with that finishing a game/application.
[/]
I was paraphrasing the cppcon talk above, and in it’s context.
I was not making a general statement - I agree that that would be silly…
At least from the perspective of the speaker in that talk, he basically only uses C-level features out of C++, and combines that with some ASM that he writes manually - you should really watch this talk, it’s quite different then most other conference-talks I have seen of late. He states up-front right at the beginning of the talk that writing in ASM exclusively is not an option, for obvious reasons that we all know. The question is thus, could there be a more ‘modern’ version of C that can replace C++ for game-engine writing. My guess is that this is starting to happen, with promising contenders like D and Rust. Just in terms of compile-time, nothing nowadays beets D as far as I know, and I think both D and Rust have support for in-line ASM block, so they just seem like a much better fit for next-gen game-engines.
But the reason I brought it up, is because I am learning ‘Modern’ C++ these days, and UE4 is the only game-engine that I know of that supports it (binary-compatible, due to it being developed and compiled in MSVC of VS2013), and I was really disappointed to discover that game-engines generally don’t use any high-level C++ language features, on the count of them being ‘too slow’… For example, I would have liked to see much less wide-spread reliance on ‘macros’, as they are not type-safe and are very difficult to debug (plus, most intellisesnse don’t work with them correctly, don’t auto-completes them, etc.). So, if you’re coding against a ‘practically C’ API, what’s the point of it supporting ‘Modern C++’? It makes it look like ‘vaporware’ - a false-promise on behalf of Epic… Sure, you ‘could’ use templates and such in your own code, and that’s cool and all, but it’s one thing to ‘consume’, say, the STL, but it’s quite another to consume a game-engine library/API that is written using templates (which it seems most game-engines don’t, including UE4). So, you also ‘could’ write your own templates and build your own library, but that is way overkill for what you ‘should’ be expected to do… Templates are for library-authors and API designers - the likes of the people who write game-engines - it is NOT intended (or rather shouldn’t be considered to be intended) for game-designers and game-logic coders. One would expect a Modern C++ game-engine to provide with high-level abstractions that are conveniently consumable by anyone wanting to code game-logic against that game-engine, and iterate on design-ideas quickly. Alas, it seems these high-level productivity-enhancing features of Modern C++ are too expensive for game-engine to design their APIs around, and the only thing that shields a game-developer from having to interface with a game-engines “C like” API (type-unsafe, leaky/dangerous, etc.), are a slew of ‘macros’ that are very unproductive to work with… This just comes as a very grossly unfortunate predicament for the games-industry, and I think that most game-developers know this reality and it’s frustration very well - which comes with sharp contrast to what ‘C++ Zealots’ (like here and others) are preaching to themselves and others…
The situation is much less rosy than the way it is being presented, and it just makes the whole story seem very disingenuous - is my general point.
NWN Lexicon
).