Late Cee Plus Plus
Late Cee Plus PlusCeePlusPlus with templates, STL (StandardTemplateLibrary), RTTI (RunTimeTypeInformation), exceptions and stuff.
As distinct from EarlyCeePlusPlus
Which of the features mentioned made the biggest impact? I'm guessing it's templates and STL - GenericProgramming can be very different from purely polymorphic programming.
Some examples comparing early and late C++ would be nice.
When I first used C++ heavily, it had no exceptions, so I created my own pseudo-exception package for error handling. Although the result had fancier features than the eventual standard, the lack of completely automated calling of destructors was of course bug-prone.
Early versions of GnuCpp were very zealous about automatic type conversions; it hunted for a chain of type conversions that would allow some existing method to be called on exotic parameters. It almost always guessed wrong on this whenever the chain was more than 1 conversion deep, but IIRC you couldn't turn off that misfeature in order to get a nice honest error message.
Most C++ programmers I've worked with, even those who have learned the language recently, use EarlyCeePlusPlus or just an improved CeeLanguage. I find very few C++ programmers who are comfortable with templates, exceptions, namespaces, or the Standard C++ Library. I find it particularly troubling that most C++ programmers still exclusively use CeeLanguage-style arrays and strings, and avoid the standard C++ containers and the string class. I'll spare you my rants about what I think about use of printf() in C++ programs.
I think the problem is that most C++ books and tutorials still focus on EarlyCeePlusPlus. The LateCeePlusPlus features are treated as "advanced topics", which scares people away. (The few books I've seen that are focused on C++ templates really are pretty scary.) This is unfortunate, as these features make the language much more expressive, and can lead to simpler code that is more resilient to change.
Some programmers think they have to stick with EarlyCeePlusPlus to maximize portability between various compilers and to avoid compiler bugs. I can sympathize with this reason, but it is becoming less true as compiler vendors improve their compliance. An organization that locks itself into using obsolete compilers will achieve the expected results.
Another force slowing adoption of LateCeePlusPlus is that EarlyCeePlusPlus is the preferred mode for people coming from Smalltalk, Java, or other OO languages. Their attempts to write C++ that looks like these other languages leads to a lot of frustration. EarlyCeePlusPlus's support for polymorphism and reflection are poor compared to those other languages. This poverty can be overcome by using LateCeePlusPlus features, but they tend to give up before learning that.
Unfortunately, many managers have concluded that a SaneSubset of C++ should exclude any LateCeePlusPlus features. Programmers who know what they're doing are stuck with BadStyleGuides, so knowledge of how to make good use of C++ doesn't get passed around.
Another problem is that some popular C++ frameworks (like MicrosoftFoundationClasses) were created in the EarlyCeePlusPlus days. Programmers using those frameworks tend to stick with their idioms. Many are led to believe that those frameworks represent The Right Way to use C++. I know a couple of programmers who learned C++ just to use CORBA; I think the CORBA C++ language mapping has permanently damaged their brains.
So, how can we get C++ programmers to learn LateCeePlusPlus? I don't know--I've given up. I think we need a good C++ book that starts with templates, exceptions, and so forth, then treats polymorphism and inheritance as "advanced features".
-- KrisJohnson
How about Accelerated C++? --AnonymousDonor
I want to use exceptions and templates. (Actually, I want to use a different language) But, the client insists on Visual Studio 6 and no external libs. Non-broken STL, Boost, and a lot of template stuff is right out. -- JoeWeaver
Well, you can (and we do) use the supplied STL, you just can't share some stuff like std::map directly across DLL boundaries. If your client doesn't allow BoostLibraries, though, they're not acting in their own best interests. Most of the stuff in there is far better quality than anything a single project will recreate on its own.
True, true. I guess the point of this is that clients specifying environments which do not support LateCeePlusPlus, or at least make it more painful to use, reduces the amount of time developers are exposed to its features. Since free time is a limited resource, and since a very popular development environment is one of the culprits, we see a lot of C++ programmers learning the newer features at a slow rate. -- JoeWeaver
Another thing strikes me, many C++ developers have been doing C++ for years and years. I think, especially when the pressure's on, we tend to stick to what we know. Sure, devs are aware to varying degrees of these funny things called vectors and maps, but they can whip up raw pointered linked lists in much less time than it would take to learn some STL. Of course, they'd win in the long run if they spent some extra time learning it. The tension between 'get it done fast now, but longer overall' and 'take a while longer to do it now, but spend less time overall' is exemplified whenever you decide if you should CleanTheKitchen.
Some developers just don't like templates/STL. Many developers already have their own libraries they are comfortable with and may provide functionality beyond the STL. -- LayneThomas
I would consider the same (or better) functionality to fall under LateCeePlusPlus. Templates/STL is just one of many ways to get there. So, it's good to know there are more developers than I initiality expected using LateCeePlusPlus.
Would you still say that if I told you those libraries were procedural code that compile fine under non CeePlusPlus compilers? -- LayneThomas
I would venture a yes. I'm more concerned with programmers having the ability to do generic programming and use exceptions, I'm not too worried about the implementation, with the caveat that one of the nice things about STL is everyone is speaking and working on the same thing.
Maybe what we are talking about isn't CeePlusPlus at all, but high level patterns that originated from OOP/CeePlusPlus. Those patterns are worth learning, but shouldn't be tied to a specific language. As a concept, reusable libraries are pretty general.
Indeed, I think part of the problem is the rapid crustifying of this disucssion. Originally it was about why lots of CeePlusPlus devs don't seem to use the higher level patterns that now exist for the language.
Yeah. A cleanup and rename to ContemporaryCeePlusPlus? might be in order.
I was just thinking this might be a good part of the HugeRefactoringOpportunity to play with. Let's let it cool a little though.
Another force slowing adoption of LateCeePlusPlus is that EarlyCeePlusPlus is the preferred mode for people coming from Smalltalk, Java, or other OO languages. Their attempts to write C++ that looks like these other languages leads to a lot of frustration. EarlyCeePlusPlus's support for polymorphism and reflection are poor compared to those other languages. This poverty can be overcome by using LateCeePlusPlus features, but they tend to give up before learning that.
It occurs to me that a lot of the reason I had difficulty with CeePlusPlus in university (and though this was a few years ago, we did get taught templates and STL - but not the other LateCeePlusPlus features, and not taught well enough to make them *work*) is because I was expecting it to have more Java-like support for OO, based on its being sold to us as an OO language. This is before I knew Java! C++'s OO support is pretty awful IMHO. -- KarlKnechtel
C++'s strong point isn't that it's great at anything, it's that it's (mostly)acceptable for anything. I can't think of a single feature C++ has that isn't done better somewhere else. However I can't think of any feature that isn't implementable (in some fashion) in C++ either. Some believe that is why CeePlusPlusReigns. -- LayneThomas
As for being comfortable with templates, I love the STL design, but alas, they're based on C++ templates. Tell me you've never gotten a 50-line error message just when using templates. Not creating your own, just using existing packages. The time lost to trying to decipher these, the ugliest and most deeply nested error messages ever invented, justifies avoidance of templates to some extent.
s/might/will/, sir :) s/will/would have/ -- Concepts didn't make the cut for C++0x -- JamesDennett
Oh, my mistake. I thought this was "The Late CeePlusPlus", as in CeePlusPlusIsDead?. The king is dead! long live the king! see CeePlusPlusReigns
That's what I assumed the page was about when I saw the title too. -- jw
[It's just a sneaky ploy to increase the popularity of this page. ;-) ]
I don't claim to "know" C++ very well (it's a large language, and I don't get much practice in it), but I've taken a couple of classes at a Swedish uni (in Visby). We were taught a subset of LateCeePlusPlus. Vectors and strings and stuff like that. I never liked C++, but when I discovered EarlyCeePlusPlus, I was shocked. So much worse than the stuff that's available now, which is what I was first exposed to. --SunnanFenderson
EditText of this page
(last edited September 27, 2014)
or FindPage with title or text search