3 ms·
You can't fix C++ because the only thing there is to fix is to get rid of all the legacy baggage but doing that would break backwards compatibility (including p
by simias 7y ago
You can't fix C++ because the only thing there is to fix is to get rid of all the legacy baggage but doing that would break backwards compatibility (including probably compatibility with C) which means that it's not C++ anymore.
"Fixed" C++, per your description, already exists. It's called D. It's called Rust. It's called C#. It's called Go.
Meanwhile there appear to be many people who (I must admit much to my puzzlement) seem to still enjoy writing C++ and want to add even more features and paradigms to it. I wish them good luck and I'll be sure to look at the results from afar and see if I can recognize some bits of the C++ I used to write 15 years ago. Oh! I think I saw an "if"!
- blub 7y ago"It's called D. It's called Rust. It's called C#. It's called Go" All of these languages with the exception of D are completely different. It's like saying you fixed a cupboard by replacing it with a sofa. D's the most similar, but it's sadly not exactly a hot language or one where there's jobs available.
- bluejekyll 7y agoWas the cupboard being used as a sofa?
- The_rationalist 7y ago* rid of all the legacy baggage * It keeps being repeated over and over but where can I find such a list? There's almost no misfeature in c++. It's issues are just the fact it's too low level / manual.
- 72deluxe 7y agoHow is it too manual compared to eg C# where I need to implement IDisposable and wrap use of variables in "using" to really ensure something is cleaned up when I want it cleaned up (without risky memory ballooning relying on the GC)? C++ destructors to clean up your resources are really neat. And deterministic - you know when stuff is going to get cleaned up. Or was it some other "manual" feature that's too much of a burden? Honestly curious.
- Leherenn 7y agoI don't have a list, but initialisation is quite a mess and the syntax inconsistent. That would be one of the first thing I would fix in C++.
- unlinked_dll 7y agoHere's a non inclusive list 1. Initialization Type foo = Type(FieldType()) Type foo = Type{FieldType()} Type foo = Type { .field = FieldType() } 2. std::unique_ptr can be null 3. std::shared_ptr does not guarantee atomic reference counting 4. std::variant and std::optional require exception handling. 5. std::map should be the std::unordered_map data structure, while std::ordered_map should be the special case. The unordered_map should also stop being a terrible hashmap implementation on most platforms. 6. std::vector<bool> is not what you think it is under the hood 7. Explicit should mean the opposite when it come to single argument constructors (meaning implicit casting needs to be explicitly enabled in the constructor definition) 8. Although on that point, one could argue that implicit casting should be a different operator overload than constructor definition. 9. There needs to be a mechanism to check the validity of a template argument before the template is expanded (concepts will fix this, iirc) 10. https://codegolf.stackexchange.com/questions/1956/generate-the-longest-error-message-in-c https://codegolf.stackexchange.com/questions/1956/generate-t... 11. It should be trivial to implement an std compliant iterator. It is not: https://stackoverflow.com/questions/8054273/how-to-implement-an-stl-style-iterator-and-avoid-common-pitfalls https://stackoverflow.com/questions/8054273/how-to-implement...
- jcelerier 7y ago> std::unique_ptr can be null what would be the difference between a never-null unique_ptr and a reference ? > std::shared_ptr does not guarantee atomic reference counting is that a problem in practice ? all implementations do use atomic reference counting. Just because it's not written in the standard does not mean that common sense does not apply. > std::variant and std::optional require exception handling exception is the standard way to report errors in C++ > std::map should be the std::unordered_map data structure, while std::ordered_map should be the special case. The unordered_map should also stop being a terrible hashmap implementation on most platforms. Anyone who has a problem that calls for caring between unordered_map and map will know the difference, and for everyone else, does it matter ? My opinion on that is that standard library types do not really matter - I use 3 different non-standard map implementations for specific use cases in one of my apps and there is zero friction as maps are almost always an implementation detail, it is nigh uncommon to e.g. have an API that takes / returns maps. > std::vector<bool> is not what you think it is under the hood that depends on who you ask :p from past teaching experience, if you ask students to tell you what is vector<bool> they will tell you that it is packed because it feels like the logical thing to do. > https://codegolf.stackexchange.com/questions/1956/generate-t.. https://codegolf.stackexchange.com/questions/1956/generate-t.... turing-complete language can generate arbitrary things and is not immune to halting problem, news at 11 :p
- jcelerier 7y ago> Meanwhile there appear to be many people who (I must admit much to my puzzlement) seem to still enjoy writing C++ and want to add even more features and paradigms to it. I enjoy C++. My general approach to programming is that you should make a domain-specific language to express your problem, and then solve it in that DSL. C++ is a good tool for that when you also need deterministic performance guarantees. So any "new feature" that allows me to write more expressive DSLs is welcome.