There are, however, definitely wrong ways of doing things in C++. There's quite a few things in the STL that should have long since been deprecated if not outright removed.
Simple example is std::map. Absolutely horrible data structure. std::unordered_map is what you actually want, but to a beginner nothing really tells you that. You just think "I need a map, oh hey there's a std::map, perfect!" and go about your day completely unaware of how awful a data structure you just chose.
Another example that's a mistake made in C++ hello worlds of all things is std::endl. std::endl does not mean "end line", it means "\n + flush" (specifically '\n' - it does not do '\n\r' or '\r\n' conversions at all, the underlying file system does that). And flushing on every new line only makes sense for line-buffered things like std::out, but std::out already flushes on '\n' character. So std::endl in practice just leads to a ton of unnecessary & unexpected flushes.
> so you go with new, but if you don't want to deal with exceptions or just want a block of raw memory, you may want to go with malloc instead.
There's actually very little reason to ever use malloc. If you globally don't want exceptions just use -fno-exceptions. If you don't want exceptions in the small scope you're working in then use std::nothrow, eg: "new (std::nothrow) int[1024 * 1024]".
As for why you do this over malloc the reason is simple - it avoids overflow bugs. new int[size_t] never overflows. malloc(size_t * sizeof(int)) - well that overflows trivially, and that overflow results in security bugs.
Raw malloc would arguably be another case of "this is just wrong C++" rather than "this is a perfectly valid alternative". Raw free would belong in this case except for calloc, which is still very useful (and avoids the common overflow bug that malloc has). malloc's only saving grace is realloc, but now you're pretty deep into a specific edge case.
As for outdated stuff in the standard library, that's something that affects every language as it ages. `map`/`set` aren't, IMO, the worst offenders; they were misleadingly-named (like `std::endl` and `std::move`), but RB-trees are a useful data structure, and while they are slower than hash tables (`unordered_map`/`unordered_set`) for the typical map/set use case, it's not like they're buggy.
The one that IMO most cries out for replacement is `[std::]rand` (inherited from the C standard library), whose RNG is abysmally low quality/predictable, very slow, and thread-unsafe. C++11 did introduce a new RNG API[1], but it's quite cumbersome and verbose to use, when they really need to introduce a simple API like BSD/Mac `arc4random_uniform`[2] so people will stop using `rand`.
Edit: I see that this is being addressed, although it didn't make it into C++17.[3]
While not buggy, iostreams are also getting a bit long in the tooth and could stand to be replaced with a more modern API, the iterator APIs (in the <algorithm> and <numeric> headers, etc) should also be methods on STL types, and `std::string` isn't quite deprecation-worthy, but it would be nice if the STL were augmented with a state-of-the-art encoding-aware string implementation like Swift's. And it would be nice if the STL acknowledged the existence of the internet (with high-level libcurl-like functionality in addition to the very low-level Networking TS).
[1] http://en.cppreference.com/w/cpp/numeric/random
[2] https://www.unix.com/man-page/freebsd/3/arc4random_uniform
Also not sure what you mean when you say operator new never overflows. Can you elaborate?
It would be nice if C++ gave an operator new/allocator that put the object on the end of a page boundary so that the hardware could catch any overflows. Sort of like how the atomic operators are cross platform but hardware specific.
std::map is a red-black tree. It will have among the worst cache coherence of anything. Do you have any supporting benchmarks?
And if you have a small enough data set then std::vector will run circles around any map anyway.
> Also not sure what you mean when you say operator new never overflows. Can you elaborate?
size_t mySize = ...;
int* myptr = (int*) malloc(mySize * sizeof(int));
int* myptr2 = new int[mySize];
Hint: the malloc version has a security bug, the new one doesn't.
In any case, it's the multiplication that has a bug, not malloc (though I agree that the usage you mention is unfortunately common).
which is the default in python, you get awesome effects, where the order of the unordered dictionary is dependent on the random seed.
where library implementor are serializing a dict into a serial structure (and are not sorting by key). running the same code and same data twice, will get you potentially different results.
now here comes the best. most of the time in python you don't see the difference. the output is exactly the same but never the less the order is not guaranteed.
so I believe having an ordered by default data-store will help the ecosystem.
Calling it unordered explicitly helps, to make sure that anybody serializing the structure will need to make a choice how to sort it.
It's not a question of ordered vs. unordered, it's a question of red-black trees vs. a hashed array of some sort.
I challenge you to find a single correct use of std::map to begin with.
Is this severe enough to be worth breaking programs? No. But was it a mistake? Yes, absolutely. And deprecation is how mistakes are fixed over time, so why not fix the mistake? Old things can stay on their old STL and live with the old std::map. Maintained things will get warnings that they can go address in their own time. And new things are guided to the proper choice.
Before C++11, you only had std::map, so every use was correct. After C++11, you may still care about iterator invalidation or actually maintaining ordering. These properties are too useful to be deprecated.
As for beginners, their priority should be learning the core language and making a habit of browsing the std documentation to see what's there. Then they'll stumble upon unordered map too.
EDIT: as for cache coherency, std mandates use of separate chaining. If you really care about cache, you'll have to implement open addressing yourself.
There's no shortage of 3rd party map implementations. Nothing forced you to use std::map pre-C++11, so it still isn't correct to use std::map prior to C++11 it was just easier to use std::map prior to that.
If you need ordered access a hashmap + key list is a superior implementation to red-black trees, so std::map still loses there.
The only thing std::map does have is iterators stay valid during inserts, but this doesn't really seem useful and indeed it's something most maps in most languages don't have. Heck, Java's red-black java.util.TreeMap doesn't even bother to keep iterators valid during inserts even though it could. How is this a useful property in practice much less one "too useful to be deprecated"? Do you have any examples?
I mean, I wouldn't complain if with C++23 we introduce std2 and make things better. While we're at it, we could also try to fix std::list and std::deque which are nearly useless too.
Superior in what way?
> Do you have any examples?
It's a couple of years since, but I remember having relied on both ordering and iterator stability in certain algorithms related to topological meshes. Basically, I'd traverse a map and delete some elements during traversal.
Could I have done it in some way with a hash table? Yes. Would it have been more complicated? Yes.
Superior in performance, and you can pick if you want to optimize for iteration (put the keys in a sorted vector) or insertion (linked list). Either way you'll trivially beat traversing, inserting, and removing elements from a red-black tree in runtime.
> Basically, I'd traverse a map and delete some elements during traversal.
That works fine with unordered_map, too. You can keep the iterator when you remove. It's only inserts where map's iterators stays valid but unordered_map's doesn't.
I am now back into high-performance scientific computing, and I am glad to see C++ has evolved much, in pretty good ways. However, is it worth getting back into C++ when things like Julia and Rust are around? Or are these still too immature?
For me, as native companion to Java and .NET stacks, Rust still cannot take C++'s place regarding mixed debugging experience, IDE integration, GUI designers support, distribution of binary binaries and most important making team mates or customers (specially their IT) accept yet another tool into the projects.
For other people Rust is already mature enough and they are delivering production code with it.
In any case, until Julia and Rust stop using LLVM as their backend, being confortable with C++ is a good idea.
Julia seems ideal in some ways, as performance can be quite close to C / C++ / Fortran, while the code is more high-level. I don't care about GUIs, distribution, teamwork or maintenance.
Julia seems promising, and there are some nice usage stories already:
https://www.intel.com/content/dam/www/public/us/en/documents...
I am quite proficient with JVM-based stacks (Java, Scala & Clojure). But the level of performance, especially in terms of memory usage, cannot come anywhere close to C++.
As a longtime hater of C++, I do want to point out that this is one of my big issues with it. Every time I mention my various gripes with C++, I get the same response from the apologists: "Well, if you just do C++ the right way, that's not an issue"
Fine! Great! Then just tell me what the right way is! But no one can (or if they do, then someone else comes along and immediately tells them they're wrong). If there were some agreed-on idiomatic subset of C++ that avoided all the pitfalls, or even just a book that everyone agreed was "good", that would go a long way toward warming me on the language. But so far as I can tell, no such thing exists.
The core guidelines are working to be precisely that.
Also, `new`/`delete` aren't unidiomatic when strictly adhering to RAII and
- Writing exception-safe code (with the `new (std::nothrow) T` form).
- Writing custom smart pointers or data structures, or high-performance containers (especially with C++17 aligned `new`/`delete` and C++14 sized `delete`).
- Using memory pools (with placement `new`/`delete`).
`[std::]malloc`/`[std::]free` aren't necessarily unidiomatic either, such as
- When using a C API (or one in pre-standard C++ or a third language) which is incompatible with `new`/`delete`.
- When you need `[std::]realloc`, and for whatever reason a `std::vector` isn't an acceptable substitute.
- In embedded or other environments that don't provide a STL.
How do you think the std::vector is implemented under the hood ?
Also shared_ptr's make the ownership relation harder to understand. (Also there's additional synchronization cost for copying pointers.) Of course there are situations where you need them, but in general, I think it's better to avoid them.
You can write a kernel in C++, or you can do high level UI, or a game engine, and these will be very different, you can almost say you are using a different language.
For example, to allocate an array, you can use a vector, array, new, or malloc. Most people will tell you to use a vector, but a vector uses a bit more memory than an array, so you might want to use this instead, but you may not want to link with the STL at all, so you go with new, but if you don't want to deal with exceptions or just want a block of raw memory, you may want to go with malloc instead.
Just use the new features if it makes life easier for you, that's the idea. As for linters, I know that cppcheck can warn you of C-isms (ex : C-style casts) but I don't know any of them that target modern C++ variants.