14

I haven't coded in C++ for years. I recently discovered that during those years it has changed quite dramatically. I'm not sure I like the changes, but that's another discussion.

I still have some C++ code knocking around my hard drive. If I got it out and tried to compile it with a nice new C++ compiler, say the latest version of g++, would it compile? Without warnings (assuming it compiled without warnings before)?

I did get to mess around with a little VC++ 2010 recently and found some things I expected to work just not working, and got different messages depending on context when I tried to use NULL. But in one part of that code I used NULL without even a warning.

AlastairG
  • 4,119
  • 5
  • 26
  • 41

12 Answers12

17

It depends. Usually newer compilers are more standard-compliant, so many constructs that compiled on earlier compilers don't compile now without fixing. For example:

 for( int i = 0; ... );
 i++;

compiled in Visual C++ 7, but not in Visual C++ 9.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • 9
    So C++ itself is backwards compatible, but the compilers implementing it are not. – foraidt Dec 01 '10 at 15:46
  • But it would compile in VC2003 with default options. – Dialecticus Dec 01 '10 at 15:48
  • 2
    @Dialecticus: So if you use nonstandard compiler extensions or exploit compiler bugs then new versions of the compiler might break your code. That's pretty much a given because it's nonstandard behavior! On the other hand, if your code was correct w.r.t. the standard to begin with shouldn't have problems like that. – Billy ONeal Dec 01 '10 at 15:50
  • 4
    @Billy ONeal: There is The Standard which is just a text and there're compilers that are working programs. Very rarely people write according to The Standard - they usually settle once it works compiled with one or several compilers of interest. This is why real code is almost never fully compliant to The Standard. – sharptooth Dec 01 '10 at 15:52
  • 1
    @sharptooh. Fair point. OTOH, if your code compiles on 2 or more compilers, it's probably close enough to the standard that there will be few compatibility problems on later versions of the same compilers. – Billy ONeal Dec 01 '10 at 15:59
  • @sharptooth, many casess of the above will compile ok in VC++9 if you use /ZC:forScope- (i.e. don't force conformance in for loop scope). I had a bunch of old C code that was re-using the same loop variable, in and out of the loop body, that needed this. – SmacL Dec 01 '10 at 16:24
  • 1
    @Billy ONeal - The problem with that particular VS buglet was that it made valid standard C++ (eg: declaring `i` in two successive `for` loops) not compile, so that you had to do the non-standard thing (just declare it in the first loop). Then once they started following the standard properly, their old incorrect behavior which their old compiler enforced stopped working. – T.E.D. Dec 01 '10 at 22:23
12

In general, yes it is backwards compatible. However, the devil is in the details. You likely will find things where conventions change, or specific libraries fall into or out of use.

David Oneill
  • 12,502
  • 16
  • 58
  • 70
  • 2
    I recently had a taste of "devil in the details" when a class started needing a move constructor to function correctly when using the new C++. Otherwise the program crashes inside the code of C++0x STL that uses new features. – amit kumar Jan 19 '12 at 15:35
8

NULL is a macro - prefer to use 0 (or nullptr in C++0x).

Not sure just how old your code is, but Visual C++ v6 suffers from limitations that result in code that simply won't compile on newer compilers. VS2005 and up are a lot better (in the sense of more correct wrt the contemporaneous C++ standard).

I would not expect it to be a huge amount of work to get old code compiled, though. I've done some pretty major ports from VC6 -> VS2005 and for the most part it's a matter of hours, not days. Perhaps once the culture shock has worn off this will not seem so daunting. Really, VC++ 10 is very nice.

Community
  • 1
  • 1
Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
  • 1
    Somebody else could do this: `@undef NULL` then `#define NULL 1`. Dumb example but that's one reason why macros suck. – Steve Townsend Dec 01 '10 at 15:51
  • @Javier It might be defined as, say, `(void*)0` instead of just 0, which means you couldn't use it as a general purpose null pointer. Alternately it could be undefined and redefined at will. – Mark B Dec 01 '10 at 15:53
  • 2
    @Javier: C is weakly typed, you can assign `(void*)0` to any pointer. In C++ this requires an explicit cast. Therefore, if the macro has been defined for C, then it may break in C++ programs. – Matthieu M. Dec 01 '10 at 16:16
  • Am I the only person that preferred C's `void*` (which could be cast to and from any other pointer type) and NULL `(void *)0` to C++'s? `int x = NULL; char *foo = 0;` compiles without errors in C++, and that just doesn't feel right... – Roddy Dec 01 '10 at 16:59
  • @Roddy - you are probably not the only one, but in a minority I think. `int x = nullptr;` will fail: `error C2440: 'initializing' : cannot convert from 'nullptr' to 'int'`. – Steve Townsend Dec 01 '10 at 17:06
  • @Roddy: C's NULL might have some advantages, but it seems things like `int n = NULL;` only produce warnings at best, not errors, in both languages. In the general case, though, not having `void*` into convert into any pointer type implicitly is an advantage. – UncleBens Dec 01 '10 at 17:09
  • @Steve: `NULL` is guaranteed by the standard. What it is `#define`-d to is implementation defined, but it has to be there. Somebody could re`#define` NULL, sure, but by the same token they could also define `std::find`. Evil cannot be stopped. – John Dibling Dec 01 '10 at 19:18
  • @John - thanks. So is C++0x `nullptr` an attempt to make this area of that standard better? – Steve Townsend Dec 01 '10 at 19:20
  • @Steve: I can't comment as to motivation, but I do feel this will be an effect. – John Dibling Dec 01 '10 at 19:22
  • 1
    @Steve: I remember this being a very interesting video on the subject: . I'd summarise it, but it's been a while ago, and probably better to get it from the horse's mouth, as it were. – Stuart Golodetz Dec 01 '10 at 20:45
  • The key bit I was thinking of is about 33 mins in, incidentally. – Stuart Golodetz Dec 01 '10 at 20:51
  • I find using 0 as a NULL-pointer in C++(98) very scary. If you pass a pointer to a variadic function that expects pointers, 0 will be passed as if it was an integer, leading to possibly broken code on platforms where sizeof(int) != sizeof(void*). Of course, C++0x fixes this with nullptr and variadic templates. – Maister Dec 06 '10 at 13:34
5

This depends on what you're comparing to.

  • Visual Studio 2010 partially implements the upcoming C++0x draft (recent versions of GCC also implement a subset of this draft, which is expected to be standardized next year)
  • C++98/C++03 was the first standardized version of C++, and is still the official one (as C++0x is still only a draft)
  • and of course, there are the dialects from before the language was standardized

C++0x is pretty much backwards compatible with C++03/98. There may be a couple of obscure corner cases that have changed, but you are unlikely to encounter them. However, a lot of changes occurred when the language was first standardized, meaning that C++98 isn't entirely (but nearly) compatible with pre-standard C++.

But more likely, what you're into isn't a question of C++ backwards compatibility, but simply that compilers have gotten stricter. They have become much better at following the standard, and no longer allow many non-standard tricks that were common earlier. Most likely, your old code was never valid C++, but worked because compilers used to deviate more from the standard.

jalf
  • 243,077
  • 51
  • 345
  • 550
3

The language itself hasn't changed since it was standardized in 1998. Idioms have changed, and compilers have both improved their support for the standard and become stricter about non-standard code, but any standard-conforming C++ code that compiled in the past should still compile today. Code that relies on non-standard compiler features or quirks might not work, but compilers typically offer command-line options to make them accept non-standard code that used to be accepted by previous versions of the same compiler.

NULL is a macro that's defined in <cstddef>. Other standard headers may include that header as an implementation detail, so it's often possible to use NULL without explicitly including <cstddef>, but relying on that has always been non-portable. It's OK to use NULL as long as you include its header, though just using 0 is preferred in idiomatic C++.

Wyzard
  • 33,849
  • 3
  • 67
  • 87
  • 1
    Thanks for the detail. Everywhere I have worked though seems to prefer using NULL to 0. – AlastairG Dec 01 '10 at 16:10
  • 1
    There are things that *have* changed since '98. For example: `auto` is no longer a storage class specifier; in C++0x, it's equivalent to `var` in other languages, doing automatic type deduction. – greyfade Dec 01 '10 at 18:25
  • grayfade, C++0x isn't finished and isn't the default for compilers yet, so I don't think it's right to say that the language *has* changed. It *will* change, though. – Wyzard Dec 01 '10 at 23:31
  • AlastairG, I prefer NULL too, actually — it makes it clear to the reader that it's a pointer rather than an integer. The upcoming new version of C++ (known as "C++0x" even though it wasn't actually finished during the 200x decade) has a new "nullptr" keyword that takes the place of 0. – Wyzard Dec 01 '10 at 23:35
