Stroustrup on next-gen C++: I didn't want to let go of my baby C++ 11 is “far better than previous versions”, says the inventor of the language Bjarne Stroustrup. He was speaking at an online event marking the launch of Embarcadero's C++ Builder XE3, a rapid application tool targeting Windows and Mac OS X. C++ Builder XE3 is a promising but curious product. Delphi and C++ Builder were …
This post has been deleted by its author
Large nested macros in C can be very useful. My magnum opus application has survived and evolved over 20 years - starting as a command line Dos program in TurboC. It has been re-organised several times until it became a Visual Studio 6 32 bit console program.
The vast majority of the code relied on nested C macros for two reasons. Firstly it allowed some extremely complicated expressions to be read as simple logical application orientated statements. Secondly the evolution changed the underlying mechanisms several times - and rewritten macros allowed recompilation without having to make widespread changes elsewhere.
The most annoying problem with Visual Studio 6 was that it optimised several coincidentally identical functions' bodies to one piece of code with a single entry point. What it should have done was produce unique entry points to a single piece of code.
Visual Studio .NET would never produce a fully working version of the application - even with all optimisation switched off. Quite what the subtlety might be has not yet been revealed.
Large nested macros in C can be very useful.
Useful, maybe, but very hard to maintain. A macros has no respect for scope, it can mean different things in different parts of a program. That makes the program hard to read, and so hard to maintain.
Macros aren't only impenetrable to humans, tools are poor at handling them too. For example: cross-referencing tools typically can't see inside a macro, so will fail to list occurrences of names variables within a macro. Source-code debuggers can't step inside macros.
All of this makes them too dangerous to use in any non-trivial way.
In my experience the preprocessor in C and C++ is inadequate for cases where one's program code is best generated by another program. Use a stand-alone macro-processor, or write your own code-generator in (say) Python. Then just build it into your makefile. But do try to make sure that it emits debug-able code!
"That makes the program hard to read, and so hard to maintain."
In this particular case the inline code was repeated many times for similar, but not identical, imported data structures. Adding a new data case was trivial as the macros generated most of the code.
When an underlying mechanism was changed then the many data cases required no recoding once it worked for one case. Without macros the number of manual changes required to keep each case in step would eventually have been an impossible "spinning plates" task. That would have guaranteed not only transcription errors - but each would have been unpredictable.
Trying to read the programs' high level functionality as C was very difficult. Reading it as a set of macro calls was very easy. The macro expansion was relied upon to the same degree that one relies on a compiler producing the intended functionality in machine executable code.
A new working case could be accurately analysing live data within an hour of receiving the first sample. It was a tool for an environment with rapidly moving goalposts.
The Quality Assurance certificate stated that only the last fully regression tested binary was certified. Future enhancement or supportability was not guaranteed.
Horses for courses.
"For example: cross-referencing tools typically can't see inside a macro, so will fail to list occurrences of names variables within a macro. Source-code debuggers can't step inside macros."
That deficiency is the fault of the compilers. There was a time when a decent C compiler had the option to retain the preprocessor output files for debugging purposes.
The same problems exist for bugs that show up in compiler third party supplied libraries, or OS calls. The library binaries used to come with symbol tables and even source for debugging purposes.
There has always been an economic need to keep development programmers to a narrow horizontal focus. In the old days there was in-house support, with wider skills, who would untangle any problems that appeared outside a developer's skills. Nowadays it often seems that even the suppliers do not have the in-house skills to support the products they sell at that level.
Even assembler system programmers often had a narrow focus that did not include things like OS task switching or the hardware implementation. They rarely had to know about potential timing problems - so experienced "random" bugs which were actually deterministic in the wider context.
Honestly, in the past I was a major violator of this principle, but it was out of necessity since I was writing that code before std c++, and templates did not exist. Now, I rarely write macros, and try to limit that to only absolutely necessary cases. Since the invention of the STL, complex C++ macros are mostly unnecessary, and undesirable. Thanks Bjarne for your great work - I am definitely going to plunk down some of my hard-earned $$ and add your book to my library! Stroustrup and Ellis has long had an honored place there - both the original edition as well as the ANSI version. -)
Templates will make it really hard for debuggers and IDEs to provide a useful debugging experience and to properly navigate code. Whatabout a template class X which accepts a class Y and calls method Y::printYourself(). I doubt that there are IDEs which can properly track this at this time if you want to see all references to Y::printYourself().
Then, templates are slow as hell to compile.
Thirdly, template compile errors are 99% noise and 1% signal. Only after having spent 500 hours in front of them you will master the black art of filtering out that 1%. And yes, I mean that absolutely serious and I don't exaggerate.
Now replace these template classes with m4 macros which are expanded into plain C++ source files as part of the build process. That will allow the IDE to nicely index all of the expanded code, will allow for nice debugging and it will generate sane error messages linked to the actual expanded code.
I recognise there are some special cases where you need the power of template classes. But my feeling is that 1 out of 10000 use cases justifies the use of templates instead of a proper macro language (m4 being just one of many).
In most cases, templates are a regression to a proper macro system such as the one I described.
Unix has been successful because it is an assortment of many orthogonal tools which can be combined in an astronomic number of ways - according to problem at hand.
The C++ compiler and templates are bolting two things together: Programming language and macro language. As always in such cases, the results are highly sub-optimal.
If they really wanted a full code generation language run at compile time; why didn't they use Perl, Tcl/tk or LISP for that purpose ?? Yeah, because of Not Invented Here.
The idea that C++ is not suitable for embedded systems is a myth.
C++ code isn't any bulkier or slower than C code. In fact I've seen plenty of C code which ends up longer because it can't use things like virtual functions.
Of course some features of C++ (notably exception handling and use of the STL) can cause code to bulk up.
But you don't *have* to use those features; you'd certainly not use the STL for embedded code.
Exceptions if done correctly (obviously depends on compiler/.code generator) should cause no overhead at all if the exception doesn't fire. If it does fire, you've got a stack unwind to handle, with its associated destructor calls, but that's not much worse than setjmp/longjmp
Program languages to many programmers are like guitars to guitar players... Many will go through a bunch in order to find one they can 'play. It's not the instrument, it's the technique. If you have a problem of 100 tires in your yard, bad C practice is to make 1 stack of 100. Bad C++/OO will make 100 stacks of 1. I have had discussions with people quoting Stroustroup like it was the bible. Just because you can do it doesn't necessarily mean you should.
I've used C++ for embedded, and it's useful (Broadcom has done it well IMHO). I've seen subclassing done backwards more times than I care to (mention scope, they say OO automatically is scoped, as they litter statics through the classes).
The allure of C++, perl, and other languages is you can create a meta-language to describe the problem you're solving. But often it's jargon, ergot, or some other obscure cant that repackages what's already there. I think that's people not trusting the language, or invoking rituals (in OO, everything must be dynamically allocated... why? ... it's not OO if it's not. So, before I bang my head off the rock).
As languages grow, if they’re owned by a single organisation, sooner or later they start taking on peculiar twists to support that organisation’s business plan. The allies of that corporation are favoured.
He sure goat that part right. (I'm looking at you, Oracle, and you, Microsoft...)
C and C++ are similar to assembly language. They are exactly as good or bad as the programmer's discipline. They will not hold your hand, nor will they stop or even discourage you from making horrendous "mistakes". Some programmers prefer to impose discipline upon themselves and love C and C++, while others prefer it to be imposed from without and hate them both.
I'm not saying the above is true for everyone, or that either approach is right or wrong but that's just how I see it shaking out.
That would be perfectly aright, if it was "honest" about it. However if you look into typical C/C++ courses you'll find that it's being taught as some sort of Pascal. Many programmers are being brought up believing that C/C++ are high level languages, they will never understand what their code does.
Plus C++ is so amazingly complex, very few single persons understand it all.
C++ does seem to be the Marmite of the development community, I do wish people would keep calm about these things.
I have made a living as a consultant brought in usually at the last minute or after the fact to save projects that have gone awry for various reasons. These have been with a broad range of languages so over the years I've got to see the many ways that languages can be abused.
The problem with C++ is that it holds the mirror up to the face of the developer at an early stage, and a weak programmer is not likely to like what he sees. Other languages delude by hiding implementation weakness and its this obsequiousness that wins over generations of developers.
There's a lot of obfuscation out there about what is a very simple concept.
Procedural: F(a, b);
Object-orientated: a.F(b)
The advantage of the latter is that you cannot apply an inappropriate F to argument a, because only the methods of the object a are available in this context. It also reduces the number of pointers or object handles one has to keep track of. Of course, it doesn't prevent all bugs. You can still do (say) a.clockwise(b) when you meant a.anticlockwise(b) or a.clockwise(c)
Introspective: in a language like Python you might return to the procedural form, but check at runtime about the exact type of argumernts a and b, and do sensible things if they're not as expected.
That's the C++/Pascal way of OOP. The normal (e.g. Smalltalk) way is that you have objects, which are more like processes, which send each other messages. So you don't call a function, which means that it's hard to have encapsulation, but you send messages which even works between different computers. (Erlang implements that)
Then there are languages where you have objects, but can join them. Imagine you wanted to do "make_love". Now is it a.make_love(b) or b.make_love(a)? There you can do make_love(a,b) and the correct make_love will be selected by the compiler (or failing that the runtime).
C is a great language.
C++ started off as a great language (extending C to OOP)
But once template was introduced to C++,, it descended into a dogs dinner of a language. Hard to understand, hard to implement without a compiler debugger, hard to even read - code looks like an drunken octopus has danced across the non-alphanumeric part of the keyboard. I'm no compiler expert, but I could have done it better,
I find it ironic that Bjarne should complain abot the bad quality of books that teach C++. He should know well, as his own "The C++ Programming Language" is the most unfathomable book ever. It does not pretend to be a learning tool, but a reference tool, I know, but it may as well be written in Sanscrit. The explanations might be a marvel of concission and perfect software engineering, but while I can picture the author jerking off in self satisfaction, for the less gifted like me, they read like infinitely recursive and cross-jumping blabber. Any search for enlightenment tends to become a hopeless expedition into the bowels of the language where the most important discovery is how little you know, how much you ignore, and how difficult it will be to advance.
So, I have not looked at his new C++ teaching book, but I don't think Mr. Stroustrup's teaching abilities are very brilliant.
I use C++ every day, and it tends to make me feel I am very stupid. Maybe I am, and that is why I appreciate languages that make me feel smart.
C++ was the first language that I learnt. Rather than putting me off programming (as others have commented), it just made every other language seem easy.
I love C# for being C++ without the hard bits, and pretty much every scripting language I've tried seems like flying by comparison.
That said, now I'm no longer a code-newbie, it would be really interesting to revisit C++ and see if it's as tricky as I remember it to be.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
