Stroustrup Says C++ Education Needs To Improve

simoniker writes "Over at Dr. Dobb's, C++ creator Bjarne Stroustrup has given an in-depth interview dealing with, among other things, the upcoming C++0x programming standard, as well as his views on the past and future of C++. He comments in particular on some of the difficulties in educating people on C++: 'In the early days of C++, I worried a lot about "not being able to teach teachers fast enough." I had reason to worry because much of the obvious poor use of C++ can be traced to fundamental misunderstandings among educators. I obviously failed to articulate my ideals and principles sufficiently.' Stroustrup also notes, 'Given that the problems are not restricted to C++, I'm not alone in that. As far as I can see, every large programming community suffers, so the problem is one of scale.' We've discussed Stroustrup's views on C++ in the past."

Comments

more to it

[g2devi]

That may be so, but there's more to it. It's only been recently fully implemented and a few years ago Stroustrup himself commented that he's constantly surprised that some things (e.g. template recursion) are even possible in C++.

The language is overly complex. The key advice any C++ expert is "restrict yourself to a specific subset of C++". That's the bulk of the difficulty. If C++ were simplified to include only that subset, you'd have a lot less need for training,

Re:more to it

[JohnFluxx]

Sometimes you need the more complicated parts of C++ - It would be a very bad idea to simplify c++ to the lowest common denominator.

For example, most people don't use the SSE stuff or even know about it. You can, for example, make a vector with 4 numbers in it and multiply it with another vector with 4 numbers in it. The result is that the four multiplications are done simulatanously.
Most people won't use this functionality and thus don't even need to learn it, but when you need an algorithm to run fast, it is essential.

Re:more to it

[shutdown -p now]

Unfortunately, even if you keep away from the more advanced stuff such as template metaprogramming, there's still plenty of surprising (in a bad sense) behavior in the most basic C++ constructs (mostly inherited from C, but exacerbated by C++ pretense at high-levelness, and with some new stuff thrown in for good measure). Pointer arithmetic, unsigned types, silent implicit narrowing conversions, PODs vs non-PODs (which in turn separate into aggregate types and everything else) and the subtle differences in initialization of those, ability to delete void* and pointers to incomplete types (and the wonders of virtual destructors), etc... The language is a mess, really. It is very powerful, and the existing code generators are very good at optimizing stuff, but writing in C++, or any subset thereof, requires a very good understanding of subtle details.

A simple example: given a vector of ints, calculate the average value, using standard idiomatic C++. Let's give it a try:

#include <algorithm>
#include <iomanip>
#include <iostream>
#include <istream>
#include <iterator>
#include <numeric>
#include <ostream>
#include <vector>

int main()
{
std::vector<int> v;
std::copy(std::istream_iterator<int>(std::cin), std::istream_iterator<int>(), std::back_inserter(v));
int avg = std::accumulate(v.begin(), v.end(), 0) / v.size();
std::cout << avg << std::endl;
}

A simple task, and a clean implementation, using the standard library as much as possible. No fancy language features used - no template metaprogramming, no pointers, no virtual inheritance. The kind of stuff a new C++ programmer might write after reading Stroustrop. And yet, it gives wrong result for certain input data. Now, who'll be the first one to spot and explain the problem here, preferrably without actually running it? Bonus points for explaining why we need "istream", "ostream" and "iomanip" headers here in addition to "iostream" (and we do, if we want this to be portable).

Re:more to it

[johannesg]

The "restrict yourself" stuff is stupid. It's like saying "tie one hand behind your back while programming". Can you think of *any* other profession where professionals are advised not to use their best tools?

The correct advice would be, "use precisely what you need and no more".

I have been programming in C++ for a very long time, and I have needed *every single tool* that some of you nay-sayers would say was unnecessary. And that's needed in the sense of "the best solution was achieved using these tools", not "I padded my CV by adding unnecesary complexity".

Re:more to it

[truedfx]

I'll admit I had to run the program, and even then it took me a while to see it.

v.size() has vector<int>::size_type as its return type. Depending on which specific type, either that type will be converted to int, and all is fine, or the result of std::accumulate(v.begin(), v.end(), 0) is converted to an unsigned type, then divided, and then converted back to int. In the latter case, when you have a negative sum, the division gives the wrong result.