2

All version of C++ should be backwards compatible.

Although there might be some unusual cases where there could be a problem, e.g. noexcept on destructos in C++0x (although this has not yet been decided).

ronag
  • 49,529
  • 25
  • 126
  • 221
2

Well, I know a lot of our old VS6 code started throwing tons of warnings when we upgraded to VS 2005 (with full warnings on of course, as everyone should work). Most were good things though, warning of potential information loss, warning that some types may be 64-bit instead of 32-bit like old code might expect, etc.

For your specific example of NULL, that wasn't even really standard C back in the day. Every compiler just had a #define for it that set it to 0. These days it is generally considered more correct (and clear) to just use 0.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
  • `NULL` not standard? It dates back to C89. It's even older than quite a few C++ programmers. – MSalters Dec 02 '10 at 08:44
  • 1
    Well, I date back older than that. We used to actually have to hunt down what NULL was defined as just to be sure. Some compilers set it to oddball things, and occasional badly-behaved source files would even redefine it. – T.E.D. Dec 03 '10 at 14:54
2

Newer C++ standards come to clarify things, then take decissions on which usage is "more correct" or accepted, so I would expect warnings. Some other decisions change what can be done or not, so I would also expect errors. I've come across the same situation, and I had to tweak the code for it to compile. It was not a great deal, but this was taking into account my knowledge of C++. In general, you should encounter not great problems.

