My opinion is that there is no "right way" of doing C++, unlike, say, python.

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.

> My opinion is that there is no "right way" of doing C++, unlike, say, python.

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.

Another reason to prefer `new`/`delete` over `[std::]malloc`/`[std::]free` (and `std::vector` over `[std::]realloc`) is that `malloc`/`realloc`/`free` don't call constructors and destructors, which means using them with non-POD types is UB (more concretely, you'll get bugs if the constructors or destructors manage some resource like a mutex, heap allocation or file handle).

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

[3] http://en.cppreference.com/w/cpp/experimental/randint

std::map will often have better cache coherence, especially if you're using a custom allocator or have a small data set.

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 will often have better cache coherence

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];

What happens when mySize is >= 1073741824 on a 32-bit system?

Hint: the malloc version has a security bug, the new one doesn't.

If mySize is computed at runtime, that computation should most likely be checking for overflow. If it is a constant, declare it constexpr and get a compile-time warning for the overflow.

In any case, it's the multiplication that has a bug, not malloc (though I agree that the usage you mention is unfortunately common).

Yes it's the multiplication that has the bug, but malloc makes that error common as you said. An API whose usage commonly has trivial security bugs is not a good API. new just wholesale avoids that common category of bugs, so why would you avoid it in favor of malloc? They do the same thing, one just does it safer.

Boost, loki, and I'm sure others have a "flat" map which is just an array backed ordered map. Slower insertions than the red-black map but because of the cache locality it's much faster overall.

actually, you should see the pain that you get when having unordered dictionaries by default.

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.

Even if you want ordered by default a red-black tree is a bad way to get it. JavaScript has ordered maps, but engines like V8 use things like this: https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tabl... instead.

It's not a question of ordered vs. unordered, it's a question of red-black trees vs. a hashed array of some sort.

In Python 3.6, dicts are now ordered.

it's an implementation detail. not guaranteed. :( which makes this even worse.

A beginner may use std::map without reading even the first sentence of its documentation and get a red-black tree when they thought they were getting a hash table. The program will work correctly, but have a Big O complexity log(n) greater than they thought. That's not a problem worth breaking all the programs that correctly use std::map.

> That's not a problem worth breaking all the programs that correctly use std::map.

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.

> I challenge you to find a single correct use of std::map to begin with.

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.

> 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.

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?

If we're just complaining about performance and third-party libraries are an in-scope solution, I don't see why anyone would settle for std::unordered_map. It trails on every hashmap benchmark. Chandler Carruth blames it on the C++ standard, which mandates chaining for collision handling.

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.

> If you need ordered access a hashmap + key list is a superior implementation to red-black trees, so std::map still loses there.

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 what way?

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 was quite invested in C++ 1998 back in the day, but didn't keep in touch with the language much after 2003.

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?

Depends on the use case.

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.

My use case is rapid development of new statistical methods.

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++.

> My opinion is that there is no "right way" of doing C++, unlike, say, python.

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.

> But so far as I can tell, no such thing exists.

The core guidelines are working to be precisely that.

Not precisely that. The Core Guidelines are great, but they're attempting to solve a subset of the issues, not all of the issues.

I'm just a hobbyist, but "new" and especially "malloc" are not "right way of doing C++". Use of array is non idiomatic either. Instead you should always aim for vector and smart pointer "factory" methods make_shared or make_unique.

I'd pretty strongly disagree with the notion that stack or static-allocated arrays (especially `std::array`) aren't idiomatic C++; rather it's (unnecessarily) allocating everything on the heap that's the anti-pattern, since it defeats the whole purpose (fast, fine-grained, deterministic memory model) of using C++ in the first place. (And implies lots of memory leaks and global state).

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.

> I'm just a hobbyist, but "new" and especially "malloc" are not "right way of doing C++"

How do you think the std::vector is implemented under the hood ?

I think what he's saying is that using `std::vector` is better than using pointers and `malloc` from the point of view of doing simple things. (Simple is not the right term but can't think of a better word). I mean 80% of times.

With that line of argumentation, why not use sbrk() or poke the syscall directly? :) I'd say prefer the safest, highest-level of abstraction that you can get away with. Which would generally mean std::vector over new/malloc.

