3 ms·
Here's a non inclusive list 1. Initialization Type foo = Type(FieldType()) Type foo = Type{FieldType()} Type foo = Type { .field = FieldType() }
by unlinked_dll 7y ago
Here'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
- unlinked_dll 7y ago>what would be the difference between a never-null unique_ptr and a reference ? Ownership. > all implementations do use atomic reference counting They do not. > exception is the standard way to report errors in C++ Not really, at least in practice. Many C++ developers do not use exceptions at all, with good reason. >turing-complete language can generate arbitrary things and is not immune to halting problem, news at 11 :p The point is that a relatively simple syntax error on behalf of the programmer generates an incomprehensible error message. This is just a comical example of that, and a lot of real world code using templates is full of opaque errors at the start. That said, concepts should help eventually.