What is legacy code and how/why is c++ described as legacy code?. . .
On top of all that is simple momentum -- There's a legacy of C and C++ code in the games industry that's venerable, tested, and works on every relevant platform.
Legacy code basically just means old code that is still in use.
More often than not, the term is generally used to describe old code that could be done better using modern techniques, but that continues to be used possibly because the cost of replacing it (or the hardware it is running on) is initially high or because there is other code that depends on it, and nobody wants to risk breaking the dependency.
so that's why languages have a hard time being as popular as c++. It may be easier, maybe faster and requires less code but it isn't worth changing because the consequence outweighs the advantage.Legacy code basically just means old code that is still in use.
More often than not, the term is generally used to describe old code that could be done better using modern techniques, but that continues to be used possibly because the cost of replacing it (or the hardware it is running on) is initially high or because there is other code that depends on it, and nobody wants to risk breaking the dependency.
so that's why languages have a hard time being as popular as c++. It may be easier, maybe faster and requires less code but it isn't worth changing because the consequence outweighs the advantage.
No that isn't why and legacy code has little to nothing to do with the popularity of something. There are programmers that swear by C++, there are some that swear by Java, others by C#, etc. Each language has its own following and C++ is so widely popular because it was adopted so quickly as the standard language for most software companies. That has started to change over the years as companies shift their focus or develop teams to develop on other platforms. Every language is designed with specific tasks in mind.
As stated by Bjarne Stroustrup
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
The only reason why there is legacy C and C++ code is because C and C++ was common back then, still is common and will remain common in future (afterall, it is pretty much *the* standard language in software engineering).
If Java or .NET was around back then and it was deemed better than C++, then there would be lots of legacy code lying around in those languages.
A good example of this is Microsoft VB6. There is a tonne of legacy VB6 code lying around but unlike C++ the new VB.NET is not backwards compatible so developers are reimplementing it in current (more portable) languages (like C++ and Java).
In another 50 years, the original legacy C and C++ code will probably still work so what will it be called? Archaic? In my opinion, if legacy code works, is maintainable and well documented then it is great. It means that it was originally correctly written and used correct "futureproof" technology. Contrast this to code that you need to rewrite every few years because you keep choosing technology that becomes obsolete / dies (I am looking at you VB6!).
As stated by Bjarne Stroustrup
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
The only reason why there is legacy C and C++ code is because C and C++ was common back then, still is common and will remain common in future (afterall, it is pretty much *the* standard language in software engineering).
If C# was around back then and it was deemed better than C++, then there would be lots of legacy C# code lying around.
A good example of this is Microsoft VB6. There is a tonne of legacy VB6 code lying around but unlike C++ the new VB.NET is not backwards compatible so developers are reimplementing it in current (more portable) languages (like C++ and Java).
That Stroustrup comment is spurious at best. There are a large number of languages that never become popular but never really go away. Smalltalk and LISP are too examples that jump to mind immediately. Then there are tons of domain specific languages, which are almost by definition unpopular and used. Haskell is probably a good example here, but you could also consider FORTRAN or MATLab in this area.
FORTRAN may not be fair on that list, as my understanding is, that bastard is uber popular amongst the math and engineering sets...
Surely your comment just agreed with that quote.
Languages may never fully go away but the popular ones that get used 24/7 do naturally generate legacy code. So again, the sheer popularity of C and C++ is what has caused the influx of legacy code.
I honestly have never seen Smalltalk code in the wild (let alone legacy libs) but I come into contact with Lisp quite often via my use of emacs and admittedly I have seen some pretty crusty Lisp (even though it is a slightly different dialect) ;)
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.As stated by Bjarne Stroustrup
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
The only reason why there is legacy C and C++ code is because C and C++ was common back then, still is common and will remain common in future (afterall, it is pretty much *the* standard language in software engineering).
If Java or .NET was around back then and it was deemed better than C++, then there would be lots of legacy code lying around in those languages.
A good example of this is Microsoft VB6. There is a tonne of legacy VB6 code lying around but unlike C++ the new VB.NET is not backwards compatible so developers are reimplementing it in current (more portable) languages (like C++ and Java).
In another 50 years, the original legacy C and C++ code will probably still work so what will it be called? Archaic? In my opinion, if legacy code works, is maintainable and well documented then it is great. It means that it was originally correctly written and used correct "futureproof" technology. Contrast this to code that you need to rewrite every few years because you keep choosing technology that becomes obsolete / dies (I am looking at you VB6!).
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 compile time (try writing a simple C++ OpenGL application and then try the same thing in Java and make up your own mind).
Plus, C and C++ can easily go the other way too. They can call, for example, a Java library or .NET library using libjni or libmono (or even Microsoft C++/clr). Trying to get Java code to call a .NET library is extremely fiddly.
That said, some of these features I have just ranted about are not always necessary for games development so it is largely irrelevant to most people. It still comes down to use the language you prefer and can get the game done quickest in ;)
but doesn't backwards compatibility increase the complexity of a language? Supporting old features that can be replaced by new ones.Definitely. My main interest in the C++ language is the backwards compatibility.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.
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).
