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 …
Unfortunately, the title is true for me. When I was first introduced to C++ I hated it and questioned my choice to become a software developer. That was back in my uni days.
Since then, I have discovered the joys of languages like Ruby, Java and C#. I think these languages made it easier for me to get into development because they were so easy to understand (especially the close relationship between c# and Java).
These days, I find myself going back to C++ more and more and I have been watching this new version closely.
I feel that one of the key factors that has lead to the poor teaching of C++ in colleges and universities is down to the sponsorship that they often get these days. Uni's are now proud to exclaim that they are sponsored by Microsoft and Oracle, pushing their respective technologies. The end product is someone who can build software in VS or Eclipse and the end product will more often than not be something written in VB.Net(eugh), c# or Java.
I think I read somewhere that Microsoft now plans to push C++ 11 in Visual Studio, if this is true, I dont know if this is a bad thing or a good thing. I guess time will tell.
C++ is confusing for new users since they have often started with procedural languages, so moving to the concept of objects is a hard switch for some people.
It's syntax isn't a clean as say Java either. Plus there's some big words like polymorphism which also make people confused.
C++ and C are still the best languages for writing fast code without the need for awful virtual machines or interpreters. But you accept that you aren't going to write portable code either.
Nah. You don't have to use pointers very much these days. Stick to RAII techniques and although you'll still need 'new' to create objects occasionally you'll hardly ever need delete.
Most objects and structures will happily sit on the stack or as object data members and nary a pointer in sight.
I came to C++ from assembler but still found pointers hard.
The difficulty, I think, is not pointers but the subtleties of rvalues and lvalues. In most languages you can write x = y without understanding x is a reference or what that truly means.
In assembler assignment between registers is magical, memory locations are the lvalues, and you always explicitly convert an lvalue into an rvalue by fetching it into a register.
C/C++ sits between the two paradigms. You finally have to understand how the high-level view maps onto the low-level one. You have to recognise an implicit lvalue-to-rvalue conversion occurs to y in x = y but that a literal 2 is already an rvalue when you code x = 2 You have understand that operator& returns an rvalue. And you have to understand that assignment effectively means *&x = y
Building an accurate mental model of those steps is what's tricky. And C and C++ are the only languages that depend on you understanding that.
The only time raw pointers have any place in C++ is when you're wrapping up legacy C code. In some ways, I wish C++ had never attempted to be backwards compatible with C - So many programmers treat C++ as C with classes (aka structs with functions), which doesn't even come close to utilising the language properly.
It also probably doesn't help that there are very few well written C++ libraries/frameworks out there to at least serve as an example of how C++ should be done properly. The STL is fantastic these days, especially with all that C++11 has added. Boost libraries aren't bad, but even having been a C++ programmer for 12 years, I sometimes find the complexity rather irritating. The problem is that, for the most part, the STL and Boost are libraries of generic classes and functions. Generics are absolutely right for containers, algorithms and such, but do nothing to serve as examples of how framework level or end application code should be structured. That isn't a criticism of the STL or Boost by the way - Certanily, as far as the STL is concerned, it is entirely appropriate that it be a library of generics and not much more because C++ is a systems language and its standard library must minimize its dependencies on any particular underlying platform.
At least with languages like Java, Ruby, Python etc. there are plenty of libraries (for better or worse) which beginners can both use and draw inspiration from when designing their own code. C++ is always going to be bewildering to the beginner without good real world examples to illustrate the language. Unfortunately, some of the more prevalent C++ frameworks, such as QT and wxWidgets treat C++ like it's still 1998 (arguably for legitimate reasons) and are, I think, examples of how things should NOT be done in modern C++.
why the hell did I get downvoted for typing "C++ is harder for people because of pointers"
I mean I don't care about the downvotes themselves, but I didn't expect them so it's a sign that I failed to predict how people would react, and I don't like that.
Maybe people thought I was complaining about the language? No I don't find C++ hard. I was just pointing (haha) out my observations that people who find it hard tend to do so because of the pointers (and references) all the & * [] stuff.
"C++ and C are still the best languages for writing fast code without the need for awful virtual machines or interpreters. But you accept that you aren't going to write portable code either."
Depends on your definition of portable code. For me portable code means I can take it to another platform, compile it and it works. C++ does that fine.
You're thinking of portable binaries...
"C++ and C are still the best languages for writing fast code without the need for awful virtual machines or interpreters. But you accept that you aren't going to write portable code either."
Not really, modern Pascal variants will generate fast code without the need for awful virtual machines or interpreters. Plus unlike C/C++ it's even portable. :) And you can turn on array bounds checking and even integer overflow checking, if you want.
Seriously the big problem with C++ and to lesser extend C is the sheer amount of features. There is no clear concept behind it, it's just a pile of non-orthogonal features. Virtually nobody knows all of C++. Stroustrup claims that isn't a problem since you get by with just a tiny bit of it. In reality in a team everyone knows a different tiny bit of the language making it impossible to understand by the others.
C and C++ are also really bad "first" languages since you already need to know a fair amount of assembler to understand all the little important problems you will face.
BTW, porting C code from one machine to another isn't absolutely trivial. For example I once wrote a little piece of software running on both a Raspberry Pi and my desktop PC. The Raspberry Pi stored a timeval struct directly into a file and the PC was supposed to read it. Guess what, it didn't work, since my Pi has 32 bit integers for both values, while my PC had 64 bit values for both. Binary formats in C are not compatible. They are in fact not supposed to be since that's where Unix comes in. On Unix systems you would store that data in text form. And text would be compatible between multiple machines.
"The Raspberry Pi stored a timeval struct directly into a file and the PC was supposed to read it. Guess what, it didn't work, since my Pi has 32 bit integers for both values, while my PC had 64 bit values for both."
Are you really advocating passing binary files between different architectures? For a pet project? You imply this would work just fine with Pascal. Is that because no-one has bothered writing a 64 bit Pascal compiler, or that Pascal doesn't support 64 bit times?
What was your point again?
"C++ and C are still the best languages for writing fast code without the need for awful virtual machines or interpreters. But you accept that you aren't going to write portable code either."
I wouldn't say that virtual machines are intrinsically awful; the JVM is a very nice dev platform (I've used jruby, scala and java and various combinations of the three quite satisfactorily) its just painfully slow to start and devours a slightly depressing amount of memory. Contrast that with, say, the Lua VM which is tiny and startlingly fast... but lua only. They could be done better though, that's for sure.
Almost all my C++ code is platform independent, because I use it to write general purpose library code which can then be linked against whatever platform specific nastiness you like. If you're not using any OS-specific library calls, you can stick your code into a standard shared library behind a bunch of functions with a C-calling convention and call them from pretty much any other language on earth than supports an FFI.
C++ put me off C++. I read the books, I played with the language, I knocked things up and they worked. But it wasn't until I had to read someone else's C++ code that I realised what an horrendous mess there is to be made with perfectly good code, and how hard it can be to turn that back into something you can understand.
I loved learning about OOP, back in the day, and loved the concepts presented therein. But I've yet to find a usable and suitable syntax for expressing the ideas contained there. As such, I've stuck with C99 - which does everything I want and ever need, integrates with C++ libraries if I really need it to, allows me to *choose* how to program (hell, with a lot of compilers, I can mix and match C99 and C++ code and not even notice), is standardised across compilers (C++ was, historically, a mess - and may still be for all I know), is blindingly fast still, doesn't need interpreters or virtual machines, and can even be read by C++ programmers with ease (which is something that I can't claim works the other way round).
I find it quite interesting just how many libraries are actually still C99-or-similar, under the hood, and how easy it is to work with everything still just using C99 instead of C++. C++ hasn't become the major takeover of the language that I expected to come for years, and C++11 doesn't look like that will be either. You can still teach someone the entire C language and the standard library in a matter of hours. You could waste that just explaining how to use some of the more complex features like variadic templates correctly.
Yes, I grew up in an era of what is now referred to as procedural programming (it was called functional programming back in my day, but that's been subverted for something now related to mathematics more than programming, but I think that both "procedural" and "functional" were originally an accurate description - you're providing procedures, like NASA space operation procedures, to the computer to have it perform a function), and that almost certainly colours my view but the fact is that at the end of the day I want to give my computer a set of instructions that it carries out as I've told it to. The OOP overhead removes a lot of control which, if you're happy to give up, is fine. I don't like it, though.
As such, almost everything I write is in C99, can be read by any half-decent programmer, used by any half-decent programmer, extended by any half-decent programmer and get the most out of the machine even if it means I have to organise my code a little more carefully. It interfaces with everything, compiles quickly and without surprises and ports to any platform I like. And almost certainly the first compiler for any new platform will be a C compiler, not a C++ one (even though that can then follow quite quickly).
Call me old-fashioned, but C99 was where decent programming standards stopped as far as I'm concerned (which is probably another reason that C++ implementations are rarely completely compatible, and why it's taken so long to standardise the language, whereas C has been through several standardisations and added decent functionality that you can *see* and *use* each time, and which quickly find their way into compilers). Everything since then has been syntactic sugar that makes code unreadable, and sometimes unpredictable, and still has to be (pretty much) C99 compatible once you take that sugar away, and for which you need to have learnt C syntax to start.
The answer to every C99 vs C++ debate is C99's tgmath.h Ughh. We'll give you magic overloading but not the real thing.
And as best I can follow, your argument amounts to a lack of self restraint. Yes, C+++ contains many guns, but you don't have to fire any of them. Even the gcc folks have moved over to limited subset of C++; here are their reasons:
"Yes, I grew up in an era of what is now referred to as procedural programming (it was called functional programming back in my day, but that's been subverted for something now related to mathematics more than programming, but I think that both "procedural" and "functional" were originally an accurate description."
I grew up in that era too (well did my Comp Sci degree in 1986-88, not entirely sure that counts as growing up though). IIRC from lectures, procedural and functional programming are two different paradigms. Simply put, procedural programming is a flat-pack furniture assembly instructions approach to programming, i.e. "Take Tab A and insert into Slot B. Now bend over, look between your legs and tighten Screw C". Functional programming is an approach in which you write the code as a series of nested functions, and is NOT the same thing as procedural programming.
A spreadsheet (e.g. Excel) is actually a good example of a functional programming language, provided you don't use any VBA or Macros in it. Any cell may contain a value, in which case it is implicitly a function which returns the value, or it may contain an "= somefunction()". Any function may have further functions nested within it (including references to cells which main contain either values or further "= somefunction()", etc. The spreadsheet simply keeps evaluating nested functions to the lowest level until it produces the desired result.
ISTRC it can be mathematically proven that any functional program can be expressed as a procedural program and vice-versa (and empirically it is obvious that this is the case; the only means by which functional programming languages can be executed is by compiling them to machine code, which is a form of procedural programming).
Functional programming languages are not widely used for software development (though vast hordes of spreadsheet monkeys use them every day without realising it). You can figure out why if you try to code in a procedural programming language by creating user defined functions which consist of a single line which returns a value calculated using only using assignment, operators and other in-built and user-defined functions (which in turn can only consist of a single line). So no sequences of lines of code, no iteration, no control structures, etc.
You absolutely CAN write any program that you could write in procedural (or Object Oriented) manner within these constraints, but would you want to, and even if you did, what would happen if you tried to maintain it as requirements change, or re-use your code?
"Functional programming languages are not widely used for software development (though vast hordes of spreadsheet monkeys use them every day without realising it). You can figure out why if you try to code in a procedural programming language by creating user defined functions which consist of a single line which returns a value calculated using only using assignment, operators and other in-built and user-defined functions (which in turn can only consist of a single line). So no sequences of lines of code, no iteration, no control structures, etc."
IIRC LISP is generally called a "functional" language.
Of course it's functions are more than 1 line long.
As such, almost everything I write is in C99, can be read by any half-decent programmer, used by any half-decent programmer, extended by any half-decent programmer and get the most out of the machine even if it means I have to organise my code a little more carefully.
Yes, and almost everything I write in C++ can be read by any half-decent programmer, used by any half-decent programmer, extended by any half-decent programmer ( probably even you) and get the most out of the machine. And I can (and have, back in my undisciplined yout') mash up C to be the most unreadable mess you've ever seen (even worse than APL). Don't conflate the tool with the lack of skills of those wielding it.
"But it wasn't until I had to read someone else's C++ code that I realised what an horrendous mess there is to be made with perfectly good code, and how hard it can be to turn that back into something you can understand."
The phenomenon also known as "You can write FORTRAN in any language"*.
I should point out that while I don't have any affinity or much experience with FORTRAN, I recall thinking a few bits of F90 were neat when I was exposed to some FORTRAN written by reluctant programmers. :)
It's possible to make a mess in any language. While you may argue that some languages make this less likely to happen, in my personal experience the major factors in the b0rk-level of some code as follows:
1) Aptitude of the developers
2) Level of dependency of dynamic linkage (the downsides are not unique to Windows)
3) Platform
4) Vintage of the code
With respect to 2) I'd like to dump on over usage of dynamic linkage - with specific reference to Rabid Dependency Injection (I have seen DI work well, once, that was the only DI app I've worked on that was linked at build-time).
1) RDI apps take significantly longer to start up (dynamic linkage is expensive folks however it's done).
2) RDI apps usually suffer from narcolepsy (reminded me of good old garbage collection when ).
3) RDI apps often crash due to failed linkage at run time (due to a missing DLL, or the wrong DLL, you have little chance of getting hold of the correct one as the end user of course).
4) There is very little chance that the entire set of libs used by a RDI app when it was tested will be the same as the set that the user has available, rendering the testing null and void as far as the deployed app goes.
5) As a developer working on an RDI app you will spend a large amount of time hunting for missing DLLs, which in many cases have not been checked in. In the worst cases, which are alarmingly common, the missing DLL won't be noticed for a long time because the dev box you are working on has about ten million versions of it that DLL littered through out it's path - OR (even worse) - the particular code path is hit very rarely - usually during the year end batch at 3AM local time (the guilty developer will of course be long gone, natch).
I don't know... I am not a fan of virtual machines, but I adore JIT as a JIT if implemented correctly would do per processor optimization on the fly either at startup or after performing tracing. C++ is my baby, I grew up with it and have programmed it since I pirated my first copy of Glockenspeil C++ when I was 14. It is truly a thing of beauty.
I however have begun investigating compiler and operating system design and development using C++ derivatives since C++ doesn't have enough ++ for me anymore. I hate the static architecture of ahead of time compiling. I don't believe good code can be produced anymore in the modern world of processors. There are exceptions. The x264 guys being the primary exception. But they code in C and blatantly force incompatibility with C++... Often out of their own interesting principles.
I'll always love C++, but for now, I think JIT oriented languages are much better technically than C++.
No - programming put you off programming. All C++ does is try to do it 'properly' from pretty much just above machine code to the top.
Other languages to varying degrees do what MS does to IT in general - pretend its easy so they can sell it to you but when push comes to shove in the long run you have to re-thing and re-factor and re-write everything to fit in with the reality you hid from for years. To the point that many get stuck in, shall we call it the sme environment emphasis on the s), where you have made progress on the flat but not got any strength to climb the hills.
Programming is NOT easy - its a mathematical mapping of almost all of reality onto a computer - bit of it can be easy but the end game is never simple. Computer SCIENCE is difficult in any language. MS Office gave you the excuse to write voluminous documents to hide behind - code itself cant do that. .
Visual studio moving to C++11 might be portrayed as that excuse. But learn your trade and don't blame the language for containing concepts you haven't got a clue about yet.
I actually agree with you, C++ does try to make you do it properly.
I think the point you missed from the article and my original post was that uni lecturers dont try and teach you to do it properly.
Quite often, they are fairly removed from the day to day business of writing code for money, either they have been in academia for their entire working life or they have quit development to become teachers (at least in my experience).
There are some unis that do a fantastic job of teaching people how to write good code, regardless of the language used, within a context of real world applications.
I strongly feel that the best way to put someone off being a developer is to choose a language like C++ as their first exposure to programming and then get taught how to use it ...
"I strongly feel that the best way to put someone off being a developer is to choose a language like C++ as their first exposure to programming and then get taught how to use it ..."
Oh I don't know. Back when I was doing an initial Access to IT course, the tutor split the year into two classes. We both did VB and C++, however one group did VB first, the next group did C++ first.
I was in the group that did C++ first. It was only a very basic course, didn't even go very far into things like pointers, however it did teach some of the basic principles of OOP. When it came time to switch to VB, everyone in the class had become so used to C++'s idiosyncracies that they took to VB's hand-holding-but-slow-as-treacle paradigm like a duck to water.
The group that started with VB on the other hand, took one look at C++ and collectively shat their pants.
Sometimes, just sometimes, learning by going to the deep end and throwing yourself in can be a good thing.
"All C++ does is try to do it 'properly' from pretty much just above machine code to the top."
Ah, satire.
"Programming is NOT easy "
Well, not in C++ is isn't.
"But learn your trade and don't blame the language for containing concepts you haven't got a clue about yet."
Why are you not using assembler? Too lazy to learn the concepts, eh?
I used Stroustrups book to write a very simple program in 1996, and we still use it today, unmodified. Has saved us many hundreds of hours of work over the years, and eliminated errors.
Needs a kludge to get it to print from a win7 box, but hey ho.
Long live C++ - thanks Bjarne.
I used Stroustrups book to write a very simple program in 1996, and we still use it today, unmodified.
Okay, that startled me. I'm sure his writing has improved since then, but his first book was a miracle of obfuscation and a love of jargon. I suspect part of that may have stemmed from the fact that he wanted to show all the really cool stuff he'd created (multiple inheritance, for example, was not considered practical in a compiled language before C++; B.S. even said that he implemented it early because he was told he wouldn't be able to do it), but the end result was a book that was useless as a teaching tool and could only be used as a reference on a good day.
It sounds like fifteen years of experience has given him some perspective though. I'll be interested to see what his next book is like.
I don't mind writing in C++ it can be elegant. But I never want to have to look at someone else's code again, especially if they are some sort of macro freak that macros the entire project into a single line, which expands to a page of macros which expands.. ALT+F4,
The order in which you encounter things is important. Knowing C before being exposed to C++ it a bonus because it some things, like pointers, are not so scary. Starting C++ without knowing C must be hell. Originally, I found learning C hard becuase pointers were an entirely new concept after doing only Basic and a bit of Pascal.
The OO concept that came with C++ back in the 90s was blingingly elegant and exciting a the time. The hopes for widespread code re-use were never quite fulfilled, however. Perhaps because, as Lee Dowling says in here, the syntaxes required to describe and manage it are overly taxing.
Today I would choose procedural for more trivial problems, OO for the more complicated, or at least the rather low-rent OO offered by Perl. IMO pointers are so central to high level languages thay should be taught from day 1, like variables.
I know this sounds [insert favorite word for poser here], but C++ is the first language I learned - unless you consider DOS batch files a language. For me it was about being creative. I was 14 and wanted to make something. From what I remember, there was C and there was C++. Pascal was something else and the rest was historic. So I dug in and just used it. The funny thing is, in my carrier, I've written more code in other languages. I dare say that exposure to C++ as my first language may be the reason computer languages to not daunt me much. It's "If that what it takes approach", not a "But I can do it quicker in this language" approach. As I care about efficiency in all areas of life, I find myself going back to C and C++ recently for projects where I do have a say in the language as compared to all these new fangled languages that make it "easy" to write things.
For example, I'm guessing the only reason we have RoR is because someone what to write a dynamic web page in Ruby. Is Perl really that horrible? Well, perhaps try writing it in C++. ;)
>>or you just used a smart pointer
smart pointers are officially part of C++ already. But if you want to transfer ownership of a chunk of memory from one object to another, you still have to do some mucking about - it's not simple reference counting as that achieves something different.
How will this be achieved/implemented in the new version anyway, anyone got a code snippet?
>Every time the developer is responsible for memory, an opportunity for an error is introduced.
Evert time the developer is responsible for anything an opportunity is there. Until the day "programming" consists of asking the computer to do something for you then nothing will change. IMO memory handling is no harder - and conceptually a lot simpler - than plenty of other parts of modern development that language geeks rave about. Eg OO, generics etc.
You can't do that in C.
He's talking about declaring an array inside a function and then outside said function being able to move (not copy) that array over to another variable.
Show me how you do that in C without copying the contents of the local stack array into a passed pointer or reference.
Hahaha. True. But it's not clear to me why a Perl mess should evoke merely meh, wheres a C++ mess (or a C mess, for that matter) - and it is invariably code you didn't write - evokes the reaction that the author was an incompetent idiot who shouldn't be allowed anywhere near a serious compiler.
I programmed in C++ from 1987 until 2005, when we switched to C#. I still do have to maintain our old legacy C++ code from time to time.
My personal opinion is that switching from C++ to C# was the best thing we could have done! Most of what we were doing was UI code, and C++ is frankly totally crap for that. It's pretty good for device drivers and graphics libraries and other low level stuff. But for anything else, it's truly awful. And I say that from a position of having a GREAT DEAL of C++ experience.
Yes, I read - and understood - the seminal C++ books "C++ Templates" (Vandevoorde/Josuttis) and "Modern C++ Design" (Alexandrescu). Oh. My. God. To think I used to think it was all so cool - now I just think the language crawled up it's own arse and died... ;)
Oh dear god, that Alexandrescu book. I found myself thinking that I'd rather shovel pig shit for a living than have to work on a code base where ideas from that book had been used. It took the complexity and obscurity of template meta-programming to a point where I had to wonder about the author's sanity.
There was a time (my glory years as far as C++ is concerned) where I actually understood most of Alexandrescu's book. The object factory template stuff was weird but I got the gist of it.
Sadly since then I've been moved onto C# and r&d so my C++ skills are rusty.
C++ does take more effort than most languages but it also has the power and flexibility lacking from those languages. The trick to C++ is to code up your own 'meta language'. Wrap all the low-level arcane C++ in classes. Getting things like copy ctors and assignment operators working can be a pain but you only have to do it once.
The STL and Boost provide templates for most things you'll need - although I never liked basic_string and friends as it seemed too picky. String handling is so common that you don't want to be fighting a template to get the job done. One thing I loved about Borland's 'AnsiString' was that it had constructors for every type under the sun.
AnsiString wibble(10) gave you a string containing "10".
or
displayString(AnsiString("The answer is ")+a*b));
The ambiguity rarely caused me any problems.
"Wrap all the low-level arcane C++ in classes."
While I noted your qualification there, and I certainly have an do indulge in a bit of wrapping myself, I am finding that it is less and less necessary now because std libs bundled with most languages are pretty mature now and there seems to be quite a bit of feature swapping going on (this is a good trend IMO). :)
Frequently I have found wrapping to be a major source of obfuscation and screws ups (this ain't unique to C++ either). Essentially you're adding functionally useless code to a system that is almost guaranteed to have bugs of it's own.
It's not uncommon to find multiple wrappers for the same stuff in a large and/or old project simply because successive generations of developers have decided they don't like what's gone before but are too lazy/time starved to change it appropriately. :)
Also with respect to Borland's AnsiString thing, I liked it too. But I quickly worked out that the << and >> were just as easy (for me) - and the best bit is that they are ubiquitous.
Sadly I've just not done much C++ work of late. Mostly it's been C# - although that does show you the strengths of wrapping things up. Most of C#'s speed comes from having generally very good class libraries.
What I love about C# is the reduction in hassle. Having reliable syntax error highlighting and no headers/LIBs to locate and track is great. The hiding of pointers is good as well - if something compiles it nearly always runs. You almost never get the surprise crashes of C++.
But I also miss scrabbling around the covers. I suppose vehicle engineers have the same feelings. They probably love the ease of swapping out faulty components and going onto the next job whilst being a little sad that there's no carb to take apart and clean :-/
Oh and for the record garbage collection will never supplant RAII in my affections :)
"It's pretty good for device drivers and graphics libraries and other low level stuff."
I agree.
If I need to write something that has to manipulate data as quickly as possible, I'd opt for C++ and all of the wonderful memory control it provides; if I need a GUI or high-level RESTful web service (etc.), I'd go for Java or C# depending on any existing infrastructure.
My time is money, as is the time of the people that need to maintain my code in future, and C++ just costs more of both.
Sod the "best" arguments, the purpose of a programming language is to abstract away the problems you don't need to solve for your current work. If memory efficiency isn't important, why include it within your current solution when you could spend the time on other things?
That's the reason I don't do assembly at work, anyway. YMMV.
It will be expressive, efficient, and have an elegant simplicity. People will be able to master all its features in a week, while being able to easily express powerful abstractions and complex data structures. It will neither leak memory, nor perform garbage collection at random intervals. It will be automatically and transparently thread safe, and support inter process communication and synchronisation as part of the language. It will be fully deterministic, so that it can be used in real time applications, as well as being provably correct, for safety critical uses.
In the meantime, just pick whatever is least damaging to your sensibilities and most suited to your purposes.
That's why in most programming languages, particularly in C, people tend to define their own languages for their problem. For example by coding the logic into data and having a simple interpreter for that data. That data can then easily be understood.
There will never be a best language. Languages are tools, and we use the right tool for the job. Or sometimes, the wrong one, for lack of a choice, or out of familiarity and/or prejudice. "If the only tool to hand is a hammer, all problems look like a nail".
"It is easy to teach a list of features, but hard to teach good programming."
Which was my opinion of Stroustrup's "C++ Programming Language" - piss poor as a tutorial or a reference, more of a stream of consciousness as he walked through the myriad ways of accomplishing any one thing in C++. I have very little confidence that his new book will be any better, and I don't even see a need for it when Koenig and Moo have already written an exceptionally good introductory book on C++.
I taught myself C from the Kernighan and Ritchie book, which was a delightful jewel of simplicity (both the book and the language).
Later, I learnt C++ from the Stroustrup book, which by comparison seemed to comprise a large collection of complex ideas dumped from author's brain to paper with very little organisation in between.
The best thing I could say about Stroustrup's book is that it spawned a lucrative C++ publishing industry. Many authors must have made a good living selling us more books to explain what the hell Bjarne was on about.
Well, that would be a great idea, except that Bjarne didn't get round to publishing it until 2008. I was learning C++ in the early 1990s so it wasn't really an option was it?
Clearly you *can* learn C++ from that book. I and many others did, because that was all there was. The book just made learning harder than it could have been.
Mr Stroustrup is undoubtedly a brilliant computer scientist, but that doesn't make him a great writer. You can't simply excuse a disjointed, turgid and dense writing style by saying it's the reader's fault for not understanding the material. That's just lazy criticism.
No offence.
This post has been deleted by its author
A lot of "programs" are better expressed as data rather than procedural code (Finite State Machines come to mind). It's a pity few preprocessors approach the flexibility of BLISS macros (or even Macro-11) for this purpose, but you can usually make some headway with C/C++.
A lot of other programs are rendered almost unmaintainable by a tangled nest of conditional compilation that ought to have been abstracted out a much lower level.
Most of the use of the preprocessor I've seen in C++, unfortunately, falls firmly in the second category.
I found that the m4 macro processor is much more powerful than the crapola named CPP. You can even use it to replace that slow abomination called "template classes" in most cases. Debugging will be a breeze because you will debug into the generated source code, which is fully expanded and trivial to understand as compared to debugging into template code.
CATIA, for example, uses only macro-based collection classes.
“A lot of people look at C++ and want to understand every dark corner. This is what you do if you want to be a compiler writer, but most people should look at what is the easiest way to write a good solution for their problem," said Stroustrup.
Oh no. Heck no. Hell no. F*** no.
That's hacking, not programming. It leads to training people to hack, rather than to program.
If I appear to be repeating myself, it's because it's a Very Important Point.
The world has enough different languages already, generating lots of incompatible code. When your language encourages people only to learn subsets of itself, it becomes effectively a myriad of closely related languages, but undefined and uncontrolled languages. "So you're a C++ programmer. Does that mean C++.subset(a,b,c), .subset(d,g,z) or .subset(f,m,dribble)?"
I suppose it may be fairer to call it "dialectisation", but the end result is that code is harder to share and maintain, because programmers' expectations and assumptions vary so far from each other's.
People hack the solution from the coding techniques they know, because the right way to do it is obscured.
If you really want a language that supports multiple subsets of functionality, you have to find a way to segregate and mark them clearly and unambiguously, so that programmers are able to identify what they know and look for what they don't know.
Full ACK!
I'd like to ask that on C++ it's also important to know how the system works. The language kinda tries to hide the system from you, luring you into a false hope that you don't need to know what kind of machine code is being created.
So it's a big question whether you are a C++ programmer who thinks that out of index array accesses create exceptions, or one who knows what really will happen.
"So it's a big question whether you are a C++ programmer who thinks that out of index array accesses create exceptions, or one who knows what really will happen."
Ah, the joys of creating fencepost errors and wandering pointers, then wondering why your program is behaving "oddly", cannot be overstated.
"Oh no. Heck no. Hell no. F*** no."
Mmm, yes. He's kind of being forced into that position though. He can hardly turn around and say "Yes C++ is big and complex and has warts - DEAL WITH IT!!!" can he? I actually bought his "Programming Principles and Practice Using C++" out of interest and it is actually pretty good. His time as a lecturer does seem to have improved his writing and he is definitely acutely aware now of the issues involved with teaching programming.
He is very keen to attract the crowd that would otherwise run straight off to Python or C# etc. That's why he's trying to keep it simple for newcomers. Besides, learning through hacking is no bad thing. The problem is if one never gets beyond that stage! :-)
I cant see how C++ 11 will compete with Java or C# for ease of programming and rapid application developing. C++ is designed for embedded and systems programming allowing the programmer do dive into assembly when needed. The language is perfect for operating systems and some compute intensive calculations. The Java and C# languages are better suited for application programming and information systems programming. Compute intensive problems can be coded in C++ and accessed as modules by Java.
The reason some people have problems writing good computer programs is that they approach the subject from a bad perspective. The education system develops their minds to rote learn answers to questions. So if you ask them what is the Square Root of -1 they will correctly say i. This can also be extended to programming so an exam asking them to describe the difference between passing variables by reference or passing variables by value would most likely be answered correctly by most. What the people that cant program dont understand is that when writing a computer program there is no right or wrong answer. Its more like an Art where you craft your own kind of science to logically break down a problem and deal with. The overall programmed solution is deemed to be correct if your solution is internally logically consistent with itself and is able to correctly solve the problem outlined.
There always seems to have been this misconception amongst embedded systems programmers (of which I am one, although seemingly more enlightened) that C++ is somehow inherently more resource hungry than C. This simply is not true. There are actually very few language features that impose memory or execution overhead (basically just exceptions and RTTI) and only do so if used.
There are actually very few language features that impose memory or execution overhead (basically just exceptions and RTTI) and only do so if used.
And, in the case of exceptions, the overhead is typically no more than the size of the error-checking code you'd have to write if you didn't use exceptions.
This is, it's only overhead if you weren't going to do any error checking.
C Primer Plus and C++ Primer Plus, by Stephen Prata, were both great introductory books. Haven't looked at that type of work in 12 or 13 years, but I see there are newer editions. Both those books explained issues If seen expressed above in highly understandable language.
PS I am not related to or have any relationship with Stephen Prata.
Which was once the domain of Fortran, is now almost exclusively C++.
The computing core, not the the GUI, of course.
There many high quality, high performance frameworks that can be used to write amazingly complex simulations that would be just impossible to do in a single lifetime (ok, I exaggerate) if you'd start from scratch.
If you're curious about what can be done with C++, check these things out:
http://www.dune-project.org/
http://www.samrai.org/
https://computation.llnl.gov/casc/SAMRAI/SAMRAI_Software.html
http://fenicsproject.org/
These are just a few I have used one way or another, there are many many more. These mostly use very advanced C++ techniques, template metaprogramming and all that horrible stuff to provide tools that do very sophisticate operations with a reasonably simple interface. It's basically what one of the first posters to this discussion said: you have to encapsulate the C++ complexity. For many domains in scientific computing, this has been already done for you.
It really is quite unthinkable today to consider developing a large, complex simulation code in another language (but of course there are a lot of people who do that; I just think they are crazy :)
This post has been deleted by its author
Have you ever seen Holerith format used in anger? I have :)
I know about the Fortran holdouts, they're the crazy people I mentioned :)
Things are of course different when you have a code base in Fortran that has been developed for 35 years, you'd be crazy to just chuck that out of the window and restart from scratch in C++. Perhaps the majority of academic and scientific programming is writing and modifying a couple of subroutines in an existing program. Even if it takes the student six months to make heads or tails of the program, it's still better than rewriting from scratch. It'd be years before you had anything working, without any scientific advance, and no M.Sc., no Ph.D., and no papers during this period. All around Career Seppuku.
However, every once in a while, people do start new projects from scratch. It's a good time to start looking around for alternative development environments. If the project involves computational mechanics and finite elements, it's quite likely that by using FEniCS/Dolfin (for instance), you'll get results a lot faster.
At the end of the day, I think we'll see evolution in action, if you depend on writing computational mechanics code to get scientific results, you'll get them so much faster with a proper environment (say FEniCS/Dolfin or OpenFOAM) that you'll leave old school scientists/programmers behind. You can't just wait for the old professors to die out (that hurts a little bit because I think I can be considered one of them), because they (we) tend to leave our disciples in our places. It's necessary to out evolve the strain :)
I'm pretty language agnostic as well, and I also use Python a lot (and matlab, and fortran, and macro languages of commercial finite element programs, and pretty much whatever it takes..) It's not really a question of C++, it's much more a question of the supporting frameworks, that nowadays are mostly written in C++. In fact, some of these have excellent interfaces to Python, using these interfaces really is the best of all worlds.
Firstly, one has to specify which FORTRAN. 77? 95? 2008? The language has evolved a great deal, possibly even more so than C++
Secondly, people who attack it fail to realize that even FORTRAN-77 had two huge advantages over its competitors.
One was for the scientist/programmer. The compiler could/can autogenerate code to check array subscripts at runtime. Given the declaration REAL A(100,200) then any reference A(I,J) is invalid if I<1 or I>100 or J<1 or J>200. With the compiler generating subscript checks, many bugs immediately crashed the program, rather than randomly corrupting random data elsewhere. C compilers couldn't do this.
Note also that (say) I=101 and J=1, or I=2000 and J=-1, are detected as programming errors even though in both cases the result of blind address arithmetic will be within A
And when the program was debugged and ready for use in anger, you recompiled with checks off and other optimisations on. Which meant that number-crunching code in FORTRAN could be faster than in C, the second huge advantage.
In particular, a FORTRAN compiler is permitted to assume that in a subroutine
SUBROUTINE FRED( A, B, M, N)
REAL A(M,N), B(M,N)
there is no memory overlap between the arrays A and B, which allows for many optimisations of statements like
DO J=2,N
DO I=2,M
A(I-1,J-1) = A(I-1,J-1) + B(I,J)
...
IN C-style languages A and B are pointers to chunks of memory, and the no-overlap assumption can't be used in nearly so many contexts.
Since F77, FORTRAN has advanced so that now many operations on arrays can (and should) be expressed as a single statement with no sequencing specified by the programmer. The compiler is free to perform whatever sequencing and parallelisation it thinks will work best. Your FORTRAN 2008 code is hardware architecture-independant. Your compiler generates a realisation that best exploits whatever it's running on, be that a pair of Intel Xeons with four cores apiece and a single RAM address space, a top-of-the-range or a cluster of a few such beasts, or tens or hundreds of them, that you wish to use in parallel.
Automatic parallelisation is a big and hot topic and probably still in its infancy. Recent FORTRAN languages have at least freed the compiler from arbitrary constraints accidentally imposed by a programmer who previously had to specify an arbitrary sequence and who couldn't indicate that he really didn't care about the ordering of this or these loops.
That said, I'd stil choose to write the outer parts of my programs in Python (using NumPy, SciPy, and suchlike) and call from there to number-crunching codes written by experts.
Hey, don't educate all these C++ retards who think that their language is "more modern" than Fortran. You could case serious depression when they discover that all these low-level features like "every pointer can be used like an array variable" are actually a regression.
Don't tell them about Fortran's automatic for-loop reordering by the compiler; that could damage their adolescent brains forever due to an inferiority complex.
And please, don't ever pair Fortran with a powerful macro language (such as m4) or custom code-generators to rip the crap out of C++. You have to think about that disadvantaged youth who never had time to get a real education into advanced numerical processing ! You want to make them unemployed or what ???
This post has been deleted by its author
A few people code in Python - and quite a lot of these people use it for intensive tasks, which makes me quite worried for the laptops they then try and run it on
If they know what they are doing, they are using NumPy and SciPy and suchlike. That means that you do the high-level stuff in a high-level language (Python), but delegate the number-crunching (inner loops, BLAS) to library code written in whatever low-level language the library author chose to use. Actually, there are multiple choices: the same library interfaces compiled with different optimisations (say for Athlon, or Intel Xeon, or rewritten using CUDA for offloading onto an NVidia GPGPU).
It's a VERY productive way to go.
The principle was much the same back in the 1970s when a sensible scientist called a NAG library routine whenevr he could. Do as litle coding as possible in (back then) FORTRAN, leave the details of how to get the most out of the hardware and how to tame the numerical methods to the experts. All that's really happened is that a much more powerful and expressive language (Python) has displaced FORTRAN, C and C++ as far as stringing together calls to library code is concerned.
Incidentally the overhead of doing inner loops and all in Python is a factor of ten at worst. In cases where the prospect of getting ten times as much computing done isn't attractive because human thought, not CPU-hours, is the rate-determining factor, then why care about efficiency?
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
