Upgrading c++98 code to c++11

Question

I have inherited a large c++ code base and have finally got it to compile and run on 64-bit Red Hat 7 (gcc version 4.8.5 20150623).

By default the makefiles in the project are compiling for c++98. I would like to turn on c++11 as that obviously provides many language benefits. g++ 4.8 has rather complete support for c++11.

My question is: What kind of risk does this introduce? What things do I need to watch out for? What type of things could break (besides things just not compiling)?

My google-foo is rather low on this because I've searched and just haven't been able to find any kind of analysis on this. (Maybe because their really isn't any risk, I just don't know.)

Answer 1

Just turning on -std=c++11 and nothing else should be fairly low risk. You may see some small speed improvements due to moves suddenly being performed where they previously couldn't be, but I doubt you'll run into any problems (unless the code contains undefined behaviour and gcc exploits that more agressively in C++11 mode - I don't know if it does).

As for modernizing the code you may want to look at clang tidy/clang modernize. But once you start to actually actively replace old working code with new modern C++11 versions, that is where you need to be really careful and make sure you got it right and fully understand both the code you are replacing as well as the new feature(s) you use to replace it.

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

See especially the 'modernize-*' checks: http://clang.llvm.org/extra/clang-tidy/checks/list.html

Answer 2

What kind of risk does this introduce? What things do I need to watch out for?

Not much usually, the current standard (c++14) seamlessly compiles older standards code.

What type of things could break (besides things just not compiling)?

You may see some warnings about deprecated stuff, like e.g. std::auto_ptr but it will still work correctly though.

---

You have to judge, if it's actually worth to refactor your older code, or just leave it as is.

If there may be improvement for interfaces using newer language features, you mey consider refactoring.