There are also other things. For example, not all compilers implemented the whole rules of the C++ standard, or they had bugs. When you get used with a compiler, some of those errors or missing features may pass unnoticed to your compiler, but may cause errors in future versions of the same compiler.

Diego Sevilla
  • 28,636
  • 4
  • 59
  • 87
2

That's the major reason why we have standards. You don't have to worry about compatibility, you will just tell the compiler to compile the code as C++98 (or 2003).

MSVC is unfortunately very bad at supporting C++ standards. It is slowly getting better (and that's why old code doesn't compile, since it shouldn't compile in the first place).

Šimon Tóth
  • 35,456
  • 20
  • 106
  • 151
0

If you have used old versions of various libraries such as Boost, expect some problems.

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
0

Very similar to sharptooth's answer, there are bits of older C and C++ code that will need /ZC:forScope- set (i.e. don't force conformance in for loop scope). e.g.

int myfunc(int x, int y, int z)
{
  int j;

  for (int i=0; i <= 10; i++)
  {
    if  (f(i) == 0)
      break;
  }
  j = i;
  for (i=0; i <= 10; i++)
  {
    if  (g(i) == 0)
      break;
  }
  if (i > j)
    return j;
  return i;
}

This type of thing is quite common in much older code, where bytes cost money and variable re-use was common place.

SmacL
  • 22,555
  • 12
  • 95
  • 149
0

Slightly random, but the keyword export is being removed from the standard. So previously standards compliant code the used export would now be illegal. Of course, very few compilers even began implementing that keyword.

pythonic metaphor
  • 10,296
  • 18
  • 68
  • 110