5

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

LeviX
  • 3,096
  • 3
  • 28
  • 41
  • 2
    [Related question](http://stackoverflow.com/q/23047198/1782465). – Angew is no longer proud of SO Jun 22 '16 at 18:17
  • 4
    Take baby-steps, by first trying to build in C++03 mode, and fix potential errors and warnings. Then rebuild in C++11 mode, and again fix errors and warnings. Each of these steps are not that big, and C++11 is mostly backward compatible to C++03 which is mostly backward compatible with C++98. The big breaking things comes in the future C++17 which will remove some deprecated functionality. – Some programmer dude Jun 22 '16 at 18:18
  • The biggest thing to think about is that [`std::auto_ptr`](http://en.cppreference.com/w/cpp/memory/auto_ptr) has been deprecated, you should replace it with [`std::unique_ptr`](http://en.cppreference.com/w/cpp/memory/unique_ptr). – Some programmer dude Jun 22 '16 at 18:20
  • Very helpful @Angew ! – LeviX Jun 22 '16 at 18:30

2 Answers2

2

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

Jesper Juhl
  • 30,449
  • 3
  • 47
  • 70
  • 1
    This is exactly what I would like to do @Jesper Juhl . I want to also compile with clang and use some of their tools for analysis. – LeviX Jun 22 '16 at 18:34
1

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

Not much usually, the current standard () 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.

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190