I have no problem with the use of std::vector (in 90% of cases it is all you need), my problem is with the new trend of shunning any use of new/delete or naked pointers in modern C++.

Sure, dogma is not very useful. But when people ask "what should I use" saying "well, there are valid cases for everything" (like someone else in the thread basically did) does not help much either.

Sure but they are implemented by C++ specialists that work on this code all the time. I'd trust them to use malloc more correctly and bug free than I'd ever trust myself to do. As long as we're not talking embedded here I'd rather rely on work already done by experts than reinvent the wheel, perhaps poorly.

Umm, no. A vector allows you to dynamically change the length of an array. If you need it, then you pretty much need a vector (or some other kind of smart container). Otherwise, there's no reason to prefer a vector to C-style array.

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.

Your parent poster was probably referring to std::array.

Having worked with Python for 16+ years, I disagree that there's a "right way" of using Python, in any meaningful sense.

In practice people do tend to disagree less about what is good code and not in Python versus C++?

I don't think anyone could answer that question, except with anecdotes. Personally, I think there is plenty of room for disagreement about code "goodness" in Python, C++, or any other general purpose language.

There is ongoing work to have linters advice on the Core Guidelines items, which are considered the best practices.

https://github.com/isocpp/CppCoreGuidelines

For those that aren't aware, actually some of the input from Microsoft side was based in the work done with Midori and having System C# ideas applied to C++.

VC++ with the code checkers and clang with clang-tidy.

Not sure about the current state of gcc or other commercial C++ compilers.

Scott Meyers' Effective C++ books are really good for learning the "right way" to code C++. He has a good intro to c++11 and 14 too, https://www.goodreads.com/book/show/22800553-effective-moder...

Don't worry about not taking the time to properly learn C++ . It is a huge huge language and trying to learn it all at once from first principles will take you forever. Just try to do things in the most memory safe way possible.

I don't use C++ anymore - but Scott Meyers' books on C++ were the best investments I could have made back in the early 2000's. He focused on some real pain/productivity points of the language and standard library that made a huge difference in my approach to the problems I was working on.

Effective Modern C++ is a great book but it is in no way an intro to anything. It keeps with tradition of exposing the warts in C++ that you should know about but the issues covered in the newest one are very complex compared to the previous book and are not at all something that someone just learning the language or even just catching up on the newest standards should do.

If you want to catch up on C++11 and parts of C++14 I recommend Stroustrup's A Tour of C++.

I'd probably read the other Effective C++ books (even though they are dated now) before cracking open Effective Modern C++.

>Is there a C++17-exclusive compiler-flag? Or linters that inform you about outdated concepts? Some way to get rid of the backwards compatible cruft when writing new things.

clang-tidy might be the closest thing you're looking for:

http://clang.llvm.org/extra/clang-tidy/

There is another language that always gets mentioned in C++ posts and that languages has a tool called clippy which does what you want. It's dreamy.

CLion also has clang-tidy built in: https://blog.jetbrains.com/clion/2017/04/clion-2017-2-eap-cl...

Looks good. Jetbrains are doing a great job. Their vim keybindings are also complete enough for me. :)

That other language doesn't have that much outdated concepts as C++

This is a solid (and likely unintentional) pun.

We started our current codebase with a blank Emacs buffer back in February and went straight to (draft) C++17. Everything is compiled with both gcc and clang. Flags like -Wall, -Wpedantic -Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-c++11-extensions are your friends.

But apart from that, languages have “cultural dialects”. So for example I essentially always loop with for(;;) and so a while (or do while!) looks alien to me. Likewise, a destructuring bind is not the only way to unpack a loop variable, so no compiler would mandate its use.

It’s a large system programming language so it will take a while to learn a lot of nuances...but you can get a ton of great code written without learn8ng that stuff.

What's the justification for using for(;;) rather than a while loop?

That's an example of what I meant by "cultural dialect": I learned C in the context of the Unix sources so for(;;) was the canonical way to make an infinite loop. People who came from other "cultures" (e.g. Pascal, like many Mac programmers) used loop constructs common to them.

And it's not like I don't use 'while' -- in a bash script it looks normal to me -- it's just I would never even think to use one in C or C++. And when I read it it looks weird to me.

