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)."
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
Well, here's what I personally dislike about C++. You don't have to agree with them, but this is how I feel and I think it's how many other people do as well. Certainly when talking to people who prefer other languages over C++, they have expressed similar sentiments.
The really big issues for me are the flexibility and the lack of libraries. The rest is less important. But with C++ it's like building a house out of 2x4s that you're not allowed to cut to length, whereas with moer modern languages it's more like building a house out of prefabricated rooms, with a ready supply of 2x4s and tools to shape them as you need if the prefabbed rooms don't fit your needs.
Please note that this is just my opinion, and you asked for it. Feel free to disagree, but please don't flame.
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
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"
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.