Slashdot Mirror
Interview Update With Bjarne Stroustrup On C++0x
An anonymous reader writes "DevX interviewed Bjarne Stroustrup about C++0x, the new C++ standard that is due in 2009. Bjarne Stroustrup has classified the new features into three categories: Concurrency, Libraries and Language. The changes introduced in Concurrency makes C++ more standardized and easy to use on multi-core processors. It is good to see that some of the commonly used libraries are becoming standard (eg: unordered_maps and regex)."
I saw the headline and thought I was seeing some 1337 form of "cox."
huhuhuuhuhuh he said "form."
If anyone has used both Objective-C and current C++, can anyone tell me whether the new specification is a clear improvement on either if these?
Jumpstart the tartan drive.
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python, or whatever is your preferred language.
"control of alignment"
I'd like chaotic good please
Knowledge is power. Knowledge shared is power lost.
Yes.
I'm a big tall mofo.
Yes. It's already been done once, aka C99. This isn't the thing that will replace C++, it's the next revision of the language, with multithreading support etc. Once C++ has worked out the hard stuff, C will have it's own next revision based on that.
Once everything's finished, it should be finalized as C++09. It may carry on another year, in which case you might call it "C++0xa" ;)
I Browse at +4 Flamebait
Open Source Sysadmin
Been there, done that.
Most of the time, the potentially reduced running time of the C++ implementation never comes close to the months saved in development.
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
If you mod me Overrated, you are admitting that you have no penis.
I want to like C++, heck, it was the first language I learned. But after so many hours of memory leaks and pointer-induced errors... My friend had mentioned at one point there was going to be transparent garbage collection in the C++0x standard. Unfortunately... looks like it's tabled for now: http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_garbage_collection Oh well.
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python
Those languages are way too high level. What you make up in development time will nowhere near compensate you for the greater processing time. I mean, CPU costs are through the roof these days!
But I have to say - even C++ is too high level. I hand code assembler with vi. That's what real number crunchers do.
I'm a big tall mofo.
...or, as a former manager explained it, "When C++ is your hammer, everything looks like a thumb."
So we are going to create the unmanaged form of C#?
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Most/All NDS games are Written in C++. C++ is a great language because it allows you to do so many things and still run fast. BTW i love this quote from Bjarne:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off."
-Bjarne Stroustrup
Yeah except he's absolutely wrong. C++ makes it much easier to shoot yourself, but the effect is more like dropping an atomic weapon on yourself.
I think Alan Kay put it best:
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."
Kay goes on further to categorically state that C++ does not support object oriented programming because of the static type system.
hours finding memory leaks? How bad are you at debugging? Plus there are tons of tools to assist with memory leak detection. However, protection is no substitute for abstinence. Learn to write code better. BTW go do some embedded software with C# or Java.
I have C++ code that I maintain. It was written in 2004. I also use Firefox, Notepad++, FileZilla, 7-Zip, which are all written in C++. It seems like most the applications I run are written in C++, with many written in C and some Microsoft programs perhaps written in C#. Java killed C++? You wouldn't be aware of it from the software on my computer.
What a fool believes, he sees, no wise man has the power to reason away.
There's only one interview with Stroustrup that's worth reading: http://www.nsbasic.com/desktop/info/interview.shtml
{Science sans conscience n'est que ruine de l'âme}
That's what this is... automatic memory management...bigger libraries... restricting pointers more and more....
I mean, C++ is evolving so badly it makes Pascal suddenly look a lot better as a compile time language.
This is my sig.
...what do people find so difficult about C++? Use the standard libraries, exception handling, and make sure your news all have deletes, and it's no more difficult than any scripting language. I actually prefer it over scripting languages, which have their place, but feel all sloppy and unspecific. It's like the difference between building a house out of 2x4s and building one out of sticks you found laying on the ground.
I'll consider Java and C# as C++ replacements once they get:
These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.
To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.
This sig does not contain any SCO code.
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
Agreed. Premature optimization is the root of all evil. Write the control flow in a high-level, easy-to-debug language, and later optimize the pieces running unacceptably slow by rewriting them in C. No object-oriented language with legacy holdovers, static typing, and gross syntax needed.
Despite knowing it is a fallacy, I will instruct by appealing to my experience: 27 years coding, 10 of that with a salary, and 5 years before that as an entrepreneur. I have forgotten more C++ than most people know, having written everything from a reference-counting garbage collector to an entire content management system in it... and with the benefit of 7 years of professional C++ development, I can say with a straight face that it is the wrong tool for every job.
[ home ]
http://yosefk.com/c++fqa/ - this site says it all.
And it's also being argumentative and verbose at that, unlike your routine 'C++ sucks' rant.
I've found that the biggest advantage for C++ is the portability. I have written an application backend for PC's (back in the days of DOS) and since then ported it through various versions of windows, Linux (for web use), Palms, and Pocket PC's.
Using C++ allowed me to very easily make the different processor needs, compatible, by writing little compatibility layers, which would swap bigend values, unpack data structures from disk into memory (so is on even boundary). and so on.
Yes the fast speed was why I originally went with the C/C++ route, but the big benefit has been the portability.
...and roll on the C++-hatred! Second C++ article in a short time, and again lots of venom and anger. "Months saved in development"? Really? What are you doing, implementing your own OS before you start application development? Here's a newsflash: C++ also has support libraries, just like Java, Perl, Python and Ruby. They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way), but that doesn't mean they don't exist.
Anything you could want for in a modern language is there. And nobody is holding a gun to your head and making you write those scary templates if you don't want to.
I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++. Not that there is nothing to criticize about it, but it is still an amazingly powerful, versatile tool that programmers anywhere would do well to learn.
I really, really, really hope a lot of these things are implemented as compiler- or runtime-level features. I understand the purity aspect of implementing features as templates, but it just bloats my code and slows my compile times. A lot of the compile time for my apps is spent regenerating the same template crap over and over, then waiting on the linker to weed out what's duplicated. It takes forever.
C++ is to C as Lung Cancer is to Lung
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
This sig does not contain any SCO code.
We will see the usual litany of C++ hating here in this thread. The hating will be generally based around misconceptions or problems that are 5 years old.
So to get them out of the way:
If you're leaking memory or spending time managing memory in C++, then you're using C++ wrong. Get a book written in the last 5 years.
If you're worried about compiler compatibility (with the exception of export which isn't much use anyway), get a compiler written in the last 5 years.
If you think that C does some subset of your task better, then write it in the common subset of C and C++ and quit whining. Or, write it in C and link it against your C++ code and quit whining.
If you think that templates simply provide code bloat, then get a compiler newer than 5 years old.
If you think C++ is slower than C, then get a good optimizing compiler (you know one written in the last 5 years) and do a benchmark. You will generally find that templates make C++ faster.
If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).
Sure there are valid complaints about C++, but the majority of them I hear on slashdot are complete bull. The majority of the remaining complaints will be fixed by C++0x.
One remaining problem is the lack of a vast array of standard, business oriented libraries. I don't write business oriented code, and I find the C++ STL one of the best libraries out there since it provides really good support for writing efficient algorithms.
Another problem is the difficulty in parsing C++. Sadly that's never going away.
But if you're going to complain about C++ compared to recent languages here, make sure that you're talking about recent C++ too, and try to make sure the complaints are accurate.
SJW n. One who posts facts.
Fixed that for you. Maybe it's how you program?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You do know that you don't have to screw around with any of that in a managed language, right? "Very easily make the different processor needs compatible" my ass--Java/C# do it on their own.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
C++ is an extremely powerful programming language and that is why I use it every day. But it has one major problem: It is too complicated. As long as you do programming full time you are OK but if too much of your time is spent on the application side of things you quickly get in trouble. This is what people like BS don't seem to get - not everyone can spend 100% of their time studying the language.
No, the "premature optimization" thing applies to all areas. Especially areas where it's never fast enough.
Why? It's simple: resource management.
You have X amount of resources to put into your product. X is always finite. It's kind of tough to measure X, but you can think of it as lines of code, man-years, or even just dollars. The amount of resources you have varies a lot depending on your budget, how much time you have, and the quality of the programmers you have. But the important thing is that X is always limited.
Now you have two approaches:
Paradoxically, I hold that #2 will produce a faster program. This is because the X you spend on making the program faster in #2 will be more effective, because you've already laid the groundwork for it. It's always difficult and time consuming to optimize code that doesn't even run yet. It's much more efficient to optimize code that already works. So the result, even though you spend less X on speed, is a faster program.
Think of it as transporting a lot of material into the wilderness somewhere. If you first spend some of your resources on building a road, you'll get the job done for less time and money than if you just start hauling stuff into the woods immediately.
If you mod me Overrated, you are admitting that you have no penis.
The new "auto" declarations really fix one of the biggest gripes with C++. Everybody is dead tired of doing
std::map::iterator it = m.begin()
Now you can just do:
auto ip = m.begin()
It takes much of the pain away from static typing...
Save your wrists today - switch to Dvorak
1. Boost.
2. Nonsense. Boost has facilities for this ("any", iirc) and also for something called "sum" types which can achieve what you want in a better way ("variant", iirc).
3. shared_ptr, weak_ptr.
4. Yup. Going to be fixed by C++0x.
5. C++ can be written to be a lot more portable than your Ruby or Python.
6. A matter of taste.
HAND.
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
Citation needed. What is post-2000's C++? Please enlighten me. All of my professional C++ experience occurred between 1999 and 2006, conforming to the 1998 ISO/IEC spec sitting on my desk, with various modifications made for broken compilers (e.g., VC++6, the lack of support for the export keyword in any C++ compiler I've used, etc.). If there's a later "version" of C++ that is supported by gcc, I have not heard of it.
I did some C++ programming in high school and college, but didn't really dig in until 1999. From that point forward, I spent far too much time building tools---like the aforementioned refcounter, or utilities for atomic access to shared variables across threads---to make up for C++'s shortcomings. After some time, I realized that I was wasting my time and should switch to using a language that comes with these features built-in.
My advice to my junior colleagues is simple: use Python or Ruby (not so much Perl, because of its syntactic ugliness and hacked-up object and exception models) for the control flow, and interface to C when necessary, using open source, peer-reviewed C libraries with existing Python/Ruby interfaces wherever possible. You will not only develop code more quickly, and develop more reliable code with better failure modes; you will make debugging much easier for other engineers who will inevitably have to dig into your code later.
[ home ]
Read: http://www.amazon.co.uk/Modern-Design-Applied-Generic-Patterns/dp/0201704315
It's a good introduction to modern C++. While the book itself is not really helpful, it gives you a nice overview of "modern" development techniques.
Not to worry. As a result of the nuclear launches following the panic resulting from the 2038 Unix date rollover, the remaining cockroach hordes will not evolve sentience until at least 2105, thus avoiding the 2099 crisis completely. So it's all good.
I am not going to go read a book simply to settle an argument: you need to summarize here.
In particular, explain to me why his techniques are not generally applicable to other languages (or to Python or Ruby in particular) or why using those techniques or similar ones and interfacing to C when necessary actually provide a less efficient development environment.
I know C++ can be made "acceptable" as a high-level language through sufficient effort; I spent 7 years doing such a thing. I want to know why that's a better solution than using tools that are---out-of-the-box and without reference to a magic cookbook---ready to do the things that require months of development or dozens of third-party libraries to achieve in C++.
[ home ]
These are all very good points, particularly regarding RAII. I'm sure you know this already, but other languages such as Python provide deterministic resource management as well (in Python, it's the "with" statement). Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern.
> I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++.
Because C++ is not a pure language. It is a multi-paradigm language (imperative, OO and functional) with both a high and low-level language features and people seem to hate the aspect they which they don't prefer.
The close-to-the-metal types hate the high-level aspects and rather use C. Disregarding the fact, that changing the code from C to C++ is purely syntactical and runs without any detriment in performance. Exactly the prime idea behind C++.
The high-level people dislike C++ exactly for this approach. They don't like that the basics are so clearly visible, and are even the default. You have to hop through some loops, before you get to a higher abstraction layer. E.g. you have to use external libraries and/or special classes for memory management.
Personally, I like C++ for exactly that reason. I can start on a fairly abstract layer with pure virtual interfaces, smart pointer, signal slots and there is not a single (raw) pointer or a manual deallocation to see (or other manual resource deallocation).
Granted, it is more verbose than in a pure high level language, but that is what the machine has to do.
And if there is a performance bottleneck, I can seamless go down in the abstraction level from simple inline functions, over imperative functions with pointer arithmetic, down to inline assembler and can even guarantee a certain timing, if necessary.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
There are vanishingly few programmer geeks left on slashdot. Most of the "programmers" here, these days, are folks who've written a few scripts or set up a movable type install.
There are a few real programmers left here, but they're lost in the noise. You know, the roaring noise made by the python and ruby folks.
This post brought to you by a C++ programmer who happens to love Python and Ruby ( and javascript! it's an amazing language ), but uses the different languages where appropriate.
lorem ipsum, dolor sit amet
Yes, this sounds logical. C++ has only recently become interesting. C++0x back in, say, 1999, would have totally killed off Java.
This sig does not contain any SCO code.
I used to think like that, but then all the things you talk about are just syntactic sugar. There is nothing you can do with proper generic that you can't do in Java or C#. Yes, C++ is way more expressive than almost any other language, but that is also its peril.
And when was the last time you used meta programming to solve a concrete problem that could not be elegantly solved otherwise.
Most people learn how to calculate a factorial using meta programming techniques and stop right there. It's more of a curiosity than useful practical technique.
As the island of our knowledge grows, so does the shore of our ignorance.
To summarize it, C++ now moves toward design which allows to catch more and more errors during compilation. But at the same time C++ provides tools which allow to write generic code.
C++ was once thought to be a language that was powerful enough that it could be used to express most features that other languages had. With things like operator overloading, multiple inheritance, and templates, you could pretty much make a class behave however you want. But years later, we have seen that C++ failed at that mission. There are simple and common OO constructs that C++ is unable to represent. Rather than focusing on improving the template functionality, I want the OO syntax fixed.
Let me cite some examples:
1) It is impossible to make a string class that behaves "normally"
Plenty of people have tried. QT, Boost, STL, Gnome, WxWidgets, all have their own string classes. Years ago, when VB developers touted how easy it was to use strings compared to C++, I told them it was merely because nobody had made a good string class. After 10 years of trying to write one, and using dozens of other ones people created, I realized that C++ is simply too weak and too loosely typed to do this.
Suppose I make a string class, kinda like the STL string:
string foo;
1) foo = "whatever";
2) foo = foo + "bar";
3) foo = 7;
4) foo = foo + 7;
5) foo += 7;
Take a look at these. The first one is no problem. That can call an assignment operator to copy the char * contents to the string. The second one can also be done with a + operator. The third one can also be done via assignment. But what if you forget that? Well, the compiler will see that as foo = foo(7) which will call the constructor that allocates 7 characters, and then assign that. So instead of the string "7" you get a blank string. The next example is a problem too. If the string class can be converted to a const char *, as is common, then does this mean to use the + operator on string and an integer? Or did it mean to convert foo to a const char *, then move 7 characters ahead, then assign it? That can result in a crash. This is because pointer arithmetic is intrinsic in C++, but it is inherently type unsafe.
Then how about a function that returns a string? A simple case in most languages, but in C++ it results in redundant copies across the stack. So people revert to funny things like auto_ptr and other wrappers, or complex mechanisms for doing shallow copies to prevent that. Other languages just avoid the problem entirely by not allocating things on the callee's stack. It's just an intrinsic problem in the old everything-goes-on-the-stack-by-default mentality of C++. It just doesn't always work.
Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++ // C#
class Foo
{
private int _x;
public int x
{
get { return _x; }
set { _x = value; }
}
}
So in the above class, I want to access _x via a property get/set. C# has a built-in construct for this. In C#, I could do:
MyFoo.x = 7;
MyFoo.x++;
MyFoo.x = MyFoo.x + 3;
MyFoo.x/= 7;
etc. The compiler knows how to get/set x, and it can even be inlined! This allows me to do things like log when x changes, or see what accesses the variable. Now, let's try that in C++.
class Foo
{
private:
int _x;
public: // Get X // Set X // Another way to get/set X
int x();
void x(int);
int &x2();
};
MyFoo.x(); // Gets x, no problem // Weird syntax, but that is fine // Does not modify the value of x, hmmm... //
MyFoo.x(7);
MyFoo.x()++;
MyFoo.x2()++;// Modifies x, but only lets you track the get, not the set.
MyFoo.x()/=7;// Same exact issue
MyFoo.x(MyFoo.x()/7);
Please elaborate; I'd like to hate C++ more effectively.
I do not understand why the post is modded "funny". Indeed, very fast SIMD libraries are coded in assembly. I think even 'liboil' has some parts coded in assembly
> I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python.
Well, Python is a different game than Java or C#, which both have a much better JIT-compiler.
I mainly program in C++ (real-time data processing), but I feel hard-pressed to believe, that Java has to be severely slower than C++ in numeric computations. The Java implementations of FFT and LinPack suggest, that comparable performance should be possible. The SciMark 2.0 should also be more up to par, when you replace the synchronized Random in the benchmark with a Java implemented Mersenne Twister.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
I also have an extensive experience with C++, and I tend to agree with a lot of the criticism that it gets.
But the problem is that no alternative exists for the type of problems where C++ is used extensively. I guess the most important area is games.
The world really NEEDS a language (the last low-level language) with the low-level performance of C++/C and with a full, modern library, and modern language features (threading, modern module system (not based on #includes and a crude preprocessor...), optional strong typing system a la Ada with optional runtime-checking etc etc etc.
Basically, a really nice, compiled, well-performing, modern low-level language could easily exist. But it doesn't. So we'll have to settle for C++ until someone makes something better.
They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way),
I work a lot with C++/Qt, but it's damn near that I want to say I program in Qt instead of C++. What's the problem with that? Well, I'm essentially lost if I have to work on a STL/WinAPI/MFC/wxWorks/boost/whatever project. Not in that I don't grok C++ which I do, but that I don't know any of the objects or functions or whatnot being in use. I do realize that there are differences between the libraries but certain basic functions should just be common, there's no reason why you'd need more than one string class. Sun got behind Java, Microsoft got behind C#, nobody got behind C++ and the result is that even the most basic of appliications can source-wise look completely different using different toolkits. It means that apart from equal syntax (and which kind of braces is the least of my problems moving to another language) there's barely something like "C++" - it's a loose family of code which happens to be compatible.
Live today, because you never know what tomorrow brings
The C syntax is horrendous, the conversion rules chaotic
Bjarne Stroustrup, creator of C++, is saying that C has a horrendous syntax and chaotic conversion rules...
Hahahahahahahahaha.
"Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern."
Really?
What about:
COBOL
FORTRAN
VB
Prolog
Lisp
ML
In fact any non-OO languages , given that RAII is an OO concept.
Kay can say anything he likes, but he did not invent the first OO language - it was Simula 67, also a statically typed language, and OOP in C++ has very visible roots in Simula (dot-notation to access members, "virtual" and "protected" originate there, for example; but in general, the very concepts of classes with methods and fields, combined interface/implementation class inheritance, object instances, special syntax for message receiver in a method call, object identity, object references and null, upcasting and downcasting, explicit polymorphism via virtual declarations and overrides, controlled encapsulation by means of visibility levels, etc).