I don't know if I read the wish list well but I didn't see
anny mentioning of the following in the requests for enhancements to the STL:

-- Smart pointer objects (See Josuttis' book or look at the boost library cases)

-- HASH containers... come on this one is a must!

And also, can someone appoint some people that actually program in C++ to that commision. That would make a difference as most practical issues are usually ignored in order to get some theoretical perfection that is never reached.

>11. Extended type information (as much runtime type information as possible for a compiled language)

I guess this would cover introspection (by applying this extended type information to instances).

I would add to this: arbitrary user-created meta data for all constructs. I know this isn't an easy one, but getting something anywhere towards this ideal would be really great.

It's a feature that helps make introspection really useful. For example, when pushing introspection to do persistence, GUI editing, report making, etc. Arbitrary meta data lets you mark up the classes/fields with all sorts of things like a description, or a read-only marker, or marking things as primary state vs derived state, or setting policies for GUI editing (like to say that this Vector2 is a position in the space defined by _that_ transform).

I'm a die hard C++ programmer, but after working with C# for a bit, I found myself wishing C++ could do this. I know it's not fashionable for C++ to add features that "C++ replacement languages" have, but let's just say we are inspired by lisp or something...

I like templates and use them frequently and the most libraries are based on them too, but what I miss is the possibility to define templates with an unknown number of parameters.
The BOOST tuple class or signal/slot classes or many others use copy & paste (or the preprocessor) and they are all limited to a fixed maximal count of parameters (e.g. 3 or 5 or 10).

It would be nice, if C++ could itself construct templates with any number of parameters (as '...' in printf()).

extensions to C++:

- '...' in templates
- '##' is the number of '...' parameters (N)
- '#' iterates over all the parameters (1 - N)

examples:


template<class A, ...> class X
{
typedef # arg#_type;

X(A a, ...) { }
};

template<class T, ...> f(const T& t, ...)
{
g(t, ...);
}

template<typename F, typename T, ...>
class result_of<F(...)>
{
static F f;
static # t#;

public:
typedef typeof(f(...)) type;
};

template <...>
struct group
{
# a#;
group(...)
: a#(#...)
{}
};

template <class Ch, class Tr, ...>
inline
BOOST_IO_STD basic_ostream<Ch, Tr>&
operator << (BOOST_IO_STD basic_ostream<Ch, Tr>& os,
const group<...>& x)
{
os << x.a#;
return os;
}


I know this is hard work for compiler vendors but this would replace many copy & paste code and fewer use of the preprocessor.

I would also appreciate, if the header guards (with "#ifdef") could be replaced by another command
(e.g. "#pragma once" like some (but not all) vendors do - I know that this is another pp-command, but easier to use).

I would hop for templated typedefs as a means to alias template names. THis greatly would faciliate metaprogramming and would also make C++ more consitent.

I would like some language/library support for an automatic way to use polymorphism without needing to expose pointers/memory management to the application program. I have developed ways to do this, based on the Coplien "envelope/letter" idiom, but more convenient and flexible. From my experience, I'm pretty sure that many other C++ developers could benefit greatly from support for such a feature, as it is far from obvious how to implement it unless you have seen it before.

A couple things I would really like to see supported:

1- Exception reporting. I realize debug info is compiler specific; but it'd be so darn usefull if there was a standardized way of reporting where the exception was thrown (not caught). This should include the filename, the line number, and the call stack.

2- Better support for pointers to functions and methods (functors and closures). Specifically, it sould be possible to have a variable point to any of: Base::Method(), Derived::Method() (no contravariance), or ::GlobalFunction() if they have the same parameters.
Borland C++Builder supports this with the __closure keyword extension. I also wrote a template class using partial parameterization; but I shouldn't have to.

That's my wish list.
Stephane

- typeof would be handy (and AFAIK, some form of it is considered). If nothing else, it would greatly improve syntax of all the stuff related to expression templates.

- Another thing that comes to mind is that much of template meta-programming that we are doing now looks very much as hacking. Instead of asking the compiler for certain information, we apply some action, as to a black box, and watch how it reacts. And then we make decisions based on these reactions (consider SFINAE).

Instead of that, compilers could expose some kind of an "object model", available at compile time, in the similar fashion IE exposes its DHTML. We would be able to ask the compiler which classes have been defined, which templates instantiated, what is the type of this particular expression (typeof), whether a class has a certain typedef, etc. At the same time we could drive the compilation process by writing to this "object model", e.g., create compile-time variables, undefine classes, etc.

- One more "complain": although C++ has rules regarding cross-unit compilation (ODR), there appears to be no "tools" that could act across compilation units, everything gets reset.

- An ability to define an entity in a namespace other then the current context, such as:

namespace A
{
class ::B::MyClass
{
};
}

would allow to wrap a class and corresponding specialization (trait) into a macro...

- non-deducable context... Is it really necessary? Why not be able to specialize on vector<T>::const_iterator?

Regards,
Arkadiy

This is petty but, with the STL using unsigned int for its size()s, if you want to be anal you have to use unsigned to avoid signed/unsigned mismatches. Typing (keyboard kind) unsigned is slower than int - how about uint as an alias? Or is that included in the new <inttypes.h>?

(1) Consider making a statement about what kinds of memory models C++ will support.

Example: I have been involved a number of projects in which multiple processes had their own static spaces, but all had access to a shared arena. It seems the world is moving away from this, toward the multi-threaded model, in which every thread has the same static space.

I don't have a problem with this move. But consider: I could make an STL container accessible to all processes by putting it in the shared arena and giving it a shared-memory allocator. However, I cannot use the Boost shared_ptr in this context, since it does dynamic allocation, but does not allow me to specify an allocator.

I am not saying the Boost shared_ptr is "bad" (on the contrary, I think it is very much needed). I am saying that we need to think about things like this. Do we intend to support every memory model under the sun? If so, then any shared_ptr that gets added to the Standard Library needs to allow specification of an allocator. If not, then we should make a explicit statement about what memory models the Standard Library is intended to support.

(2) More generally, be careful about introducing possible system dependencies into the Standard Library.

The "C++0x Standard Library Wishlist" includes:

5. A threads library
6. A socket library
10. Some form of simple graphic/GUI library

All of these (and possibly some others on the list) will tend to make C++ favor certain kinds of systems above others. Again, I do not have a problem with this. I do have a problem with adding these things without careful consideration and explicit statements of intent.

(3) Include the Boost random number library.

Isn't everyone tired of cruddy pseudo-random number generators?

(4) Some thoughts on octonions and quaternions:

From the "C++0x Standard Library Wishlist":

21. Math/octonion & math/quaternions (used by game designers for 3d math)

Octonions are a mere curiosity, to be exhibited in the occasional advanced math class. No one uses them for anything practical. Certainly no game designer does anything with them.

Quaternions, on the other hand, certainly are useful, being a good basis for computations involving 3-D rotations and orientations.

However, the Boost quaternion package, while it is a top-notch implementation, is a mathematician's idea of a quaternion package, not a game designer's. The mathematician thinks the trig functions and the multipolar representation are great, but the game designer will never use them. The game designer wants quaternions that interact well with 3-D vectors. For example, it seems silly to have to write

quaternion<double>(0., v[0], v[1], v[2]);

when what I really want is something like

quaternion<double>(0., v.begin());

I suggest adding a constructor that, as above, takes a floating-point value and an input iterator. Similarly, add a version of quaternion<T>::unreal that takes an output iterator and sends its i, j, & k values to wherever the iterator points.

(5) Lastly, for goodness sake, specify std::sort to be O(n log n).

The committee knows that already, right?

What about synchronized keyword to synchronize the whole method (like Java)? This will ensure that programmers do not forget to unlock a semaphore when they return from a middle of a function.

My top list of want to haves are:
- template typedefs;
- auto type.

per illustration:


template< typename T, typename U >
struct foo_T { };

struct t_t { };

template< typename T >
typedef foo_t_T< T > foo_T< t_t, T >;


and


template< typename T >
T foo(const T & t_)
{ return t_; }

struct foo_t {};

void bar()
{
auto tmp = foo(foo_t());
}


1. "Controlled virtuality" - like in C# or (even better) C++/CLI. Right now, if you declare a function virtual in a parent class, virtuality will automatically be inherited even if it is not really needed. For instance:

struct IMyInterface {
virtual void fun() = 0;
};

struct MyImplementation {
void fun(); // this one is also virtual
};

In order not to break existing code, maybe it would be a good idea to add a keyword that would "stop" a function from being virtual:

struct MyImplementation {
nonvirtual void fun(); // this one is not virtual
};

2. XML API. I agree we need a good XML API. However, I would strongly suggest to avoid DOM which is non-efficient and not "C++ friendly". Some cursor-based model would be much better, IMHO.

Where are class properties (those things which replace calling getter/setter methods in user code)? They are often used in many languages and even some C++ extensions have them, but I'v e seen no remark on them.

This one may sound silly, but here it is:

Source code is the human interface to the language, and source code is edited in text editors. Most programming editors indent based on braces. The only reason i don't use deeply-nested namespaces in C++ (a-la Java) is because this indention gets unwieldy after 2-3 namespaces. Because source code is OUR interface to the language, i will propose a small amount of syntactic sugar to make it easier to nest namespaces without confusing editors:

Current syntax and typical usage:

namespace one {
(1x indent) namespace two {
(2x indent) namespace three {}
(1x indent) }
}


Suggested as an acceptable shortcut:


namespace one::two::three {

}


Easy enough to add to C++ parsers, i would think.

The significance is that editors which indent only have one indention level to deal with, and also their syntax-highlighting code may not even have to change to deal with it.

i wish... i wish... i wish...

For an in-language way to get the string form of a class' name.

e.g., i'd love to see a well-defined-behaviour restriction placed on typeid::name(). Even if it didn't return "MyClassName", i'd like it to be forced to return some standardized representation of a type's NAME. To make this easier on compiler implementors, a type name should not include any type modifier info, like const, *, &, etc., as in a string context they are not normally significant (in my experience).

Probably a minor thing, but I would like to have the "substr" method on strings check for and handle strings that are out of bounds.

For instance, if I were to say something like this:
string foo="Hello";
string bar="";
bar=foo.substr(bar,10,10);

It should not give a run-time exception. It should merely set bar to "". (Just like awk, php and perl do!)

I do say it from my side of enterprise programmer, and I'm not taking into account all problems related to HW architectures and platforms.

This is also a high level and demanding list, therefore it may go out of the boundaries of what it can stay within the actual timeframes and scoping.

1 A standardized documetation facility (e.g. doxygen)

2 A metadata language support (e.g. xdoclet,jdk1.5)

3 A draft Support for reversibility from the implementation
to a "set of" design paradigms (e.g. UML and eiffel)
This feature can be nicely integrated with graph support,
documentation, metadata, and even the graphical
facilities

4 Draft support for the design by contract method

5 A standardized support for testing availble from the
asserts in the contracts

6 Aspects (e.g. aspects cpp)

7 A draft specification for a web service container,
taking into account also authentication

Kindly,
Diego Bragato

It's not my most important, or anything like it, but I haven't actually seen anyone else ever ask for it. It is trivial however.

Overloads of std::conj in <complex> for float, double and long double which simply return their argument, e.g.

double std::conj(double x) {return x;}

Why? So you can write a single template covering real and complex cases which involve conjugation. An inner product is a typical example, x * conj(y), which is x * y when real.

You could argue the case for other complex-only functions in <complex> such as arg, but I've not needed those. conj I have.

Add some support for delegation.

Ideally, something like Borland's __closure, but with support for static functions, with better integration into the type system, and with the full set of operations.

------------------------
Bare minimum proposal
------------------------
Modify section 5.2.10/9 to state that when a member function pointer(MFP) a of class X is converted using reinterpret_cast<> to another MFP b of a class Y __of incomplete type__ but the same signature, and a pointer p to X is converted to a pointer q to Y using static_cast<>, then
invoking (q->*b)() is equivalent to (p->*a)().

This works on every C++ compiler ever made. It allows creation of optimally efficient delegates. Here's an example implementation:

http://www.codeproject.com/cpp/FastDelegate.asp

Unfortunately, this code is not legal (even though it works on all compilers, albeit with some nasty tricks for the non-standard MFPs used by Microsoft/Intel). But with that trivial change to the standard, it could be made legal retrospectively.

The proposal has no side effects on other areas of the language. All extant compilers are automatically compliant.
And it adds a significant new concept to the language.
(In one of Herb's recent blogs, he mentioned that he drools over C# delegates. These are better, because they work with templates).

I doubt you'll find anything with a better "bang for your buck".

Of course it would be nice to have full language integration, especially with better error messages, and a defined ABI for delegate structures -- but please consider this kind of zero-cost option if a full implementation doesn't make the list.

I have two requests:

[1] Allow underscores within (i.e., inside, not at the beginning) an integer literal to improve readability.
See this thread in comp.lang.c++.moderated:
Message-ID: <22868227.0411021649.97c19df@posting.google.com>

[2] Raw string literals where back-slashes are just another character.
E.g.,
r"This is a \n special string \t where there are no new lines or tabs"
This would immensely help if C++ should be used for REs.

thanks,
- Anand

What I am missing in both list is improved/strongly typed enumerations. There have been some excelent proposals on comp.std.c++!

Personaly, I would also like the ability to extend an enumeration.
Say for example that a base class contains an
enum Base::color { r, g, b }
then it is sometimes desirable to have
enum Derived::color { Base::color, c, m ,y }
in a derived class.

The ability to divide the public portion of a class's interface into named "subsets". Users of the subset would need an explicit statement indicating the usage. For example:

class A
{
public: ... // just plain public
public X: ... // stuff in the X subset
public Y: ... // stuff in the Y subset
public X: ... // more stuff in the X subset
};

void foo (A &a)
{
using class A::X;
...
}

class B
{
using class A::X;
...
};

**********

In one large class heirarchy I worked with, there were a great many virtual function overrides that really just provided the value of a constant for some algorithm implemented in the base class, for example:

class Quarter : public Coin
{
public:
virtual int value(void) const ( return(25); }
...
};

It would be clearer (and improve performance a bit) to be able to say:

class Quarter : public Coin
{
public:
virtual int Value = 25;
...
};

The value of "Value" could be stored directly in the vstruct. The declaration:

class Coin
{
public:
virtual int Value;
...
};

would make "Coin" abstract, since no value for "Value" is given.

**********

A "psuedo-template" name footprint. The class footprint<A> would have the same size and alignment requirements as class A, but footprint<A> would have an vacuous implicit constructer and no other members. The purpose is this:

union X
{
footprint<A> a;
struct B b;
footprint <C> c;
};

X x;
...

// Use x to store an A instance, constructed using
// new placement syntax.
new (&x.a) A;

**********

In the same way that physicist are in need of a Unified Field Theory, I dream of a "Unified Meta-programming Mechanism" for C++. What I mean by this is some "thing" that would do everything that both templates and macros do and do it as well. For example, the "typeof" operator gives macros a fighting chance to act somewhat like function templates. Could a pre-processor with m4-type power and some set of "semantics-extraction" mechanisms (like typeof) take the place of templates? This is so brief and sketchy as to be useless. But maybe someone smarter than me can make something of it.

http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_frm/thread/747d3f2b3a82524a

Here I propose idea of template typedef along with its syntax and some neat features it will allow. Please note that this is not 'usual' template typedef, i.e. you can not do like this:

template<class T>
typedef foo<T, U>* foo2<T>;

->

foo2<T> pVar;

equivalent to

foo<T, U>* pVar;

instead it is a direct mirroring of typedef to the templates world.


Also allowing forward declarations for type and template aliases will help! (or introduce implicit forwarding like in C#)

Bye.
Sincerely yours, Michael.

virtual const data members

Today a vtable is really an initialized static const struct containing only pointers to functions (plus possibly some opaque data used by the run time system). I would very much like to be able to declare and initialize members of types other than simply pointer to function.

class C1 {
    // this single property costs a full pointer in the vtable
    virtual bool propertyX(void) const { return false; }
    ...
    // all together these properties occupy a single vtable byte
    virtual bool const propertyA : 1 = false;
    virtual bool const propertyB : 1 = false;
    virtual bool const propertyC : 1 = false;
    virtual bool const propertyD : 1 = false;
    virtual bool const propertyE : 1 = false;
    virtual bool const propertyF : 1 = false;
};
 
 
class C2 : C1 {
    // override a few properties
    virtual bool propertyX(void) const { return true; }
    ...
    virtual bool const propertyC : 1 = true;
};
 
 
void foo(C1& myC)
{
    // full cost of a virtual method dispatch
    if ( myC.propertyX() )
        ...;
 
    // single fetch, unaltered control flow, better register allocation
    if ( myC.propertyC )
        ...;
}

A few times I missed a special destructor that is called on “normal” scope leave but not as part of the stack unwinding on exception. Or perhaps an ability to recognize the stack unwinding run-time. For example if some work should be done on scope leave or say on destruction of a temporary but if no exception occurred only. It should be legal to throw from this “finalizer” code. E.g. Formatting helper when data are prepared and then processed automatically in a single step unless an exception occurred:
Logger(mylog) << “x=” << x;
Here Logger::~Logger() logs the formatted message providing additional information like timestamp etc but it should only do so on success but not if an exception occurred. Of course the same can be achieved with just one extra line or an explicit message “terminator” but that’s more verbose and easy to forget.
Similar technique might be used for database interfacing (format an SQL query and then execute it if everything is fine), XML tag auto-closure etc.

I would like to solve the problem of ambiguous overriding from 2 base classes:

ie:

class A { virtual int update() = 0; /* and other stuff */ };
class B { virtual int update() = 0; /* etc */ };

class C : A, B
{
   int update()
   {
      // update stuff
   }
};

which update is C overriding? Can't tell, thus error.

How about:

class C: A, B
{
   int A::update()  // override A::update
   {
      // do update stuff for A interface
   }
   int B::update()
   {
      // do stuff because you are a B...
   }
};

?

After coding for many years in both C++ and Java I have in mind some features, which Java lacks and also those, which would be nice to have in C++. Here are two big ones (as I see them):

1) Database connectivity API. I'm actually surprised that this was not pointed out at all. One can say that ODBC is there. But ODBC drivers are often not official on UNIX platforms and in real live there is C++ library for every RDBMS. It would really be nice to have some common standard interface.

2) This one is more in science fiction realm, but let's dream a bit. Reflection. Ability to load code dynamically. This Java feature is so powerful. I can hardly imagine how it can be fully implemented in C++, but at least efficient, programmer-friendly way to access objects in shared libraries as well as defining own object loaders would be first step in this direction.

Best regards.

things i would like to see in C++0x:
- C99 variable-length arrays
- thread, atomic and aline keywords for variables
- naked and deprecated for functions
- better inline assembly: guideline rules for standard implementations
- a new pointer for garbage collection, with very well defined rules for referencing/dereferencing, etc...
- exceptions: add finally; new exceptions to caught things like divide by zero, floating point exceptions, etc...
- add rotate left/rigth operators, add support for add/sub/shift with carry
- class properties
- interfaces
- unicode: uchar8, uchar16, uchar32 and wchar for platform default (ex: uchar8 for linux, uchar16 for windows)

for a detail description see: http://clientes.netvisao.pt/camop/
please send any comments and suggestions

I have 2 propositions.

The first helps to reduce dependencies when the implementations of classes are changed. Consider the following case:

header:

class A
{
public:
  void foo();
private:
  int a;
};

module:

void A::foo()
{
  //...
}

Now we spot a bottle neck in A::foo and we rewrite it and therefore introduce a helper function. In the good old C days one would simply have made this one static and the header would not need to be changed. Here although we would need to declare the helper method in the header (assuming it needs access to a) and thus need to recompile all modules using that header for no good reason. Methods do not affect the representation of an instance in memory and therefore technically don't have to be declared in the header if they are not called from outside of the class.

I propose that all member functions defined outside of the class declaration and not declared in the class declaration are implicitly declared private, module local and non virtual.

This will not break encapsulation as without a public member function defined inside the class declaration you will not be able to invoke member functions declared outside of the class declaration.


My second proposition is that the this pointer may be a smart pointer. This would allow for example much better implementations of garbage collectors as one can move the memory of instances around, by encapsulating an additional level of indirection inside the smart pointer, without needing to tell the outside. One problem that although arises is that it is still possible to take the address of a member. This needs further thinking.

Optional argument evaluation.
Sometimes we have debug logging functions that need to be obliterated in final, but even empty inline functions incur the overhead of argument evaluation.

Log::Print("Length = %f \n", myvector.Length());

There's no way to avoid the myvector.Length() call in release. This is the one time that I've seen justifiable use of macros in C++ code, simply because there is no other way of doing it.

What's needed is an "optional_args" keyword to tell the compiler it can delay or avoid evaluating inline function arguments.

template <typename T>
optional_args void Print(int priority, const char* message, T value)
{
if (priority >= global_priority)
{
DoPrint(message, value);
}
}

If both priority ints are const, the compiler could just nuke the whole lot, otherwise at least only evaluate the inline arguments until the DoPrint.

Note I've avoided var-args since compilers can't easily inline this, which is necessary for the optimisation to occur.

I have probably overlooked it but I didn't see anything about implicit forward declarations and doing away with header files completely. I do not pretend to have breadth and insight on this issue, but I have seen other (respectable) people refer to header files as purely compiler assisting concept that is now obsolete given the power of the average machine and level of sophistication compilers achieved. Recursive dependency and source code redundancy are the two major problems stemming from header files that are just on the top of my head now.
But maybe I'm missing the whole point of this new version of C++ - is it supposed to be source-level backwards compatible?

I'm surprised that nobody has mentioned type inference. So instead of writing

vector<int>::iterator it = v.begin()

make it possible to write:

auto it = v.begin();

-or-

let it = v.begin();

('let' shamelessly pulled from Ocaml). typeof() doesn't quite cut it since then I'd have to write

typeof(v.begin()) it = v.begin();

This may seem a simple example, but it really pays of with nested templated classes...

I want stl associative container(set,map etc) to be more flexible. code like below:

std::set<T> set_obj;
std::set<T>::key_compare& kc = set_obj.key_comp();
std::set<T>::iterator iter = set_obj.find(x);
*iter = y;
kc.change_param(z);

I can not change the values directly, and i can not get the key compare functor by refrence.In some special cases, I want to change the element value and the key compare functor synchronously, and I ensure the set's ordering is keeped. I can not do that now.

I want the STL change that

Introduce an interface keyword that eliminates the hazards of downcasting in a multiple-interface class hierarchy (without requiring RTTI overhead or the use of dynamic_cast). Here's how it could be implemented:

An interface is defined as a struct that cannot contain any non-static data members. All non-static interface methods are virtual. Static data members and static methods are allowed, and constructors and destructors can be optionally defined.

Multiple interfaces could then be added to a virtual base, single-inheritance class hierarchy without requiring more than a single vtable pointer in each base and derived class runtime structure. The vtable pointer for each interface would be a component of each of the class vtables rather than a component of each object instance.

The advantage is that we could retain the runtime efficiency and reliable downcasting properties of single-inheritance class hierarchies, while taking full advantage of the flexibility of multiple interface inheritance. The only drawback would be the small runtime and code size overheads of the additional level of indirection required to reach interface methods. But since interfaces are intended for module encapsulation rather than efficiency, this would be a minor price to pay.

One thing I end up doing a lot in our system here is using the preprocessor to instantiate virtual functions when using the Visitor pattern on a large tree heirarchy, and I'd like to propose an extension to templates that might have applicability elsewhere. In the below example, I'm not particularly suggesting a syntax or any keywords or anything. I'm merely using some things that look like keywords and syntax to get the _concept_ of this across. If there's a better or more succinct way to do it...I'm not a language design expert. ;^)

Let's say I have a heirarchy of tree nodes:

class Visitor;
 
class Base { ... };  // This one is abstract.
class A : public Base
{
    ...
    Base& traverse_left();
    Base& traverse_right();
    ...
};
class B : public Base
{
    ...
    Base& traverse_down();
    ...
};
class C : public A { ... };
class D : public A { ... };
class E : public B { ... };
class F : public Base { ... };
class G : public F { ... };
class H : public F { ... };
class I : public F { ... };

(Assume that I've declared:

    void accept(Visitor& v);

in every class above.)

I'd like to be able to divide this heirarchy into groups of types:

type_group SimilarToA = { A, C, D };
type_group SimilarToB = { B, E };

or even better:

type_group SimilarToA = { A, has_base_class(A) };
type_group SimilarToB = { A, has_base_class(B) };
type_group SimilarToF = { F, has_base_class(F) };
type_group AllTreeNodes = { has_base_class(Base) };

Then, let's say I was doing some visitors, I would like to be able to do apply these type group at compile time:

class Visitor
{
    // "apply<List as Name> { code } " would cause the
    // compiler to generate code in a fashion similar to
    // a template, replacing Name in the code between the
    // braces with each name from the list in succession.
    //
    // So the following clause would expand to:
    //
    //   virtual void Visit(A&) = 0;
    //   virtual void Visit(B&) = 0;
    //   ...
    //   virtual void Visit(H&) = 0;
    //   virtual void Visit(I&) = 0;
    //
    apply<AllTreeNodes as T>
    {
       virtual void Visit(T&) = 0;
    }
};

Then I can define traversal (and let's assume it's different for the different classes above):

class TreeTraversal
{
    // Leaves don't traverse.
    apply<SimilarToF as T>
    {
       virtual void Visit(T& n) { }
    }
 
    // A nodes traverse to the left then the right.
    apply<SimilarToA as T>
    {
       virtual void Visit(T& n)
       {
          n.traverse_left().accept(this);
          n.traverse_right().accept(this);
       }
    }
 
    // B nodes traverse down.
    apply<SimilarToB as T>
    {
       virtual void Visit(T& n)
       {
           n.traverse_down().accept(this);
       }
    }
};

One might define a design rule using this facility:

template<class Base>
class MustVisitAllA : public Base
{
    apply<SimilarToA as T>
    {
       virtual void Visit(T&) = 0;
    }
}

And then when compiling a class that inherits from a concrete instantiation of the rule, you'll be forced to implement all the A visits.

One could see that if there were a lot of subclasses of visitor, then this technique could be used quite well to generate methods in them. Right now, to do something similar to the above, I have to use the preprocessor, with all the ugliness and debugging difficulty that this entails. It has been worth it as I probably have a 10:1 ratio of generated methods vs. methods that I have to write (and debug) in our application.

I know that the example I give of use of this is specific to my particular design, but I believe that the ability to apply a list of types to the generation of a section of code arbitrarily as above would be a powerful and useful addition to the language. I don't currently know of a way to generate similar memeber functions (or certain other things) without using the preprocessor.

Thanks for your time. Let me know if this is of any interest.

--
George T. Talbot

I posted these wishes in another thread (A Brief Look at C++0x), but obviously they belong here!!


1. Variadic templates
(as suggested and discussed elsewhere)



2. Anonymous nested objects (here: c.nested) with access to the containing object (here: c of type C). It should be possible to derive their type from a base class (here: 'Base'). I want to suggest different possible syntax for that (it would be enough to have one).

struct Base {
    virtual void foo() {}
};
 
struct C {
    void foo_C() {}
 
    // not possible in c++ nowadays
    Base {
        void foo() {foo_C();}  // nowadays, c.nested has no access to the members of c.
    } nested; 
 
    // not possible in c++ nowadays
    Base nested {...}; 
 
    // not possible in c++ nowadays
    struct {...} nested : Base; 
 
    // not possible in c++ nowadays
    struct : Base {...} nested; 
 
    // possible, but doesn't derive anything
    struct {
        void foo() {foo_C();}  // not possible - nowadays, c.nested has no access to the members of c.
    } nested; 
} c;
 
Base* b = c.nested;
b->foo();

To access the members of c, c.nested doesn't need to store a reference. The adress difference of c and c.nested is the same for any object c with type C, so accessing c.foo_C() would technically be no problem.

(Nowadays, this can be achieved using the barton-nackmann trick and multi-inheritance, but that's not a nice solution)



3. The same for nested functions - they should as well be able to access other members of the containing class or function.



4. A "This" keyword to identify the type of "*this".

template<... ... ...> class A {
    typedef A<... ... ...> This;  // too clumsy, should be done by the compiler!!
};

5. exit loops with a break statement with return value

for(...) {
   ...
   if(..) break end_of_file(i);
   else if(..) break end_of_file(i+5);
   else if(..) break found_error("parsing_error");
   ...
   if(..) break found_error("mature content");
}
 
cout << "normal_break" << endl;
 
label end_of_file(int line_number) {
   cout << "end of file reached in line "<< line_number << endl;
}
 
cout << "normal break or end of file finished" << endl;
 
label found_error(char* message) {
   cout << "found error " << message << endl;
}
 
cout << "normal break or eof or found an error" << endl;

These labels are similar to nested functions. The difference is, when they are finished, execution will continue in the line where the label block ends.

The same could be achieved with helper functions, but then the code would be scattered in places where it is hard to find.

C++ has no standard for adding assembly
lines for the source code(Compilers act on there own ways).
why don't we make a standard to this via C++0x ?

In my opinion two most important additions to C++ would be:
1) Compile time meta information (Something like Daveed Vandevoorde's metacode).
2) Standard modules - C++ version of Java class files or .net assemblies.

These two features could revolutionize C++ once again.

Compile time meta information.
Although template metaprogramming is a very cool and interesting way of getting some things done, It looks too complicated and has certain limitations that are direct consequence of the lack of the type information during the compilation. Some metadata can be obtained using quite indirect and unnatural tricks, but anyway, that approach is too limited.
Even if it's too difficult to implement all Daveed's ideas, at least some way to iterate over class/template's members/member functions and their types would be very useful.
Something resembling .net attributes but available during the compile time instead of (or in addition to - optionally) runtime - would be awesome. This would enable a whole gamut of new powerful techniques.
All this additions revolving around the metadata issue would greatly reduce the need for code generation tools for C++ resulting in more portable elegant and generic solutions.

Optionally, making this rich metadata (extended RTTI) available during the runtime would be also handy, but I'm not a big fan of that idea because it might encourage structurally simple but inefficient Java/C# style solutions.

2) Standard modules.
This would make possible to share C++ binaries across different OSes and platforms as long as the CPU instruction set is the same. Platform specific code could be isolated in platform specific binaries with the same C++ interfaces.
Ability to include those modules would also be nice. This is already implemented in MSVC:
#import "some.dll"
Just make it something portable and standard.

3) I agree that access to host class members/functions from the nested class could be useful in some cases and not too difficult to implement. I believe implementation complexity would be similar in a way to multiple (virtual) inheritance.
From the conceptual point of view it's no uglier than MI itself or friends for example.

multiple levels could be handled with either scope resolution operator, or additional keyword (host?):

1) OuterHostClassName::this->someFunc();
or
2) host.host.someFunc();

whichever feels more consistent with C++ syntax.