Quote: Original post by MrCoolsman
Third, if your code is taking a while to compile, turn off optimizations and debugging support.
This is a total non-option for most production projects in the game industry. You either need debugging support for finding code issues, or you need optimizations so you can actually play the damn game at a reasonable framerate.
Quote: Fourth, template error hell. Yep, that's the price you pay for a Turing-complete generics system. Of course, it didn't need to be that way. Would you have preferred generics the same way C# and Java do it? Or have the power to do the things that Boost does all the time? Everything's a choice.
I'm with incin on this one - Lisp-style macros/compile-time metaprogramming is a far superior option. Granted, C++ was created when that kind of hackery wasn't reasonable for resource and performance reasons, but that's no reason not to explore alternatives.
This is in fact one of the major goals of Epoch.
Quote: Fifth, an import system. Personally, there isn't much difference between "#include <somelib.h>" and "import somelib;". You still have to have the path set correct, which is where most of the pain comes from.
I strongly disagree.
In my experience, much of the pain comes from the fact that #includes are essentially mechanical versions of copy/pasting code between files. This can lead to all kinds of subtle problems if you do something naughty in a header, like use a using declaration.
The other big source of pain in C++ is the inability to use a class without having its definition visible in each translation unit. If we had a real module system, we could write code once instead of splitting between a definition in a header and a redundant copy of the interface in the .cpp implementation file. This kind of thing made sense in the 1970's when memory was scarce and holding every module of a large program in RAM during compilation was a non-starter. In 2010, it's fucking stupid.
Quote: Sixth, intellisense. Yup, it sucks. Nothing I can say about that.
We had a big discussion awhile back on why exactly this is. The bottom line is that the C++ grammar is so idiotically hard to parse that building reliable incremental parsers for it is very, very difficult. This is the real source of faster and more informative syntax completion and similar features in languages like C#, or even Java.
Quote: Seventh, concurrency. Every imperative language fails at it.
Again, this is a problem that we are directly (and I daresay successfully) attacking in Epoch.
Quote: Eighth, memory management. The fact that I can overload global new and control memory allocation in critical situations is a plus. However, those instances are few and far between, so there isn't much of a reason to have that feature in other languages.
Except it means that we can't implement things that do need manual memory management, unless we blend C++ and Some Other Language. This is messy, impractical for many projects, and difficult for most programmers (believe it or not). Keeping everything within a unified, single-language framework makes a lot of sense. Once again, see Epoch.
Quote: Ninth, data types. The standard type uint32_t is guaranteed to be 32 bits. This is no longer a portability issue.
Except as you noted the bulk of C++ code is actually legacy stuff anyways, which predates uint32_t. If the language had been standardized on type sizes to begin with (which would have made it useless for portable systems programming back in the day and so arguably would have been a bad decision at that time) then these problems wouldn't have arisen.
