Well C++ does have a deprecation system. For example std::auto_ptr<T>.

Also, if you don't use an old feature of a language. How could that effect your project negatively? Just because the language supports something, it doesn't mean you have to use it. Same with new features, I know a lot of developers I work with tend to overly consume language features because they are "new and cool".

Most C and C++ compilers also have a way to specifiy the standard to use via a compile time flag (i.e -std=C++11, -std=C++0x, -std=C99). It also has "non standard" standards support (i.e -std=gnu++0x) and even one that adds basic RAII into GNU C (cant recall the compile time flag).

What would you prefer? A slightly more complex language or one that a library you rely on no longer compiles because the language has changed?

Ironically using something like Java or .NET does not solve this because both these languages are compiled using C / C++ so a breakage in the underlying C language has a knock on effect on these entire platforms (i.e porting Java to a new platform is a massive task made almost impossible if the C++ language changes every year).

Well C++ does have a deprecation system. For example std::auto_ptr<T>.

Also, if you don't use an old feature of a language. How could that effect your project negatively? Just because the language supports something, it doesn't mean you have to use it. Same with new features, I know a lot of developers I work with tend to overly consume language features because they are "new and cool".

Most C and C++ compilers also have a way to specifiy the standard to use via a compile time flag (i.e -std=C++11, -std=C++0x, -std=C99). It also has "non standard" standards support (i.e -std=gnu++0x) and even one that adds basic RAII into GNU C (cant recall the compile time flag).

What would you prefer? A slightly more complex language or one that a library you rely on no longer compiles because the language has changed?
Ironically using something like Java or .NET does not solve this because both these languages are compiled using C / C++ so a breakage in the underlying C language has a knock on effect on these entire platforms (i.e porting Java to a new platform is a massive task made almost impossible if the C++ language changes every year).

What's deprecation?

Deprecation

As far as my experience goes, the code is not called legacy because it is old, it is because no one supports it (and, therefore, no one understands properly how it works).

As far as my experience goes, the code is not called legacy because it is old, it is because no one supports it (and, therefore, no one understands properly how it works).

so backwards compatibility is a good thing? I heard C++ is also backwards compatible with C and that struct comes from C while the C++ equivalent is class.

Definitely. My main interest in the C++ language is the backwards compatibility.
If Java could support old C and C++ code and didn't need a JRE, I would be all over that mofo ;)

C++ is mostly backwards compatible with C (in that it is very easy to get C compiling with a C++ compiler). Objective-C also is backwards compatible with C. C++ is a little more strict than C in that it needs explicit casts etc.. but in general it is all good.

C++ has structs as well but the only difference between a struct and a class in C++ is that by default everything in it is public. A well designed C++ application can make use of both structs and classes.

I might add that although C++ is backwards compatible, the design of the code is different and should be treated as such. New(ish) features like custom deleter functions in smart pointers make dealing with C code much nicer however.

I think the best example I can think of is OpenGL which is a C library can be directly consumed by C++ code. Contrast this to using other languages where you have to use a wrapper (a wrapper is a large project to bind the native C code to another language). These things are notorious for becoming very unmaintained and out of sync with the latest version of the original library. Even Microsoft couldn't be arsed anymore with XNA (A fat binding for DirectX 9). Another example is the many Java OpenGL bindings. These things are platform specific (so you instantly lose one of the potential features of Java) and they are also a massive pain to rig up compared to just doing the whole thing in C++ and binding it at runtime (try writing a simple C++ OpenGL application and then try the same thing in Java and make up your own mind).

but doesn't backwards compatibility increase the complexity of a language? Supporting old features that can be replaced by new ones.
By putting those two options in one language, don't you increase it's complexity till it becomes so bad?

A (almost) compatibility with C is a feature of the C++ programming language, read more here: http://www.stroustrup.com/bs_faq.html#whyC

For the legacy code question: it exist for an ancestral and universal common law in the programming world that could be summarize in “if it works don't touch it”. Many people don't argue with it or they have slightly different forms (I honestly prefer this: "if it works and it doesn't create big issues, don't even try touch it or I will cut your fingers!")...

A good example of legacy code in the game industry could be the use of DirectInput: DirectInput it's deprecated (last version came with DirectX SDK 8.x), but it still works well and for many games its limitations are not a big issues, plus you can use it to support all the HIDs (human interface devices) that are not supported by other APIs (like xinput)... DirectInput actually is used in most AAA games and game engines/SDK (Valve's Source, Crytek CryEngine, Torque 3D, Unreal Engine, etc...).

