Stroustrup Says C++ Education Needs To Improve 567
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."
Not another I/O Rewrite please! (Score:1, Informative)
Bjarne: C++ should evolve, but there's a mass of C++ code already out there. Improve it please, but don't make us go back and rewrite existing code.
Re:more to it (Score:5, Informative)
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:I'm just glad they're teaching C++ actively aga (Score:5, Informative)
My favorite lecturer quote, "Oh, I don't really do any coding at all".
Re:more to it (Score:5, Informative)
I focus instead on restricting programmers to the tools they need, so they focus their creativity on algorithms instead of coding methodology. I've even codified it all, as an extension to C [sf.net], rather than C++. Works great for team programming. I had a guy last week write two IC placers: simulated annealing, and quadratic placement, in 5600 lines of hand written code, debugged and working. He did it in 6 days while supporting a difficult client, without working weekends or evenings. I'd estimate his productivity at 10X to 100X higher than average.
Re:I completely agree (Score:5, Informative)
I agree with the premise that C++ is a great language, that is poorly understood, and often mis-used. Education would seem to be the answer to that.
Re:I'm just glad they're teaching C++ actively aga (Score:3, Informative)
Re:I'm just glad they're teaching C++ actively aga (Score:2, Informative)
That's imperative programming.
You get functional programming with lisp, scheme, python, ocaml, haskell.
I've written some educational C++ articles (Score:5, Informative)
The articles are:
- Sermon at the Soup Kitchen: On C++ Software Quality and Institutional Resistance to Change
- Pointers, References and Values: Passing Parameters, Returning Results, and Storing Member Variables with Musings on Good C++ Style
- On Refactoring C++ Code
- Pointers to C++ Member Functions
I'm no Stroustrup, but I've received quite a bit of praise for writing these.Re:I'm just glad they're teaching C++ actively aga (Score:2, Informative)
Re:So long its not Matlab (Score:5, Informative)
> numerics and graphics package rolled in to do 90 percent of what is in
> Matlab.
Good idea. This is what both Sage [sagemath.org] and the Enthought Python Distribution [enthought.com] 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 [enthought.com].
> Is there an engineering graphics library that is Numerics/Numpy compatible?
There is Matplotlib [sourceforge.net] for
matlab like numpy graphics, and Chaco [enthought.com] for more dynamic 2d graphics. MayaVi [enthought.com] and Sage [sagemath.org] both provide powerful 3d graphics.
Re:more to it (Score:3, Informative)
Re:Right on (Score:2, Informative)
Re:more to it (Score:3, Informative)
Re:Maybe the real problem... (Score:3, Informative)
Have you ever used C++? Python's lists correspond (roughly) to C++'s std::vector, and the Python list sort() method corresponds to C++'s std::sort(). No need to reinvent any wheels here.
In case you just meant that there is no exact match for the Python list class in C++, then that's true. But that is true for all languages but Python. Also keep in mind that Python (which I like and use regularly) buys its incredible powerfulness and simplicity by being one of the slowest languages around. One of C++'s design goals was to never be so slow that the user has to resort to another language, and that prevents it from having much of Python's convenience.
Re:I'm just glad they're teaching C++ actively aga (Score:3, Informative)
In my experience there's no language that's more suitable for gigantic software projects with millions of dependencies than Java. Admittedly I don't have much experience with Python and Ruby yet, and while I see those two as advanced scripting languages, other people keep using them to build large software projects in less time than it takes in Java. But compared to C++, maintaining very large projects is much easier in Java.
If you can try to define your point, pitfalls and workarounds, perhaps someone here can give you some advice. On the other hand, all large, complex projects have their pittfalls and occasionally require workarounds. It simply comes with the software engineering territory.
Re:myth (Score:3, Informative)
Wrong.
C++, like every sufficiently useful programming language, is a multi-paradigm language. It is dominantly procedural, this is true, but it also has language support for OOAD (which is not the same thing as OOP, as you correctly pointed out), generic programming, generative programming and facilities for adding embedding different kinds of of DSELs in convenient library form.
Anyone who says "C++ is object-oriented" are, much like those who refer to the non-existent language "C/C++", probably using C++ incorrectly.
Re:more to it (Score:2, Informative)
Well, the first problem I see with this code is that it uses integer division. The fact that "/" on integers gives an integer division isn't just a problem of C++, but of many languages (Pascal did get it right by using a separate operator, div, for integer division, and reserving / for float division). Thus if you enter the numbers "1" and "2", instead of the correct answer 1.5 you'll get 1. To get floating point division, you must have at least one of the types be a floating point type. This could e.g. be done by replacing v.size() with double(v.size()) or (preferrably, because it avoids a type cast) (v.size() + 0.0). Of course, the variable avg shouldn't be int either, but a floating point type.
Another problem of the code is related to the fact that v.size() is an unsigned type, which will give unexpected results if the sum on the left is negative (but then, this problem wouldn't occur if the correct floating point division was used). This is due to the rule inherited from C that mixing signed and unsigned in arithmetics will cause the signed value be converted to unsigned. This can also give other surprising results; e.g. v.size() > -1 will always evaluate to false.
The code also has other problems, like missing error handling for I/O errors and for empty sequence (i.e. no numbers given at all, which will result in division by zero). But that's hardly a language problem.
We don't. Only "iostream" (for std::cin and std::cout) and "ostream" (for operator>, but istream_iterator for input (the fact that istream_iterator internally uses operator>> is irrelevant here; it's the job of the "iterator" header to make sure everything needed in the implementation of the iterator is included; indeed, on a compiler implementing export, might only be included in the corresponding