Slashdot Mirror
Bjarne Stroustrup On Concepts, C++0x
An anonymous reader writes "Danny Kalev has an interview with Bjarne Stroustrup about the failure of concepts, the technical issues of concepts, whether the ISO committee's days are over, and whether C++ is at a dead-end. 'I don't think that concepts were doomed to fail. Also, I don't think concepts were trying to fix many things or to transform C++ into an almost new language. They were introduced to do one thing: provide direct language support to the by-far dominant use of templates: generic programming. They were intended to allow direct expression of what people already state in comments, in design documents, and in documentation. Every well-designed template is written with a notion of what is required from its arguments. For good code, those requirements are documented (think of the standard's requirements tables). That is, today most templates are designed using an informal notion of concepts.'"
No you need to calm down and thing about the previous designations of C and C++ standards: C++98, C99, etc. C++0x was intended to be a C++ standard released between 2000 and 2009; at this point, it looks like it is actually going to be released in 2010, and we'll all be calling it C++10.
Palm trees and 8
It's named in parallel with language-revision names like Fortran77 and C99, that use the base language plus the last two digits of their revision year. When the process started years ago, though, they didn't know what year it would finish, but expected it to be in the 200x decade, hence "0x". So, C++0x. Now that the finalization has slipped past 2009, it's C++1x. When it actually comes out, it will have a year with no 'x', like C++10 or C++11.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I don't think that they are. There is quite a good comparison on the wiki page. The main difference that springs to mind is that duck typing in Python is dynamic (resolved at runtime), where-as the type system in C++ is static (resolved at compile-time). That makes them very different beasts.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Uncluttered article, without any extra crap and multiple pages. Printable = readable.
Do you realise that most of the guts of Windows is actually written in C++? And that the secretary of the C++ Standards Committe, Herb Sutter, works for Microsoft?
Are you even a C++ developer at all?
Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?
Few people remember this days, but Java was positioned that way back in late 1990s. I cannot find any reference because I don't remember the exact words, but I recall Scott McNealy saying something along the lines of "Now that you have Java, why would you write in anything else"?
Bertrand Meyer and his Eiffel programming language is another example. He isn't really stating directly that it's the best thing since sliced bread, but virtually all his papers on the matter read like aggressive advertisements, praising the virtues of Eiffel, and sniding other languages because they don't "see the light" in form of design-by-contract and command-query separation (conveniently ignoring the major flaws of Eiffel such as universal generic type covariance). He also edited Wikipedia article on Eiffel to match that, got extremely offended when other people have tweaked the article to remove self-promotion, and tried to "revoke" his GFDL'd contributions (read from here on, and check the article history, for the full story of that drama).
The main difference that springs to mind is that duck typing in Python is dynamic (resolved at runtime), where-as the type system in C++ is static (resolved at compile-time).
Compile-time checking has two purposes: enforce contracts between methods and allow for optimization. I'll cover each of these in turn:
Dynamic languages have more overhead to dispatch a method call. But then static languages have to duplicate the template code for each type that it handles. It is disputed whether the more direct dispatch outweighs the overhead of loading the duplicated instructions into the CPU's instruction cache.
Types of arguments to methods make up part of a contract between a method and methods that call it. It's good to have a compiler that can verify some of a contract at compile time, but the halting problem implies that not all parts of all contracts can be expressed in a way that can a machine can verify. Fans of dynamic languages claim that purpose-written unit tests can verify contracts more thoroughly than a compiler's built-in checking, but fans of static languages claim that properly done static typing writes half the unit test for you.
C++ is dangerous because it needs to be. There needs to be one high level language in the world that's like juggling operating chainsaws to code in it, because of the options that gives you.
Wrong. It's not essential that a language be unsafe to have low level constructs. Ada, Modula I/II/III, Clascal, Object Pascal, Eiffel, and other hard-compiled languages have been much safer than C++, with comparable power. You don't have to go to an interpretive environment to get safety. That's an illusion from Java, which was made interpretive because Sun wanted portability between their SPARC architecture and the competing Wintel systems.