7

We are working on a module that is developed in C++, but given the new C++11, I am thinking about migrating to that.

How to proceed? Are both the same or is there some compiler dependency?

My software currently supports Windows and Linux. I am using Microsoft Visual Studio as well as GCC to build it.

Overall, what changes are needed if any?

jogojapan
  • 68,383
  • 11
  • 101
  • 131
Amit Kumar
  • 93
  • 2
  • 8
  • 2
    You won't know what changes are needed until you start porting. Most likely, no changes will be needed, but you may obtain benefits (often avoiding allocate/copy/free cycles) by using taking advantage of things like perfect forwarding, emplacement, and so on. – David Schwartz Jun 02 '13 at 07:37
  • 4
    Unless you were using `auto` keyword as storage duration specifier (it's been changed to be used for type inference in C++11) I don't think you'll have to change anything. – jrok Jun 02 '13 at 07:37
  • 1
    I know `C++ 11` is backward compatible with new feature's.But is there any specific change's example compiler versions? – Amit Kumar Jun 02 '13 at 07:39
  • Related: [Migration to C++11](http://stackoverflow.com/questions/10040686/migration-to-c11) – jogojapan Jun 02 '13 at 07:40
  • You only need to worry about specific compiler versions when you know what features you want to use. As far as I am aware, there is no feature complete compiler out there yet (but this should change in the near future). – juanchopanza Jun 02 '13 at 07:40
  • 3
    There aren't many breaking changes, but watch out for string literals with GCC. `"This happened on "__FILE__" in "__FUNCTION__""` and similar macro expansions will break, you need to put spaces between your quotes and your defines; `"This happened on " __FILE__ " in " __FUNCTION__ ""` or gcc barfs. – kfsone Jun 02 '13 at 07:53
  • @juanchopanza Clang claims to be feature complete as of april.21.2013: http://blog.llvm.org/2013/04/clang-support-for-c11-and-beyond.html – justin Jun 02 '13 at 10:59
  • 3
    @justin clang 3.3 is scheduled to be out in a few days. I also saw that [gcc 4.8.1](http://gcc.gnu.org/ml/gcc-announce/2013/msg00004.html) has been released. It is claimed to be feature complete. – juanchopanza Jun 02 '13 at 11:01
  • Beware of Visual Studio and its compiler (msvc) when using some C++11 specific features, many aren't implemented yet. – teh internets is made of catz Jun 02 '13 at 11:53

4 Answers4

9

Old C++ will work with your C++11 Compiler

  • Reviewing how you use iterators (maybe you can move to range-for)
  • Review if you use function pointer (maybe you can use lamdaes)
  • Review Class Initiators (maybe you can write initialization list)
  • Review your pointer use (maybe you can switch to SmartPtr)
  • Review your use to NULL with pointer maybe you can move to nullptr
Baget
  • 3,318
  • 1
  • 24
  • 44
  • Well written old C++ will *probably* work the same with a C++11 compiler. There are still a few breaking changes, even if you don't have any undefined behavior. It is important to test everything thoroughly, to ensure that everything still works as expected. – Jørgen Fogh Feb 17 '16 at 21:23
2

The compiler issues are few and easy to work through. It's far easier than adopting a new compiler. If you have the choice, stick with the std lib you use now, then update the std lib after your programs compile as C++11. You may need to stick with older versions of the library if loading dynamically.

If you want to take advantage of new features, have a look at cpp11-migrate. This tool can automate adoption of some of the new features for you when you are also ready to fully commit to c++11 (assuming your compilers support all those features).

justin
  • 104,054
  • 14
  • 179
  • 226
2

Migration? I thought WG21 fought hard to preserve all the compatibility. Unless you used export you do not need migration, existing code is fine.

I guess you really meant the question for refactoring the existing code to pick up C++11 features. Here I'd apply the general wisdom about refactoring -- never do it without a proper goal and value-based motivation.

Just that new shiny features got introduced does not impose technological debt on your code.

I suggest you start using new features in new code, and apply more liberal changes it where you refactor for different reasons anyway. And start thinking in general reshape only when having multiple styles is considered a real pain. (The multi-paradigm nature of C++ normally should allow quite much freedom, and force uniform approach only occasionally.)

From the new features what I'd focus on:

  • auto. All my new code is full of auto const and auto const& locals omitting the types. Ok, one suggested globalreplace contradicting what I said previously: replace ::iterator usage by auto if you have for loops using them.
  • lambdas, if you use algos with one-shot functions
  • the new threading stuff, especially std::future if applies to the project

If you happen to use 'std::auto_ptr' probably a good candidate for globalreplace too.

I left out move semantics because I'm yet to jump on them, not sure of the impact, so I leave it for others to suggest or not.

Balog Pal
  • 16,195
  • 2
  • 23
  • 37
  • "*I thought WG21 fought hard to preserve all the compatibility*" -- sure, but some compilers are slowly enforcing conformance -- and this is a good time for them to improve their conformance and force us to update our programs. also, there are some breaking changes where conforming programs will produce errors when compiled using std.C++11 (narrowing conversions are one example). – justin Jun 02 '13 at 11:35
  • 1
    @justin: I just re-read that C.2 section and concluded again, that if any of the changes manifest on my codebase it already has an latent bug at the spot. (IUC the narrowing conversion change applies only to brace-init, where I expect matching types.) My extrapolation from that is the migration should not be an effort worth mentioning compared to usual problems real life throws at us. But I won't debate anyone's different experience or opinion. It would be interesting to collect real-life stories. – Balog Pal Jun 02 '13 at 15:03
  • see Ali's link for a more complete list of breaking changes. i just didn't agree that the obscure `export` was the only real concern. over here, i estimate it took about one hour per 50,000 physical lines of code to add support for c++11 on one compiler and a c++11 compatible std library to the point where it builds and links OK. following libs/compilers go faster. poorly maintained codebases and projects slower. testing omitted. that adoption phase would probably cost most teams a few dedicated days -- weeks at most, and hours on the low end. (cont) – justin Jun 02 '13 at 19:51
  • (cont) then you have the option to "modernize" the codebase to use new features (e.g. the new features you propose), which can take a bit of time to refactor and review codebases, then retest programs. there are also teams that don't feel that big changes like that are justified because it's too risky, so they adopt very slowly and make only the necessary changes over time. – justin Jun 02 '13 at 19:53
2

As others have pointed out, your code will probably compile just fine. If you are curious what could go wrong, then see

What breaking changes are introduced in C++11?

If you are planning on changing your old code to use C++11 features, I would add auto to Baget's answer.

Community
  • 1
  • 1
Ali
  • 56,466
  • 29
  • 168
  • 265