I think the <istream> and <ostream> headers are required because the types of std::cin and std::cout might otherwise be incomplete, meaning operator<< might be undeclared. I know the <ostream> header is also required to that std::endl is declared. I'm not seeing what could be in <iomanip> that's of interest of your program. Could you explain that last one?

I got my B.Sc. in Comp. Sci in the 1970s and ...

[Anonymous Coward]

I think COBOL and Fortran education needs to improve. Nobody knows how to use it nowadays. These kids and their OO languages... HEY! Get off my lawn.

Re:Education, even at Universities, needs to Impro

[IamTheRealMike]

My university course spent about half an hour on pointers in a 3 year course. Most of that half hour was factually wrong: the slides were full of code samples that wouldn't compile or would always crash.

They did, however, spend two terms teaching Hoare logic. Or rather, they spent one term teaching it, and then repeated the same material in another term with a different lecturer, because their communication was so poor they never realised they had duplicated their teching.

Friends at other universities reported similar stupidities, though not always on the same scale.

C++ is a rather complex language, but simplifying it won't help. The problem is that low quality education is rampant.

Re:I'm just glad they're teaching C++ actively aga

[thetartanavenger]

Where are they teaching it actively again? I'm a student on computer science at the moment and all they teach in any depth is Java. The only reason I know c++ is my desire to learn it, despite the fact that various parts of my course have recently required a fairly in depth knowledge of c++.

My favorite lecturer quote, "Oh, I don't really do any coding at all".

He should go work for Microsoft ...

