8

I am learning C++, and trying to write good code. I am currently using a lof of compiler flags, such as

-Wextra -Wall -pedantic -Werror -Wfatal-errors -Wcast-qual -Wcast-align -Wconversion -Wdouble-promotion -Wfloat-equal -Wshadow -Wpointer-arith -Weffc++ -ansi -Wstrict-aliasing

I have just learned that keywords new and delete should not be used anymore in C++11. However, I do not have any warnings when I use them.

Is there some flags to use to ensure a good C++11 style?

Tom Cornebize
  • 1,362
  • 15
  • 33
  • 11
    *I have just learned that keywords new and delete should not be used anymore in C++11.* Where have you read that? Are you sure you understood it right? You're discouraged to use raw pointers where you'll have to worry about freeing a ressource later on. You can't really avoid using `new` and `delete` and there's no reason to do so. You may hide using `new` behind a call such as `std::make_unique()` or `std::make_shared()`, but behind the scenes those are just wrapped calls to `new`. – Mario Oct 05 '14 at 08:14
  • 7
    @Mario: modern C++ does not really need to use `delete` often at all, many applications would be best served by never calling it directly (and rarely calling `new`). You're right to question whether the OP's issue is pure dogma, but `delete` in application code is a red flag these days. However, with so much library code being in headers in modern C++, there is also the fact that `delete` may appear to the compiler even when the user has not written it. That's the tricky thing about warnings--most compilers don't discriminate between "your" code and "their" code. – John Zwinck Oct 05 '14 at 08:26
  • @Mario the point is that *you* should never use them, some library does. – o11c Oct 05 '14 at 08:27
  • `delete` is indeed a red flag. `delete[]` is an even more red flag. More generally, any sequence of the type "1) acquire a resource, 2) do something, 3) release resource" should encapsulate 1 and 3 into a constructor/destructor, because if 2 fails, then 3 is automatically executed. Memory management is a special case, which is typically handled by standard library classes. – Alexandre C. Oct 05 '14 at 08:27
  • @Mario [Here](http://scrupulousabstractions.tumblr.com/post/37576903218/cpp11style-no-new-delete) and [here](http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/-Not-Your-Father-s-C-?format=html5) for instance. As you said, you are discouraged to use raw pointers. This is why I am looking for flags which would throw warnings when using raw pointers. – Tom Cornebize Oct 05 '14 at 08:30
  • Wouldn't expect any specific flag for that, especially considering there are use cases where you're forced to use raw pointers (like circular dependencies). – Mario Oct 05 '14 at 08:39
  • Isn't `-Wall` enough? – GingerPlusPlus Oct 05 '14 at 08:56
  • 1
    @GingerPlusPlus It does not provide all the warnings. So, it may not be enough, depending of what you want. – Tom Cornebize Oct 05 '14 at 09:05
  • Incidentally, I just noticed you included `-Wfatal-errors`, which is most likely going to be harmful; it doesn't change *what* is an error, just whether it keeps trying (see also `-fmax-errors=` for a more general limit). Usually you *want* to be able to see more than one error without recompiling everything (but more than, say, 20, may start losing usefulness). – o11c Oct 06 '14 at 19:04

1 Answers1

5

First, you have to realize that your compiler is never going to completely enforce good style.

However, there are two techniques that you can use for the compiler to help you enforce your own style: warnings (which can be passed on the command line or in pragmas) and poison pragmas.

It is difficult, however, to manage the exact set of warnings that are available with each compiler version, so I made a list of warnings. Note that support for clang is minimal, its warnings are usually inferior to gcc's in practive, despite their fantastic marketing; additionally it is impossible to detect which version of clang you are using to work around bugs (feature detection macros are rather worthless).

I also made a list of poison.

Additionally, I have some makefile magic that ensures that the above two techniques are applied to every applicable file as well as doing some other checks.

It should be noted, however, that every application has different needs, so these headers should not be used as is. Very few applications, for example, would want to poison std::string like I did.

o11c
  • 15,265
  • 4
  • 50
  • 75