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)."
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
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.
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.
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 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.
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.
You actually don't build a house out of 2x4s anymore. It's a lot more of 2x6s for exterior walls and 2x8-2x10+12s for beams and the like. 2x4's are merely for interior walls, at least according to most building codes.
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.
Now you're just being unfair.
1. I found it pretty easy. Most Boost libraries are header-only so you only need to put the relevant header files in your project, adjust your header search path, and you're done.
2. Your example hasn't got much to do with C++, and everything to do with static vs dynamic typed languages. The C++ version will be about the same size as the Java and C# versions.
3. Uhm sorry, "real garbage collector" and "Python"? You do know that Python uses reference counting, right? Just like shared_ptr and weak_ptr. shared_ptr is really nice; I've been using shared_ptr for a while now and most of the time I don't even have to think about memory management.
4. No comments.
5. This is the only point that I disagree with the parent. Python and Ruby tend to be more portable. I've seen my share of cross-platform C++ compilation errors, some which are easier to fix than others.
Still, if you're writing system software (e.g. a web server, daemon control software, filesystem indexer, etc) or large desktop software (Photoshop, Microsoft Word, KDE), then it would be madness to choose Ruby/Python over C++.
It doesn't have automatic memory management. By which I assume you mean garbage collection.
If you meant smart pointers and RAII, then I must inform you that C++ already had those, they just weren't standardised (i.e. you had to use boost or roll your own).
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.
Not sure how long ago I first heard that, and it's still as true today as it was back in '95. I think I first heard it from Greg Anderson, of Anderson Financial Systems (one of the old-time NeXT development shops.)
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
The success of C has been largely due to the fact that it makes one basic assumption that no other language aside from Assembler ever made: The programmer is always right. Modern C++ is getting further and further from its origins as an alternative precompiler to C. Valid C code is no longer valid C++ code as it once was. I think most C programmers would welcome a few additions to or improvements on the language such as objects and additional memory allocators, but once you start telling a C programmer "No, you can't pass that value in there" or placing restrictions on the programmer you wind up limiting their freedom to code effectively and you get away from the purpose of a compiler, which is to make programming easier. Yes, strongly-typed languages prevent mistakes from getting into the code, but the purpose of a compiler is not to prevent mistakes: that's the programmer's responsibility. I've stopped coding in C++: I'm going back to C. Of course, Objective C is looking more and more appealing, since it's been a part of gcc for a few years...
Any modern project in C++ that does not involve embedded hardware should be using Boost, period. C++ without Boost is like a marathon without legs. Incorporating it is a piece of cake, and it adds so much functionality that you'll wonder how you managed without it. On top of that, it's so widespread that support for it is quite common. It's even to the point that the new standard is actually stealing bits and pieces from it.
no, I think he meant a map where the value part can be any type, not just the one stated in the definition.
eg.
map.insert(1, "hello");
map.insert(2, 69);
map.insert(3, myobj);
etc. Boost::any is what he's after in that case so its a pretty moot point.
Easy:
The syntax is, I will grant you, somewhat on the verbose side, but it should illustrate the point, and the difference becomes less significant as the program scales.
(Yes, I know I'm using a different data structure. That's kind of the point: just because Python implements records as dictionaries doesn't mean that languages without heterogenous dictionaries can't do records.)
Your examples are complete bullshit. You CANNOT assign a character to a string, so your foo = 7 example is utter crap!!! You CAN do this: s(7, 'a') OR THIS: a.assign(7, 'a'). Your other examples just so your ignorance. You return a member by VALUE, and are shocked that the caller cannot modify your member? Is that really something you'd want or expect them to do? That is the whole point! It protected the innards of your objects. For the uneducated, it is called a class invariant.
Well, something in the range of 99% of the desktop applications available on Mac OS X are written in a duck-typed true OO language.
I hold that the main reason that C++ is used so much for large desktop applications on Other Platforms is inertia, pure and simple. Programmers hate change. I realize that this is a purely a statement of opinion and I have no way to back it up.
If you mod me Overrated, you are admitting that you have no penis.
I still haven't seen anything matching it for real time stuff. Not that I wouldn't mind, at all.
But writing I don't think I've seen OpenGL code in another language that wasn't incredibly slow. Maybe that's just momentum, but regardless, it's still the state of things.
Not to mention that C is not a subset of C++. The differences are minor and mostly subtle but they are there and they matter. For example, this trivial bit of very typical C code will not compile in a conforming C++ compiler:
char *x = malloc(10);
I'd suggest asking your "C/C++" interviewees to produce some code that's legal C but not legal C++. It will at the very least be amusing to watch them squirm.
If you mod me Overrated, you are admitting that you have no penis.
It's the difference between being able to type "import", and having to search, download, compile, and pray. As for few modules being part of the language, every example I listed is built in to Python.
If you mod me Overrated, you are admitting that you have no penis.
Yes, if C++ included the same libraries that Python does, this objection would go away. (Why wouldn't it?) The other objections would remain.
And no, GC does stop you from having to think about memory management. So-called "soft leaks" aren't a memory management problem, they're just a regular old code bug. GC doesn't save you from all bugs, or even from a particularly large number of them. It mainly just saves you from programming overhead.
GC also doesn't save you from having to manage external resources as that SafeHandle class does.
RAII is definitely not the design pattern I want. Believe me, I know what RAII is, and I know what I want, and the two do not intersect in any way.
I know it's hard to believe, but there are people out there who legitimately do not like C++. Not because we're stupid, or clueless, or because we've been misled, but simply because we have different constraints on our programming or even just different opinions.
If you mod me Overrated, you are admitting that you have no penis.
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.
Implicit conversion to const char* is not in the standard string. Neither is a constructor which allows string(n). Your string examples could be supported by a string class, but they would reduce safety by allowing accidental addition to integers. The preferred way is to use a stringstream to convert any object T to a string using its operator . C++0x will address the copying issue via the move constructor, giving user code the benefits without any changes since it mainly concerns library implementors. Really, your post comes off as an ill-informed swipe at C++. For example, "I could go on with other examples of things that the super-powerful C++ can't do". Why the petty attitude?
The problem isn't that it can't be done. If you really knew C++ as well as you claim, you'd realize that it's pretty easy (bordering in trivial) to write a string class that does precisely what you ask. The reason most don't work that way is because after people try it, they find that it's not what they really want -- in particular, allowing assignment of an int (to use your example) to a string tends to cause problems. If you're writing a 10-line throwaway script, allowing assignment of an int to a string probably won't cause a problem, but for big, industrial-strength projects it's a whole different story.
It's odd that you blame this on "loosely typed" -- loose typing is exactly what allows this to work, and C++ prevents it by having stronger typing than the languages to which you're apparently accustomed.
Properties, at least as supported by these languages are simply a lousy idea. Supporting or using them is an equally bad idea.
A property is only "useful" when you've really used the wrong type. IOW, you have (for example) an int (by whatever name that language happens to use) private to your class, but you really want that int to be restricted to a specific range, or log every time it's read/written.
In other words, what you want is something that works like an int in some ways, but not others. C++ already provides a way to define such a type directly though (and so should any other OO language) -- that's what classes are for. When, for example, you want an int that's restricted to a specific range, you write a class (or template) for that purpose -- and it supports assignment to and from ints by overloading operator int and operator= respectively. Of course, these can also be inlined, just like any other function in C++.
C++ does have shortcomings -- but your understanding of it appears to be sufficiently limited that you don't know them yet.
The universe is a figment of its own imagination.
No, auto_ptr is bad because of move semantics, not because of lack of rvalues.
RValues are bad because they will encourage people to write move constructors, thus making it difficult to tell who owns the data.
My point about swap is that rvalues are not required for it.
Regarding the templates, 99% of the time the problem is at the point of instantiation, not inside the template. The priority should have been the point of instantiation: the first line should show the point of instantiation, and the last line the actual template.
GC will never come in C++, let's not fool ourselves.