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."
"control of alignment"
I'd like chaotic good please
Knowledge is power. Knowledge shared is power lost.
Yes.
I'm a big tall mofo.
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.
No, not really.
In fact C++ is barely managing to hold its own any more against C# and Java.
It's not that C++ isn't good, its just that its harder to do things in it then it is to do those same things in either C# or Java. Harder to do means more expensive, and businesses all over are having to tighten their purse strings.
I keep finding that for fast number crunching apps, C beats C++, and for less intensive work its usually easier to use Java or C#, or indeed python, then it is to use C++.
Also, its certainly true to say that in the UK C++ is not anywhere near as useful in terms of getting yourself a job as it used to be.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
Objective-C is essentially unrelated to C++ in every way. C++0x does not change this fact at all. Comparing the two makes just slightly more sense than comparing C++ and Prolog.
If you mod me Overrated, you are admitting that you have no penis.
...or, as a former manager explained it, "When C++ is your hammer, everything looks like a thumb."
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.
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}
Because performance is important to some people.
...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.
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.
...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.
C++ is to C as Lung Cancer is to Lung
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.
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.
If it was as good as it stands, then newer languages such as C# wouldn't take off.
Don't get me wrong, I love C++ and it's my primary programming language, but to say it's perfect as it is, is just silly.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
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
No it's not. The standard does not define concurrency issues. Not how to spawn threads and create mutexes, but lower-level issues, like coherency. This is sorely needed for truly portable code. Rvalue references will help a lot with the creation of temporaries that are just copied and destroyed. You see this now in all the specializations in the libraries for the swap function. With rvalue references, you can write a single template that will be optimal for all types. Currently template error messages are a mess. several lines of unreadable garbage because your type doesn't supply a member or operator that the template needs. Concepts will lead to concise, easy to understand error messages. typedecl and the new use for the auto keyword will reduce verbosity, and stop the nightmare that is figuring out the type of a complex template (i.e., when using Spirit, et. al.). Lambdas and closures will simplify using the STL algorithms without having to create a lot of functors. REH
Anonymous Cowards suck.
Counter-counterpoints:
d = {"name":"Bob", "age":42}
print "Name is %s and age is %d" % (d["name"], d["age"])
Keep in mind that this is a complete python program, no further code is required.
If you mod me Overrated, you are admitting that you have no penis.
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 ]
> 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"
Boost has in many eyes really transcended from "just an external library" to an integral part of the C++ platform. It compiles on every major platform, and it is open source.
Boost is moving C++ forward at a rate 10x that of the standards committee. I am not sure why you felt integrating it with your project was difficult- it is header only for the most part and does not require you to use any specific pieces. Shared_ptr's, which are the most useful library of all, do tend to be viral in the sense that you have to use them everywhere, but this is a GOOD thing.
If you are doing C++ without Boost these days, you are really missing the boat.
Generally speaking, I agree with your post. However...
That's a really, really awful way to think about C.
C has a completely different set of best practices and design principals; anyone who puts "C/C++" on a resume I'm reviewing loses points as opposed to listing them separately.
Oh please. Pascal does everything C++ can now.
First off, if you have a problem with using external libraries, then you just won't get anywhere with a C/C++. They are VERY general purpose, and intentionally so, and the whole idea is that implementation specific things are supposed to be provided in libraries, rather than the core language. That said:
1. Boost is actually very easy to integrate for most of its features. A few (small handful) of its components require compilation, but the vast majority of them are template-based and header only. Meaning just include a header file and there you go, you're using boost. No extra compilation/installation required.
2. This kind of thing is GREAT for doing small scripts, but HORRIBLE for doing large complex applications where type safety can be VERY important for avoiding bugs. If all you ever do are small, quick, limited scripts, then you're absolutely right that you should avoid C++, that's certainly not what it was meant for, and not so much the domain of a strongly typed language. For things like the software that runs large financial institutions and whatnot, there's a reason code like that should be avoided at all costs.
3. I have trouble imagining a situation where a real garbage collector would ever be superior to an RAII model with shared smart pointers for stuff allocated on the heap, outside of plugging up a leaking legacy app. Maybe for very simple programs, but once you get non-trivial destructors (for example, with objects that lock system resources), then you start having to do manual memory management in your GC environment anyway, and end up with a horribly ugly conglomeration of "mixed metaphors" as it were. Smart pointers really give you the best of both worlds: deterministic destruction, without having to worry about manually releasing anything. It's just a matter of getting used to declaring a smart pointer wherever you would have a "type *name" instead. So yes, I'd argue they ARE a substitute for garbage collection in almost any situation.
4. Sorry to be blunt, but you should probably RTFA on this one. The problem is solved through "concepts," which is the part of the new specification which deals with this specifically. It's essentially a C++ implementation of the "design by contract" metaphor.
5. In this case "can be" equates to "do whatever you like and it'll be portable on all major general purpose computers, and who uses Ruby or Python on embedded platforms anyway?" If you are able to compile with GCC, which is the case for pretty much every computer/OS combination in existence, then you can count on it being pretty damn portable. If you are programming for something like an ATM or a set-top box, then you probably aren't going to be using a high level scripting language anyway.
6. Yeah, it can get ugly. Thankfully this will be largely fixed with the "auto" keyword in C++0x.
It is the discussion. Judging c++ with boost excluded is like judging perl with CPAN excluded. Who cares whether it's "part of the language" or not? Everyone who uses the language seriously uses them, and they're critical to understanding how the language is used effectively.
You surely are a careless coder, then. C/C++'s memory/pointer-related problems are due to careless/clueless programmers, not due to the language itself. You clearly fail to understand the language, yet pretend to answer with authority. Do you use (or even know) the RAII idiom? that smart pointers have been there for years? Yes, I mean auto_ptr and shared_ptr. How about the Boost library (which is being included partly in C++0x). Garbage Collectors are non-deterministic by nature; Therefore, they are a real no-no for real projects (think real-time systems or massive number crunching, where memory pools are common).
If you make language even an idiot can use, idiots will be using it. Like with VB.
Extreme Programming - Redundant Array of Inexpensive Developers
It doesn't solve anything that *couldn't* be solved before, but that's not the point, as anything can be solved given enough time and effort.
But out of the box, without even any compilation needed(!) you can get smart pointer implementations, timers, asynchronous I/O, a multithreading toolbox, conversion libraries, containers, memory pools, and tons more (some would say so much more that its bloated) with the added peace of mind knowing that tons of people out there are using them as well and they are thoroughly debugged. Its worth it for the shared_ptr's alone- those alone dramatically reduce the biggest source of C++ bugs.
In my previous company, I worked on a system that was about 10 years old- started before the STL came into existence, and long before it was well supported by compilers, and thus the team had spent a lot of time building STL-like functionality with dynamic strings, iterator like functionality, vector/list work-alikes, etc. This meant that now once the STL came around, a programmer familiar with "standard" C++ had to learn how to re-do mundane things like string and container manipulation. Similarly, that team had created smart pointer implementations, logger classes, multithreaded and socket libraries, etc. Boost not only provides all of this functionality, but you get it working right out of the box, and since Boost is well known, you don't have to wait for a programmer to get up to speed for a month or two while he becomes familiar with your code.
There are some more exotic features that you don't have to use, but I recently used multi_index to implement what is more or less an in-memory database cache in about 100 lines of code. This replaced a lot of code that read records and then threw them into hash maps or vectors using the OrderId as a key, then the CustomerId as a key, etc... so we had fast lookups to our most commonly used objects.
What are its advantages over ACE? ACE is a great networking and concurrency library, which not all applications necessarily need, and ACE's strong point is multi-platform networking and concurrency, which while I wouldn't call a small niche anymore, can't be used across all applications. At least some of Boost's libraries, most notably shared_ptr, can be used in any C++ program. In fact, until Boost::asio was released relatively recently, I would say ACE and Boost were entirely complementary. Also, boost is more or less a testing ground for the C++ standards committee, so it is more or less "blessed" and can be seen as a Beta for future versions of the standard.