I realized two other reasons (I can't edit my comment any more):

- 'for' is simply my only looping construct. Now that C++ supports 'for(auto x : some_container) x.blahblah();' this is especially true.

- the old 'for(init; test; increment)' syntax put all your control right up front so as you read the code you already have in mind the range of when the body will run. A 'while(not_exit) { ... }' doesn't tell you that you're, say striding over the even elements or whatnot -- it's really just the equivalent of an open loop with an 'if(...) break;' somewhere in the body. And let's not get into the botch of 'do..while'

For an infinite loop, some people prefer it because the lack of a condition means it looks simpler than while(true), and therefore signals its meaning more effectively.

I'd be very surprised if there was any difference in terms of the generated code. Personally I use while(true).

There was a very interesting little side note in John Regehr's recent CppCon talk[1] on undefined behavior: Apparently, C11 added language that forbids compilers from eliding side-effect free infinite loops if they're of the form `while (<constant expression>)` but not other loop forms. C++ has not yet adopted this language, but it might in the future.

A strange choice by the committee I'd be interested in reading more about.

[1] https://youtu.be/v1COuU2vU_w?t=2327

Not a compilers guy, so when you say "eliding loops", do you refer to optimizing out loops that the compiler assumes are side-effect free?

Coming from an embedded background, the form "while (true) { // do nothing of interest }" is seen a lot in embedded code. If your code is interrupt driven, or running certain RTOSes, you would usually see this at the end of main(), since everything happens in interrupts. You might also see this in error handlers, and "unimplemented" interrupt handlers during development, as a way to trap the program without halting / resetting the system completely. If this kind of loop was optimized out / you returned-from-main on your embedded system, interesting and unintended things may happen.

While I've never had problems with these particular loops being optimized out (that I can remember!), I do remember having to do other vary silly hacks to try and tell the compiler not to optimize things out, because something is happening in hardware that it wasn't aware of, so I wonder if this is just a practical way of making sure that this kind of code keeps working with newer compilers, even in the face of aggressive optimization.

Yes, the C and C++ standards allow compilers to eliminate loops which have no side effects (It's actually slightly more tricky than this but whatever, check the spec for the exact details). This can be tough in situations like you say, but also in other places: for example, Rust's semantics do not allow you to elide them, but because we use LLVM, we incidentally inherited this behavior: https://github.com/rust-lang/rust/issues/28728

LLVM has since added a new intrinsic: https://reviews.llvm.org/D38336

This will allow us to fix the bug.

Yes, the optimizer is allowed to completely eliminate side-effect free infinite loops.

Example: https://godbolt.org/g/md86qX

for(;;) // hmm. No condition, that's the quirky syntax for infinite loop

while(true) // infinite loop! Red flag!

repeat // I have no idea what this will do.

For(;;) allows you to put the looping variable initialization, exit condition, and increment statement in the same line, so you easily get a clear idea of those three.

I don't know why this got downvoted; true, I was referring to the infinite loop case, but this is a legit (if not C++-specific) case of a benefit of for over while.

Likewise do...while is in retrospect, a mistake, because it documents the control strategy in a bad place from a humans-understanding-code point of view.

>I don't know why this got downvoted; true, I was referring to the infinite loop case, but this is a legit (if not C++-specific) case of a benefit of for over while.

Thanks gumby.

I simply didn't catch that they were referring only to infinite loops. I though they were debating the usefulness of while versus for, in general.

This is actually really troublesome, I coded a lot of c++ about 15 years ago. So initially I tend to write code thats old style. Googling samples is all over the place on what version its using. It would be nice if someone built a linter around this

True, but it happens to any language that has been long around.

I stopped following Python regularly around 2.2 timeframe and only use it occasionally as better shell scripts when on UNIX like systems.

If I was to actually build an application with it, I bet my code wouldn't be very up to date with 3.7 Pythonic code.

Look at the "modernize" checks in clang-tidy.

No, your best bet is to check cppreference.com to see when the method was introduced and learning from a recent enough book.

I guess if you set the compiler's standard flag to C++14 or C++11, etc. and it compiles without warning or error, then you are not using any C++17 features. How exactly this would be useful remains to be seen!

clang-tidy has a few 'modernize' type lints; it's far from comprehensive but it's something.

Another problem is it becomes harder and harder to understand the code written by others.