5

I have a pretty big c++ code base (not self written). Numerous libraries, some not so syntactically heavy, some extremely so. Among others there's heavy use of Boost, some Eigen.

I just love some of the new features of 0x and a quick compile/test tells me that it seems all good. This question, and this one suggest that there are some things that smell funny.

My current state is:

  • gcc4.4.3
  • libstc++6-4.4
  • boost-1.40
  • eigen 3.0 - beta3

using the std=c++0x flag.

I know the standards committee has agonized about backwards compatibility and endured serious pain. My question is, did it work? Can I take all that code, switch on c++0x and be certain, that everything does not only compile but also work as expected?

I don't use high 0x magic, just auto and some of the usual favorites explicitly marked "implemented" on GNU C++0x status.

Community
  • 1
  • 1
AndreasT
  • 9,417
  • 11
  • 46
  • 60
  • 2
    Try the hot new language, it's called C89 :). Works on everything. You can even use it in your C++ compiler! Guaranteed not to break on upgrade. – Matt Joiner Mar 26 '11 at 12:28
  • Things like "sizeof('a')" produce different results when compiled by a C++ compiler, so there are no guarantees even with C89. But are there any non-contrived examples of C++98 code changing behaviour silently under C++0x? – Clinton Mar 28 '11 at 00:24
  • @Clinton: See http://stackoverflow.com/questions/5759232/stdvector-default-construction-c0x-and-breaking-changes – Alexandre C. Apr 27 '11 at 07:38

3 Answers3

3

I would certainly recommend using GCC 4.5, as it sports more bug fixes and a more solid implementation of the latest C++0x.

With regard to the questions you linked:

  1. This is just a type definition on a new platform. Don't worry about this, it won't really break anything or be hard to fix.

  2. This is one of the more complicated C++0x features, but shouldn't have that much of an influence on backwards compatibility (except if boost tries to hack itself into a feature that is to become a compiler/language feature).

The only real way to check if there are problems, is to turn on the compiler flag, and see if any problems pop up. Better yet, turn on full-fledged warnings (at least on GCC, MSVC has some nagging problems in this regard) to detect as many subverted problems as possible. This isn't waterproof though. You might want to use different compilers (GCC/MSVC/Intel/Clang) to cross-check compatibility, but in the case of c++0x you'll be very limited to the common subset of the compilers you use to check. Currently I use C++0x extensively, and intend to fix any problems that come into being when the finalized standard is implemented.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • 1
    +1 for turning the warnings on: have some trust in the built-in mechanisms of the compiler to detect when some things smells bad. Then test to see if it really behaves as expected, of course. – Matthieu M. Mar 26 '11 at 11:56
  • @Matthieu: I didn't mention a warning flag, but it is a good idea. Editing that in :) – rubenvb Mar 26 '11 at 13:53
  • Ah! I read *turn on the compiler flag* and thought you were talking about warnings :D – Matthieu M. Mar 26 '11 at 14:24
2

There is no answer to your question, it depends on your code. Try to compile, fix compile-time problems. Once it compiles, run your test cases, and fix whatever needs to be fixed.

If you don't have test code, start there.

Mat
  • 202,337
  • 40
  • 393
  • 406
  • I am only a user of a ton of libraries. Some of them very header-only template heavy. I cannot test them all. And in a system as big as this I cannot check if there's something creeping in somewhere. – AndreasT Mar 26 '11 at 11:34
  • 2
    That's what some people call "integration tests" - you check your usage of these libraries are still working as expected. Check with each library's vendor/project to see if they are ok with C++0x as implemented with your version of GCC. If even you can't tell if you software is working correctly, how do you expect anyone else can? – Mat Mar 26 '11 at 11:39
1

This cannot be answered without knowledge of the code base. In particular, with 100% backwards compatibility you might find the same issues that you can find by upgrading/changing a compiler within the same standard:

If your code is not standard, if it uses features that are specific to the compiler or version, if it has any instance of undefined behavior or depends on unspecified behaviors that just happen to work in your current platform, then if might not compile (if you are lucky) or exhibit different behavior at runtime (if you are not lucky).

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489