The design of C++0x

B. Stroustrup. The design of C++0x. C/C++ Users Journal. May 2005.

My basic opinion is that the language wish list is far too long, and that the libraries wish list is far too modest.

Two topics of interest: type safety, and support for concepts in the template model (i.e., the generic programming model).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Although I am font of C++ (99

Although I am font of C++ (99% because of templates), I have to admit it is not an elegant language. There are too many things that have to be added, all exceptional cases, and that's a sign of something without solid theoritical foundations.

I've been playing with LISP lately, and I think that what we need is a new programming language with LISP capabilities from one side and with C capabilities on the other. The LISP side would be a language that would allow programs to be executed at compile time, and thus allowing for infinite concepts (including object-oriented programming) and true expandability, and the C side would provide all the known stuff (pointers, structs etc) that are useful at run-time for truly optimized applications plus direct interfacing with O/S and other services.

Have you come across CMUCL? T

Have you come across CMUCL? That (and probably SBCL) allows low-level programming dealing with pointers, structs, and the like.

Impossible languages

The old fashioned way to deal with low and high level programming in C is to write functions in C and use a scripting language that calls your C library. This system is nicely preserved in the Linux world. Since this is the 21 centuary why not simply update this concept to functions and components (ie objects) in dll’s and use along with your favorite high, high level language where you can express your concepts freely. Why worry about pointers if you don’t even know how to solve the problem yet?

Radical idea

Embed a scripting language into the compiler outright (Ruby, Python, whatever) and obviate the template meta-programming agony.
You could as well put wings on a bus and fly it about, given enough velocity.

Scripted Compiler

You may be interested in this discussion of scripted compilers.

Wah?

Are you for it or again it?

Not in this case

The C++ type system is turing complete, but that actually works against it. Allowing imperative constructs I believe would make things worse, not better.

Scripted Compiler

First on Stroustrups point - there are plenty of libraries available, and it just isn't that important whether they are language standards or not.

The problem is that language issues make life unnecessarily hard whatever libraries you use, and these issues can only be fixed well by updating the language standard. For instance, sure you can write libraries to work around the lack of anonymous functions (see Boost) but you can't magic away the serious limitations in those libraries. The language support isn't there to do a better job.

On to the scripted compiler thing, though, and I basically agree with both Achilleas and Chris - it's just that IMO the scripting language that should be embedded in the C++ compiler should be C++, just as the scripting language used to manipulate LISP code at compile time is LISP itself.

Think of YACC and similar tools. One problem with them is that they don't understand the embedded C/C++ code - they just treat it as a text template. Take a different approach, and YACC could be a library that knows when the embedded code is wrong because it interacts with the compiler during the generation process, in which it creates a ready-compiled module.

Using the Turing-complete template system as a code generator is flawed, partly because it overworks the compiler in terms of creating pointless classes, but also because it is more like Prolog than C++.

If my run-time code is imperitive OOP code, why shouldn't my compile-time code be imperitive OOP code? In fact, why shouldn't I be able to use the exact same code both at run-time and at compile-time? Once I have written some code, I want to be able to re-use that code as much as possible after all.

All that would really be needed is a means of delimiting nestable blocks, a data type representing already compiled blocks, reflection support, and the ability to use "compiler instances" as generated-code absorbing, module creating factory objects. Some scripting languages can already handle most (if not all) of this.

Follow this approach to it's logical conclusion and a lot of C++ tools get a lot easier...

  • Want a refactoring tool? Write it in C++ and use reflection to analyse the code semantically. If the 'block-of-code' type supports roundtripping back to source code, you're pretty much done.
  • Want to check that your unit tests achieve full decision coverage? Write a library that asks the compiler where the decision points are and adds in the appropriate checks.