[Pinky's Brain]

"The standard will be finished in late 2008, but it takes forever to go through all the hoops of the ISO process."

They have a solution for that ...

Re:C++ has issues

[IamTheRealMike]

C++ isn't going anywhere. Nearly all serious desktop software outside of Mac-land is written in it because the alternatives (Java? C#?) suck rocks. Large amounts of high performance code is written in C++. I don't know where you got the idea that people who care about performance use C from, that's flat wrong in my experience. I agree that D is a very nice language. It will make great strides in the next five yeras. However, maturity counts for a lot.

Re:Maybe the real problem...

[ubernostrum]

Computers and the logic that runs them is complex and brittle, thus why it is important that developers understand a lower-level language like C++.

...and several previous generations of programmes roll over in their graves at the thought that C++ is a "lower-level language".

The thing is, C++ is huge. Just to have a solid working knowledge of the core language, you need to master whole rafts of things that have nothing whatsoever to do with the low-level operation of the machine, because even the core is a labyrinth of obscure corner cases that make language lawyers drool, and which, if expressed in pseudo-code, would be a bunch of gigantic switch statements with a couple dozen levels of ifs nested inside each case. Now, add the STL on top of that, and add common third-party bits like Boost on top of that, and you're left with a monstrosity. To really understand programming at a lower level, you need at best only a small subset of C++, and unfortunately for C++ that subset is properly called "C".

Java put you on Skid Row?

[Latent Heat]

Let me get this straight, that some wieners at Purdue decided to teach Java instead of C++ in their Intro to Programming course, and that you had a wiener of a prof who was teaching you Java without adequate experience, this all put you on the path to dropping school, dropping your CS major, and taking courses at community college without finishing a degree?

I will grant you that if you or the parents are shelling out the Purdue tuition, maybe their CS department should find a better professor for their intro course. I am sorry to hear that this experience dissuaded you from completing a CS degree, and there is probably a lot more to your personal story than can be shared on Slashdot.

But I would like to communicate to others out there that you will have a few good teachers in your educational career who are really inspiring, a vast group of average teachers, and a number of who you consider to be really, really bad teachers. The "bad" teachers are that way (in your opinion) for a number of reasons -- they may be "nice guys or gals" who don't have enough preparation or smarts to teach, they may have admitted to you gaps in their preparation that you have taken upon yourself to hold them in disrespect for, or maybe they assign too much HW and work you too hard.

If one is going to take a passive approach, show up to class and demand, "Here, educate me", that is a good way to fail at getting a degree and also to fail at every other opportunity that presents itself down the road. If one is going to take an active approach, working as hard as one can at learning from all teachers, the good and the bad, supplementing gaps in instruction with self-study, working coding jobs, group study, one is going to be successful at college and everything else.

To suggest that a person can have one "bad" prof means that they are on the street drinking methyl antifreeze out of a jar wrapped in a paper bag, this suggests a very passive approach to not just education but life in all its aspects.

Re:I'm just glad they're teaching C++ actively aga

[skroll82]

"My favorite lecturer quote, "Oh, I don't really do any coding at all"." That's not a big deal. Computer Science is not about coding in particular, but understanding the practices to design and implement solutions to a problem. Computer Science is more about applied math then writing in language X. I learned some of the most important concepts in a class that was all done in pseudocode. Understanding how to approach a problem and solve it efficiently is more important then learning a language. In fact, once you know how most things are working, with a few basic concepts such as pointers or how a computer interpret an instruction listing, you should be able to pick up almost any language fairly easily. If you are not capable of learning things on your own without being handheld through a set of power point lectures, even if you knew C++ instead of Java you aren't going to be worthwhile in the real world anyways. You are destined to be a code monkey.

Re:I'm just glad they're teaching C++ actively aga

[Anonymous Coward]

Hello Gentlemen,

I'm a first year programming student at an Ivy League school and I've just finished my Visual Basic classes. This term I'll be moving onto C++. However I've noticed some issues with C++ that I'd like to discuss with the rest of the programming community. Please do not think of me as being technically ignorant. In addition to VB, I am very skilled at HTML programming, one of the most challenging languages out there!

C++ is based on a concept known as Object Oriented Programming. In this style of programming (also known as OOPS in the coding community) a programmer builds "objects" or "glasses" out of his code, and then manipulates these "glasses". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "glasses".

Please allow me to make a brief aside here and discuss the origins C++ for a moment. My research shows that this language is one of the oldest languages in existence, pre-dating even assembly! It was created in the early 70s when AT&T began looking for a new language to write BSD, its Unix Operation System (later on, other companies would "borrow" the BSD source code to build both Solaris and Linux!) Interestingly, the name C++ is a pun by the creator of the language. When the first beta was released, it was remarked that the language would be graded as a C+, because of how hideously complex and unwieldy it was. The extra plus was tacked on during a later release when some of these issues were fixed. The language would still be graded a C, but it was the highest C possible! Truly a clever name for this language.

Back to the topic on hand, I feel that C++ - despite its flaws - has been a very valuable tool to the world of computers. Unfortunately it's starting to show its age, and I feel that it should be retired, as COBOL, ADA and Smalltalk seem to have been. Recently I've become acquainted with another language that's quite recently been developed. Its one that promises to greatly simplify programming. This new language is called C.

Although syntactically borrowing a great deal from its predecessor C++, C greatly simplifies things (thus its name, which hints at its simpler nature by striping off the clunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "glasses". Instead C uses what are called structs. Vaguely similar to a C++ "glass", a struct does away with anachronisms like inheritance, namespaces and the whole private/public/protected/friend access issues of its variables and routines. By freeing the programmer from the requirement to juggle all these issues, the coder can focus on implementing his algorithm and rapidly developing his application.

While C lacks the speed and robustness of C++, I think these are petty issues. Given the speed of modern computers, the relative sluggishness of C shouldn't be an issue. Robustness and stability will occur as C becomes more pervasive amongst the programming community and it becomes more fine-tuned. Eventually C should have stability rivaling that of C++.

I'm hoping to see C adopted as the de facto standard of programming. Based on what I've learned of this language, the future seems very bright indeed for C! Eventually, many years from now, perhaps we'll even see an operating system coded in this language.

Thank you for your time. Your feedback is greatly appreciated.

Strostrup is the problem

[Animats]

The big problem with C++ is Strostrup. He's in denial about the fact that the language is fundamentally broken. But he's still influential in C++ circles. Thus, no one else can fix the mess at the bottom.

The fundamental problem with C++ is that it has hiding ("abstraction") without memory safety. This is the cause of most of the world's buffer overflows. No other major language has that problem. C has neither hiding nor memory safety, so it is still vulnerable to buffer overflows, but they're to some extent visible at the place they occur. Pascal, Modula, Ada, Java, C#, and all the interpreted "scripting languages" have memory safety. C++ stands alone as a language where you can't see what's going on, and the compiler doesn't have enough information to check subscripts.

The reaction of the C++ standards committee has been to try to paper over the problems at the bottom with a template layer. That didn't work. The template classes just hide the mess underneath; they don't make the language memory safe. There are too many places that raw pointers leak out and break any protection provided by the templates. The template language itself is deeply flawed, and attempts to fix it have resulted in a collection of "l33t features" understood and used by few, and too dangerous to use in production code.

The fundamental cause of the trouble comes from C's "pointer=array" equivalence. That was a terrible mistake, borrowed from BCPL. The trouble is that the compiler knows neither which variables are arrays nor how big the arrays are. You can't even talk about arrays properly. I mean, of course,
int read(int fd, char* buf, size_t len);
That's just trouble waiting to happen. "read" has no information about how big "buf" is.

C++ added references to C, and should have added syntax like
int read(int fd, char& buf[len], size_t len);
to go along with it, so that arrays became first-class objects with sizes. But it didn't. There are some other things that have to be done to the language to make this concept work, but this is the general idea. This is the elephant in the living room of C++, and Strostrup is in denial about it.

Every time you have another crash from a buffer overflow, every time you install another patch to fix a buffer overflow, every time you have a security break-in from a buffer overflow, think of this.

Re:C++ has issues

[SageMusings]

Real Mike,
you have my full attention. Please, support your assertion that Java and C# suck rocks.

C++ can be fast at execution time but the development time is prohibitive in many applications where you need to be agile and actually ship code in a hurry. I try not to get hung up on all the esoteric points of different programming languages, although I am quite amused to read other's comments. Yet, I will hazard a post on this topic.

I learned C++, not all of it to be sure, but the portions 85% of us might need in a given project. It may be intellectually stimulating to code an app form a "purest perspective" but many of us have to earn a living and produce a lot of code in short order. C++ does not fit this bill. Most applications just have to work and work today, not next quarter. Then we have to extend the app after a few months. Since C++ is quite a bit harder to read and I have to learn code I did not write in short order to perform this maintenance, I enjoy Java and C# apps a lot more than ones coded in C++.

Please, tell me why Java and C# suck compared to C++ in the practical world. Nearly all of us are not writing low-level, time-critical code. Most of us write apps for business transactions. I happen to write business software that is widely distributed and the C++ performance boost is nullified by the latency of remote calls to distant servers.

Please, tell me the advantage of writing an app in a year vice 6 months.

There are many languages because there are many problem domains. C++ is not the best language. There is no best language, period.

Nearly all serious desktop software

Finally, it has been my observation most "serious" code is no longer constrained to the desktop.

Re:So long its not Matlab

[William Stein]

> What the community needs right now is a Python distro with enough of a
> numerics and graphics package rolled in to do 90 percent of what is in
> Matlab.

Good idea. This is what both Sage and the Enthought Python Distribution are
shooting for.

> (Are the Python people still hashing out that Numerics/Numpy divide?

No that is done. And the lead developer of Numpy -- Travis Oliphant --
now gets to work full time on Python scientific computing, as an
employee of Enthought.

> Is there an engineering graphics library that is Numerics/Numpy compatible?

There is Matplotlib for
matlab like numpy graphics, and Chaco for more dynamic 2d graphics. MayaVi and Sage both provide powerful 3d graphics.

Computer science is about concepts, not syntax

[Capt. Skinny]

I'll never forget those fateful words from the professor: "I don't know this language myself, so I'll be learning it with you as we go."

Isn't the whole idea of a Computer Science education to learn the underlying concepts of programming, not just the syntax or semantics of a particular language? The programming language used is merely a vehicle for conveying those concepts. The professor who was "learning [J++] with you as we go" was referring to the specifics of the new programming language, not the concepts that he was going to teach in the course. Presumably (unless he was unfit for his position), he knew those concepts well and was able to convey them to the class using whatever syntax and semantics were thrown in front of him.

The quote I'll never forget came from one of my professors during an advising session: "I'll often get calls from IT managers asking if we have any graduating students who know COBOL. I always tell them that ANY of our graduates could know COBOL - and ask if they are hiring someone for their intellect and understanding of programming concepts, or for their knowledge of a particular language."