Slashdot Mirror
The Future of C++ As Seen By Its Creator
holden writes "In a rare public talk, C++ creator Dr. Bjarne Stroustrup discusses his ideal in programming languages, as well how he sees the next version (and beyond) of C++ developing. He explains the general selection criteria used for adding new features, some of the legacy of C++, and many other interesting topics. Especially interesting is during the Q&A he explains his views of the embrace and extend mentality some implementations, such as VC++, have taken."
Please use the torrents, and keep those torrent up and running after you're done d/l'ing.
o rrent Ogg/Theora (Recommended)o rrent XviDo rrent MP4o rrent MPEG
http://csclub.uwaterloo.ca/files/stroustrup.ogg.t
http://csclub.uwaterloo.ca/files/stroustrup.avi.t
http://csclub.uwaterloo.ca/files/stroustrup.mp4.t
http://csclub.uwaterloo.ca/files/stroustrup.mpg.t
AC to prevent karma whoring.
C++ has adopted Boost's function class in the TR1 library - you will be able to use std::function, etc. No more member function pointers if you don't want them.
Not that job listings are a particularly good indicator of anything, but from Monster:
The C++ ones include plenty of new systems.
"The Milliard Gargantubrain? A mere abacus - mention it not."
C99 is driven by customer demand. And I don't mean as in a bunch of geeks saying 'implement ALL of C99 now!' but as in they work with their enterprise customers to prioritize features.
TR1 WILL be supported as soon as C++0x is finalized. Not sooner. If they would implement is now, it would likely change as soon as the new standard is ratified. Of course, even if they would implement now, you would criticise them as soon as the standard is ratified because ZOMG! Microsoft's TR1 is proprietary and out of date! LOLOLOLROFLMAO!
I suspect they will simply license TR1 from dinkumware which is feature complete with the current state of TR1.
Intellisense is a dog. People are working on it, and a lot of redesign is going on. Not just for intellisense, but for the whole compiler architecture to make it more scalable and plufable.
And I don't know where you are getting your info from, but asm is perfectly supported in 64 bit. Just inline assembly isn't because for 64 bit code this would make it non-portable between different 64 bit architectures.
You can still add asm files to your VC++ project and compile them.
And you can say yuck to MFC and I would agree. But a very large number of enterprise businesses still builds massive VC++ applications that use it extensively. maintaining and improving it makes lots of business sense.
And finally, C++ is not meant to be as RAD as C# and VB because that would require a lot of manpower which cannot be justified. VC++ is targeted for interoperability, performance and control over the program execution. Not for whipping up a data driven LINQ doc. People who want to use LINQ would simply build a C# project for data interaction and add it to their mixed mode C++ project.
C++ is far too complex yes. But there is nothing that can really replace it. A language which supports functional, generic, procedural, object-oriented programming, with static typing, metaprogramming, and heavily geared towards native building? I mean, do you know a language which can resolve iterators to simple pointer arithmetic when compiling? Of course there are far better languages feature-wise, but they all demand some performance penalties. This may or may not be relevant. For example, for video codecs its relevant, as it is for most other realtime stuff (try capturing with Java and its GC for instance).
So, C++ fills a niche. D *may* be a replacement, but I am skeptical. I don't know Eiffel well enough though, this may be a good candidate.
And lets not forget that C++ toolchains are among the most optimized and tested ones. For example, Lisp could be able to reach C++ performance, but doesnt simply because the Lisp toolchains arent as optimized. A simplified example: sometimes SBCL does register->memory->operation->register calls, where g++ optimizes to register->operation. And, the amount of C++ code in existence is staggering.
This sig does not contain any SCO code.
This discussion came up again with Visual Studio 2008 "Orcas" and plans seemingly a bit lacking once again for an improved C++ feature set and general love for IntelliSense, etc.
s tID=970938&SiteID=1
Microsoft had the following to say:
http://forums.microsoft.com/MSDN/ShowPost.aspx?Po
See bdunlap's response.
Beware: In C++, your friends can see your privates!
It's clear that Microsoft is not interested in the future of C++.
.NET. Why would they still be interested in something that could be used to migrate away from Windows?
They more or less own the market for C# and IDEs for
BTW, it's really hard to migrate a Windows C++ program away from Windows. A Windows C++ program may be legal C++, but is something horridly deformed and barely recognizable.
http://www.dieblinkenlights.com
Dr. Stroustrup made a great contribution by designing the C++ language. However, in recent years it seems to me that he has been taking a leisurely approach to making improvements.
... Hans-J. Boehm's site". It seems to me that there
are too many areas in which the C++ answer is "You can just go there", rather
than "This is the standard, certified method."
Stroustrup is, unlike most programmers, an excellent writer. His FAQ is an example. Quote: "What's a good certification for C++ programmers? To the best of my knowledge, there isn't a good certification program for C++ programmers. That's a pity. A good certification program would be most useful. However, C++ lacks the central organization that would produce a solid certification program, and a certification program without authority or that focused on syntax would be worse than useless."
I'm certainly not an expert in this subject. However, I get the same impression from the words "C++ lacks the central organization" in that paragraph that I get from his other recent work. Something like, "What, me be a leader?"
Note that Java and C#, which are sometimes seen as replacements for C++, are proprietary languages from companies that are routinely mismanaged. If you use those languages, you partner with those companies, and it is possible that you too will suffer from their mismanagement. For that reason, there is a big need for strong leadership in maintaining a language unencumbered by issues of proprietary behavior.
Concerning Java, Dr. Stroustrup says "Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation."
Concerning C#, he says, "It will take a lot to persuade me that the world needs yet another proprietary language (YAPL). It will be especially hard to persuade me that it needs a language that is closely integrated with a specific proprietary operating system."
Again, I'm not an expert in this area, but it seems to me that Dr. Stroustrup tends to define his leadership narrowly and concern himself with programming constructs rather than larger issues such as extension, standardization, and certification of libraries, for example. About C++ garbage collection he says, partly: "See
It's amazing to me, but true leaders are very rare. After all these years, we still depend on Dr. Stroustrup, even though he has been less than a complete leader in the more social aspects of developing the C++ language, in my opinion.
You know you have a sucky language when your important function is called CMPXCHG16B (not to be mistaken with that other little SOB, the good ole CMPCHXG16B)
10 ?"Hello World" life was simple then
Let's not forget that you can actually overload the "new" and "delete" operators and drop in your own memory allocator if you wish...
How do you figure that? I work in low-level code, where performance really matters, and I still can't remember the last time I used pointer arithmetic. Sure, I use array indexing all the time, but the fact that this is semantically equivalent to pointer arithmetic in C++ is coincidental. As long as a language supports arrays (as in contiguous memory that supports fast random access — contrast with linked lists) and indirection (call it a pointer, a reference, a link, whatever you like — something you can build graph-like data structures with) then I don't see any need for pointer arithmetic at all.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This thing's been forwarded around the net without the original author attached. However, I think I tracked it down to cddukes@unity.ncsu.edu... Any readers correct me if I'm wrong.
8 of 13 people found this answer helpful. Did you?
This is why I hate to work in C++:
1) Syntactic ambiguity: you can't tell from a glance whether your function call is sending a copy of an object or a reference to an object. A fault with C also, but this should've been fixed
2) Templates: buggy and inefficient. I would've preferred STL to work on a generic object class.
3) RTTI: Still not sure what this is getting you in C++. Dynamic casts? Unfortunately you have to choose to enable or disable it per-file, whereas having a base object class would let you do it per-object.
4) Operator Overloading: another case of ambiguity. You'll never be quite sure what your code is doing.
5) Lack of Garbage Collection: I would've at least liked a reference counting pointer without having to download BOOST.
6) Non-standard ABI: C object files are reusable across multiple compilers, since their format is standardized. In C++ it's not. Everything must be compiled in the same version of the same compiler.
That's just what I came up with on my own. I'm sure other people have more problems.
http://mw1.merriam-webster.com/dictionary/restful
s
1 : marked by, affording, or suggesting rest and repose
2 : being at rest : quiet
http://mw1.merriam-webster.com/dictionary/restles
1: lacking or denying rest : uneasy
2: continuously moving : unquiet
3: characterized by or manifesting unrest especially of mind ; also : changeful, discontented
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
That entirely depends on how you use templates. A single instantiation of a template will likely be smaller than the equivalent generic code, especially in a complex class where you only have to instantiate the members you use. However, if you allow the same code to be instantiated several times, it will quickly blow up your executable size. Any way you avoid this, you quickly lose the benefit of templates (i.e., you make the generic version and lose compile time type-checking). Have you seen the size of executables that heavily use STL? They can be huge.
Since most C programs are valid C++ programs, and will compile to a comparable size, almost nothing. However, as soon as you actually *use* non-trivial C++ features, such as the standard library, you are lost on small platforms. Any programming language you can't like with the most basic element of the languages standard library without taking up 90% of your target RAM is... useless (for that target).
As a die hard Eclipse fan I have to violently agree with you. Eclipse is brilliant at Java development and gives poor little netbeans more than a run for its money in every respect except for the integrated profiler. But the Eclipse CDT is horrifically lame. I tried it. It had a bunch of things Eclipse-like that I enjoyed, but it was just so slow and unpolished that it didn't have the extra mile that we all associate with the Eclipse Quality.
Bravo to you for recognizing crap in a otherwise golden framework. Many others wouldn't have your vision to recognize the garbage in the goldmine.
Consider yourself spoken to.
I think you may be confusing me with either a Java evangelist or a C++ basher. I am neither, but I will go through the various points you raised one by one to clarify what I meant.
"Primitive, error-prone control flow constructs"? Such as?
Well, in terms of loops, things like foreach (a real one, not an awkward function template that doesn't work with built-in arrays) and labelled break/continue are no-brainers in any modern procedural language. However, in that area I was really thinking of more powerful things like pattern matching and guards on functions as specific features. Of course, given sufficiently powerful handling of functions or macros, you can effectively define your own control flow constructs, so if you want a forever loop or a generator, you just write it.
Then there are the OO-related issues, based around polymorphism, virtual function dispatch, and dealing with class and member function templates. Look at the elegant simplicity of Smalltalk or the flexibility of Eiffel and then tell me with a straight face that C++'s manual approach to dealing with inheritance and virtual functions is really the best way we could do things. Hint 1: Function overloading vs. function overriding vs. function hiding and their behaviour with virtual function dispatch are crazy. Hint 2: Template resolution takes many pages to describe in the C++ standard. Hint 3: Virtual destructors, 'nuff said.
And this is without getting into dealing with concurrency in any way, never mind with higher-level tools than primitive threads and locks. Take a look at Erlang's message passing approach or recent developments in transactional memory in everything from Haskell to .Net-based languages if you want to see how weak the "standard" threads and locks model really is.
As for functions not being "first-order entities," that's a consequence of C++ being a statically-typed language that puts performance first
Tell that to OCaml, which manages to combine a powerful type system and high-performance imperative features with a functional programming framework quite effectively. As I noted in my previous post, most projects written using C++ today don't need the fast but unsafe and inexpressive approach. Even those that do don't need it most of the time, which is why hybrid approaches like the one OCaml takes have such potential.
Not to mention that you have things like functors that can turn functions into real objects with only a class wrapper as code overhead.
Sorry, but even with the nice tricks in Boost, C++'s support for functional programming is at best mediocre compared to what is common in many other languages today, and I don't just mean the mainly academic ones. Being able to overload operator() and play with templates a bit does not change this, it just makes it slightly less limiting.
"No syntactic support for common data structures"? I'm not even sure what you're talking about here. What kind of syntactic support do you think C++ lacks?
Well, try initialising a std::vector with some literal data and see how far you get. This one is so annoying they're actually planning to add a hack to compensate in the next version of the C++ standard.
But the operator overloading you mentioned, while welcome (Java got this one wrong and just hasn't realised yet), is still quite limited. Want to define a multi-dimensional indexing operator? Better go learn about proxy classes, and template metaprogramming if you don't want to take a significant performance hit while you're doing it. And that's only if your data structure happens to be similar to the array-based built-in stuff. Simple but effective things like the head::tail list notation common in functional languages and amenable to recursive processing through pattern matching are difficult or impossible in C++, even if you create your own classes and overload operators in a re
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.