As far as my experience goes, the code is not called legacy because it is old, it is because no one supports it (and, therefore, no one understands properly how it works).

Agreed. Although I guess that as soon as a dependency our code relies on has had support dropped, no matter how new the code is, it is suddenly "legacy". This is why portable code is very important (especially nowadays where for some reason companies think experimental == modern)

Although I find it quite amusing how much of Microsoft's legacy technology these days is actually outliving its successors. I have already placed my bets on MFC actually outlasting WPF (a technology at least 3 generations newer).

so does that means they don't understand what runs their system?
If this is true, what is the benefit of having what you don't understand and isn't supported?

Because if it still works, then it is still useful. If it is an old crusty black box, then that is a shame but it still probably doesnt justify a rewrite.

We dont understand whats behind closed-source software and yet people are more than happy to use that.

I guess in some ways, closed-source software is deprecated as soon as you have purchased it because you cannot maintain the code yourself.

(Full disclosure, I am a BSD user/developer and advocate open-source for everything people do).

As far as my experience goes, the code is not called legacy because it is old, it is because no one supports it (and, therefore, no one understands properly how it works).

Agreed. Although I guess that as soon as a dependency our code relies on has had support dropped, no matter how new the code is, it is suddenly "legacy". This is why portable code is very important (especially nowadays where for some reason companies think experimental == modern)

Although I find it quite amusing how much of Microsoft's legacy technology these days is actually outliving its successors. I have already placed my bets on MFC actually outlasting WPF (a technology at least 3 generations newer).

so does that means they don't understand what runs their system?
If this is true, what is the benefit of having what you don't understand and isn't supported?

Because if it still works, then it is still useful. If it is an old crusty black box, then that is a shame but it still probably doesnt justify a rewrite.
We dont understand whats behind closed-source software and yet people are more than happy to use that.
I guess in some ways, closed-source software is deprecated as soon as you have purchased it because you cannot maintain the code yourself.
(Full disclosure, I am a BSD user/developer and advocate open-source for everything people do).

I don't know what BSD is.

http://lmgtfy.com/?q=BSD

As far as my experience goes, the code is not called legacy because it is old, it is because no one supports it (and, therefore, no one understands properly how it works).

so does that means they don't understand what runs their system?
If this is true, what is the benefit of having what you don't understand and isn't supported?

There's no benefit, other than that the system works and will likely continue to work. The implication of this definition of "legacy" is that no one is left who understands the old code precisely enough to replace it with newer, better, cleaner code. Happens all the time -- some medium-sized utility at a large warehouse operation becomes critical to the business, developed by one lone programmer, and hacked to add new features over the years, and suddenly that programmer leaves the company, retires, or dies. The business relies on that software, but can't risk changing it and can't afford to hire a consultant to come in and analyze it to the necessary degree. You'd like to think that just any programmer can come in and read the code and know what's going on, but its not the case in reality. In reality there are all sorts of little assumptions and gotchas in most code bases (particularly of the type I describe here), and documentation, if it even exists, is often outdated for just plain wrong.

Yes, the business is precariously positioned to rely on such software, but what can they do?

There's somewhat less of this in the games industry, for example, but I recall reading in an article that Madden Football -- all the way up until its Xbox 360 and PS3 incarnations -- still had some C code in it that had originated in the Sega Genesis version. The first few Halo games, originally developed for the MAC, had a codebase that sort of hacked some C++-like features into their C codebase (The mac platform didn't have great support for C++ back in the day, and their frameworks to this day are written in (or at least exposed as) Objective-C rather than C++ or even vanilla C). I'd wager that the latest unreal engine has code stretching back to the original unreal.

Legacy code is just older code that's either difficult or unfeasible to replace, but which is nonetheless necessary to continue using. It's most often stated in relation to C++ just because C and C++ were among the first very popular, widely used languages. But there's a non-trivial amount of legacy COBOL and FORTRAN code running all kinds of finance and business institutions. In fact, if you understand either one along with the hardware and related software systems of the day as well as the old-timers did, and also a modern language well enough to re-implement it in a more-modern language, you can probably earn yourself a half-million-dollar salary or more through consulting work.