The Future of C++ As Seen By Its Creator 424
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."
Re:C Plus Plus Bye Bye (Score:4, Interesting)
but, if we talk about managed languages, I'd go straight for Python or Common Lisp.
Re:Parent is trolling (Score:4, Interesting)
C++ was not meant to be RAD like C#, but VC++'s compiler and IDE are _far_ from perfect. There are still several annoying little issues you come across when you play with real C++. My point was that there is so much room for improvement in the C++ compiler but they have completely neglected it and the IDE to implement features for their proprietary languages. Which all in all, this being Microsoft, is not that surprising - but it is still a shame.
You got one thing right - I did mean inline assembly (sorry, typos happen). It would be just as non-portable as using seperate
Re:Next version? (Score:3, Interesting)
not bad... (Score:5, Interesting)
I haven't yet written (or debugged) any large programs in C++, so that could be why I'm still enthusastic. Perhaps after some time with the language I might see what everyone is so worked up about.
I'm reading through "Effective C++" by Scott Meyers, and although the language seems like it has its warts and complexity, it also offers a great deal of power and is a hell of a lot more fun to program in than C because you get the abstraction support of objects, namespaces etc. Streams - awsome. Shared (reference counting) pointers - awsome. Less need for the preprocessor - awsome. And the standard library (plus Boost too) is so vast... containers, algorithms, it's all there.
Python is still my favourite general-purpose language, but if I need something compiled, then I don't see what is so bad about C++. Sure, Objective-C is a far better approach to the "lets-make-a-better-C" idea, but I'm not sure how to use it (and the standard library) outside of OSX or GNUStep.
Re:Just one thing (Score:2, Interesting)
The main benefit of C++ abstract classes is that you can have a single class inherit from multiple abstract classes without having to resort to something like Java's interfaces.
You think multiply inheriting from a bunch of C++ abstract classes is somehow worse than implementing multiple Java interfaces? Abstract classes are interfaces, and inheriting from an abstract class is identical to implementing an interface. All of the problems you hear about for the evils of multiple inheritance go away when you start talking about pure abstract classes. There's no worrying about "which parent class method will be active when they have identical signatures" since there aren no parent methods.
Watch the video (Score:3, Interesting)
Re:With all respect... (Score:3, Interesting)
With all the libraries and the plethora of features, it also has a large measure of Perl's problem: "Some designs that are not compact have enough internal redundancy of features that individual programmers end up carving out compact dialects sufficient for that 80% of common tasks by choosing a working subset of the language. Perl has this kind of pseudo-compactness, for example. Such designs have a built-in trap; when two programmers try to communicate about a project, they may find that differences in their working subsets are a significant barrier to understanding and modifying the code."
The summary, here [faqs.org]: "When all is said and done, however, C++'s most fundamental problem is that it is basically just another conventional language. It confines the memory-management problem better than it did before the invention of the Standard Template Library, and a lot better than C does, but the confinement is brittle; it breaks unless your code uses objects and only objects. For many types of application its OO features are not significant, and simply add complexity to C without yielding much advantage. Open-source C++ compilers are available; if C++ were unequivocally superior to C it would now dominate... Consider using C++ if an existing C++ toolkit or service library offers powerful leverage for your application, or if you're in one of the application areas mentioned above for which an OO language is known to be a large win."
Re:not bad... (Score:1, Interesting)
Re:Just one thing (Score:2, Interesting)
Does a compiler exist for ARM architectures?
And do you think moving over to Haskell would work for my
colleagues? Some of them do not have a formal education in
CS and PL and are not too eager to learn something new.
Size of iostream? (Score:3, Interesting)
After this we can get onto the main proceedings which might or might not return anything.
We move to the future by emitting a string of "Hello world" before returning zero.
This is the end of the discussion I hope it was informative.
Re:With all respect... (Score:2, Interesting)
Replacing C++? (Score:5, Interesting)
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?
The thing is, most development projects that use C++ today don't need all of that.
C++ is a fine, pragmatic tool, and I have great admiration for Stroustrup's ability to build such a useful thing. C++ is also a powerful systems programming tool.
But C++ is not a good language for most application development, which is what a great deal of code written in it really is. I think there are several separate but somewhat related reasons for this.
One is the safety argument. Most people simply don't need the flexibility/footshootability [delete as applicable] of C++. You need only look at the much-hyped field of garbage collection to see that (a) many professional developers find this one feature useful that they regard Java as superior to C++ for this reason alone, (b) many more professional developers have no clue about the overheads involved (which are almost zero for typical applications using modern approaches to GC implementation), and most importantly (c) a great many developers using languages without GC make mistakes that developers using languages with GC wouldn't. Similar arguments apply to other routine problems, such as pointers/NULL.
The second is the expressive power argument. Life is too short to be using programming languages with primitive, error-prone control flow constructs, functions that aren't first-order entities, no syntactic support for common data structures, crude macros, header files, etc.
Third we have the standard library argument. Yes, yes, you can get a C++ library for almost anything. That's not the point. The key word is "standard". Take a look at the huge practical success of Java and Perl, and tell me the vast Java standard library and CPAN have nothing to do with them. Sure, C++'s standard library is, technically, of a higher quality than most. But it still has stupid flaws (string support and IO streams are both fundamentally broken, for example). More seriously, it has stupid gaps. In the 21st century, it's hard to seriously advocate application development in a language with no standardised support for user interfaces, networking, concurrency, file systems, etc. No, I'm not going to spend days trying to find the right non-standard library for me. Non-standard libraries are for solving significant problems, where the difficulty and scope make it worth investing the time to find and hook in someone else's code. They're not for trivia that everyone uses all the time.
And finally, we have the tools argument. Working with header files sucks, and while just about everyone else is playing with their funky, auto-refactoring, navigation supporting editors, what do we have? VC++ (where refactoring still isn't available in native C++) and Eclipse (which is C++ forced into a Java-like IDE)?
The really scary thing is that reality bites now. It's not like I'm the first person to identify these practical flaws with using C++ for application development. It's not like other people haven't developed languages and tools with all these improvements already. And yet C++ continues to be one of the most important application programming languages today. Why?
Momentum. That's why. Building a new programming language with a syntax that doesn't look like C is asking for trouble; just look at the arguments Python sees over whitespace. (Curiously, I've never seen such complaints made about Haskell. Perhaps this shows a difference between the insight of your average professional programmer vs. your average language geek academic?) More to the point, trying to advocate a new programming language for industrial application development that isn't some form of block-structured, OO-based clone is asking for trouble.
I'm hopeful that over the next few years, as hardwar
Re:Parent is trolling (Score:3, Interesting)
gcc has a TR1 implementation and they have started implementing some of the c++0x features (that should be enabled explicitely on the command line)
In any case, VC++ majorly sucks. It's slow (and gets significantly slower at each new version), takes ages to do elementary things (I've seen it take 10 to 20 seconds to open a fucking text file - and a small one at that), has a sucky interface (as of vs2005, the project properties dialog was still not resizeable and full of small text fields meant to contain lots of data, like list of libraries. And don't even get me started on the project configurations dialog), don't really have any features not found anywhere else and they don't even work that well (how easily the code completion system fails). To do anything really useful like some automated refactoring operations, you have to install a third party tool (visual assist)
The project management, with its file/directory hierarchy which is not taken directly from the file system, is completely stupid and annoying (I worked at a MMORPG company on a solution containing dozens of project, and the hierarchy layout in visual studio and the file system were completely different, a fucking nightmare)
It also don't play well with version control tools, because it like to save the contents of the xml in project files in a different order each time, so even a trivial change will show lots of diffs in version control, making it impossible to figure out which compilation setting was changed frmo a version to another, for instance.
I don't know, I just can't find any redeeming feature in this IDE. As far as I'm concerned, when it comes to C++ it's a worthless piece of shit that is only used out of market inertia. It used to be alright, but the performance went down while the features stayed roughly the same except for those awesome 3d toolbars, so now it just doesn't seem to be worth its (rather high) price point compared to free alternatives like eclipse/cdt (or even kdevelop 3.4 if it was available for windows).
And don't come to me saying that a free version is available, its irrelevant to the professional world which have to pay for the dubious privilege of using this thing.
Re:C Plus Plus Bye Bye (Score:3, Interesting)
Sadly, I generate new Fortran code on a regular basis. I wish I was generating new C++
Re:C++ needed improvements several years ago. (Score:4, Interesting)
Re:not bad... (Score:2, Interesting)
Absolutely correct (Score:1, Interesting)
Delegates deal with 90% of all practical uses of closures, but I guess acknowledging that would be too much for some people's pride.
Re:Static iostream size? (Score:3, Interesting)
I have compiled C++ code down for a PIC microcontroller with 8 kB of RAM. The trick is to use only stuff from the C99 standard. Then you compile the code using VC++ on a Microsoft PC and do your unit testing. You can then rename all the CPP files to C files, and recompile under the PIC compiler and generate valid code.
In practice, the VC++ compiler is fairly non-standard, and the renaming of files business sucks. My solution was to move all the code into header files (.h), and then include the headers from stub .CPP and .C files.
The interesting thing was, the development time on the project where I did this was drastically reduced. A full fledged C++ compiler, like Microsoft C++, made program test much simpler. Development time was dramatically reduced because of a much simpler test cycle. This resulted in much more reliable code being given to the PIC, further simplifying the embedded development/test cycle. Debugging an embedded platform is much tougher than debugging on a PC, so any debugging that can be done on the PC is really big bonus.
Another interesting point is that for an embedded platform, particularly the really small chips, you may be better off turning off the entire C Run-Time Library. You aren't going to use any functions from it anyways. Calls like printf() and iostream make little sense on devices lacking basic terminal I/O commands.
Additionally, on devices without virtual memory, you want to avoid calls like new and malloc(). Make everything possible stack based, allocated only once at known program points, or allocated statically. Minimize the number of random allocations and deallocations. If you are trying to prove correctness for long uptimes, you need to prove that malloc() always succeeds. That is a very difficult thing to do given the potential complexities of external memory fragmentation and memory leaks. There is no Virtual Memory available to cover up inefficiencies in your code, in new, or in malloc(). Exceptions are also bad, because you have to prove that every single one of them is handled correctly and won't cause run-time issues. Besides, exceptions, new and malloc() are big sources of random uninitialized memory variables, and often result in slower code. All unexpected behavior on an embedded platform is bad.
On an embedded platform, for long up-times, you must also consider the possibility of hardware memory corruption. As such, statically allocated variables (non-indexed) are nice. You can read directly from a fixed memory location, and effectively verify allowed values. It is also desirable to keep the program simple and straightforward. This makes it easier to prove correctness and simplifies unit testing.
To any potential coders out there: this approach is completely non-standard, and I don't really recommend it unless you are working with embedded devices. My coding style on a PC platform differs significantly from my coding style on memory constricted embedded devices (like PICs). Also, on an embedded device, program length is usually small (for speed). As such, fast obtuse fragments of code are tolerable (if they are commented.) For a PC, programs are bigger, and obtuse code is not nice.
What follows C++ is probably (Score:4, Interesting)
As a C++ programmer, I can tell you that it is nearly impossible for C++ to make coding, compiling and debugging easier without redesigning the language.
Coding: Name one C++ editor or IDE that offers accurate code completion or code refactoring (compared to other languages.) I've tried Source Insight, SlickEdit 2007, Visual Studio 2005, Understand for C++, Vim, etc. and it is clear C++ is too complex compared to most other mainstream programming languages.
Compiling: Implementing a C++ compiler is far too difficult. And compiling takes too long even when you use C++ idioms like pimpl.
Debugging: Sure, boost.org's smartpointers and RAII are helpful but how many hours do C++ programmers spend tracking down bugs that would've taken minutes (if not seconds) to track down or avoid in other programming languages?
Why do I use C++? Because it is compiled, has numerous 3rd-party libraries, and is widely used. Like Windows XP, it might be a pain but it is so widely used that you'll have no problems finding employers that will pay you to use it.
Simply put, we deserve something better than C++ and it isn't going to be enough to enhance C++ because a full redesign is needed in order to address the issues noted above. We need and deserve a language that takes what we've learned from C++ and is designed from the ground up to address those issues.
So far, D programming language seems to offer the best hope, and some really talented C++ gurus like Walter Bright and Andrei Alexandrescu are involved.
Strostrup is now part of the problem. (Score:5, Interesting)
C++ has many problems. Some, like "an array is a pointer", it inherited from C. Some were mistakes in the original design that were later fixed, like unchecked downcasts, "this" as a pointer rather than a reference, and the lack of generics. And some are there because Strostrup is in denial about the problems, like the fact that the language gives no help with either thread or memory management.
Memory management remains the biggest problem. The fundamental problem is that C and C++ require the programmer to obsess on who owns what, while providing zero assistance in managing that information.There are ways out of this, involving syntax and compiler support for owning and non-owning pointers. But instead, attempts have been made to paper over the problem with templates. This never quite works, because for some things you still need a raw pointer, which breaks the abstraction. The history of auto_ptr (up to standard revision #4 now, I think) makes this clear.
Bolting on a garbage collector doesn't help much in a language with destructors; see the mess in Microsoft's "managed C++". If you're going to go with a garbage collected approach, it's better to go to a language designed for it, like Java.
Most of the standards effort is going into template features that few will use and fewer still will use well. Trying to use the template expansion engine as a general purpose macro system is a terrible idea for production code. But it has a big fan club on the standards committee. Worse, the C++ commitee does very little to improve language safety and reliability. Which is why we still have buffer overflows in C++ code, fifteen years in.
Incidentally, none of this has anything to do with C++ being compiled directly to machine code. There have been safer compilable languages usable for system-level programming. Modula 3 was probably as good as it got. But that language died when DEC went under. It's possible to hard-compile Java; there's a version of GCC for that, and it's getting some interest in the embedded community. The problem could be fixed. But it won't be, because the people responsible are in denial.
Re:The Future Is Already Here... (Score:1, Interesting)
Have a project that would actually get much benefit from lazy evaluation and static typing? Lisp does both just fine, use macros to define a DSL in about 20 minutes. I do it often enough to get static typing so the compiler** can optimize things better that I saved it as an asdf system and just have Lisp load it at startup.
And just as often, dynamic typing is the obvious way to go. Same applies to lazy eval, sometimes it makes sense, sometimes not (and thank god for it when it does).
And monads? A hack that admits for most projects outside of academia you need state to Get Shit Done. Even if it makes sense to write a portion or all of the project in a purely functional style, once again Lisp handles that without a second thought. It's simply a matter of not using assignment.
And if you're really that addicted to them (they *do* have some nice qualities), once again it's a simple matter of macros.
Parallelism? That's one of the things functional style makes sense for. Big deal *shrugs*.
Your "future" has already been here for half a century. Everyone else is just catching up, implementing more and more of Lisp as they go.
*I wish there were something like Slime for Python or Ruby, when I'm forced to use these weird halfhearted Lisp clones for bill paying purposes.
**Compiling to raw machine code mind you, much like Haskell can be native or VM. Lisp hasn't been purely interpreted in fucking eons. Admittedly, GHC's Haskell -> C translation is pretty slick, but most Lisp users don't have a need for it, and heavy work is long underway for those that do (CLiCC for Common Lisp, Chicken for Scheme, among others for both), or quite often any given CL system will happily save a core image that bundles the "runtime" (what's the proper word for this?) needed, or there's ECL or such.
And as a side note, I'm eager to see what becomes of Scheme when R6RS is final. Its tail recursion, call/cc, cleaner syntax, etc... have been sexy as hell for quite some time but without a standard method for handling packages/libraries it has remained barely an academic blip in the Lisp world. I can easily imagine Common Lisp becoming regarded as basically a Scheme that already has a set of popular libraries loaded.
Rant (Score:2, Interesting)
C++ has a lot of different features, which is why some find it confusing, but it is those many features which allow the language to be so flexible. Whereas a language, again picking on java, such as java forces the programmer to follow a very strict object-oriented form, C++ gives the programmer a choice as to how they want to write their code. I can write very object-oriented code, with features java doesn't support such as operator overloading and multiple inheritance, or I can write very functional-based code that resembles C. Also, C++ gives the programmer true control over what is going on inside their application. In java for example, objects are passed by reference and primitives are passed by value. In C++, I can specify which of the two I want for either type on a per argument basis. Another example is exceptions, which are known to be a rather slow feature in a language. In a language such as Java, again sorry java fans, exceptions are an integral part of the runtime interpreter. In C++, if I find that I don't wish to use exceptions, I can disable support for them and regain that performance boost that was lost at the hands of exception checking.
Alright, alright..I am done ranting for now. All I guess I am trying to say is that yeah, maybe C++ is a bit more confusing to a beginner then interpreted languages and the like, but it is those features which can be confusing that allow a programmer to really control their code. The better the programmer understands what the code they are writing is doing, the better code they will write. That being said, long live bit flags, unsigned variable types, multiple inheritance, operator overloading and raw pointers!
-Your Local
Re:Parent is trolling (Score:1, Interesting)
Ditto on VC++ being a crummy editor. In fact almost all the blue badges (full-time Microsoft employees) I met were dedicated vim users, except for a few Emacs freaks like me.
Re:What follows C++ is probably (Score:3, Interesting)
Re:What follows C++ is probably (Score:2, Interesting)
Re:Rant (Score:2, Interesting)
This discussion reminds me of a very interesting book [amazon.com] that one of my professors lent to me which was a sort of puzzle book describing some small intricacies within the JVM that could lead to rather large bugs. Even with higher-level programming languages, I still believe it is necessary to have a strong understanding of the underlying implementation. So in other words...
C++ is dying while C is thriving (Score:3, Interesting)