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".
How about Accelerated C++?
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.
- Yeah, I really really hate that. Also hate the spurious errors some compilers throw. It does make me avoid templates, but sometimes they're still worth it.
- Agreed. I actually think templates + STL are the best feature of C++ (sigh), and that they should be used in preference to the other nasty features of C++ practically whenever possible. But everytime I get such an error message I at least temporarily change my mind. :-)
Surely this is an issue with the compiler's diagonistics - not the language itself. StlFilt
(a Perl script) is used by a few compilers now to trim error messages from STL components.
- True enough. However, long template error messages are something that turns people off to late C++ regardless of whether it's a compiler issue or a language issue. Hopefully, the messages will get trimmed better in the future by the compiler or there will be wider of of StlFilt style stuff.
) might improve the error message situation.
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