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.

In the same spirit, I'm very afraid of the compile times that all these new features will incur.

Some of the proposed solution, like Bjarne Stroustrup Comparable<T> class just increase the compilation time with no actual code generated.

The main application that I'm working on contains about 1500 cpp files (not counting headers) and it takes about 2 hours to compile (Pentium IV, 3GHz, IGB RAM). The dependencies aren't great, but the fact is each file just takes too long to compile.

We make extensive of STL and Boost, which greatly increase compilation time for each source file: We could decrease our template usage, but what's the point of using C++ if you can't use the nice templates which make our lifes easier.

To give a comparison, a similar sized project in C# compiles in minutes!

I do hope the C++ committee will look at proposals to increase compilation times, such as N1736 and others.

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

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 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.

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

Seriously? Could you provide your profiling output?

I can't imagine that any place where you would put a call to the Log::Print() function would be executed enough times to have any impact on a modern CPU. Perhaps if the stubbed inline function was called a few billion times during program execution, it would eat up 1 second.

I've seen the log macro trick used on titles for PS2. Having log functions in the final build is totally pointless. In this case you want the entire thing to be obliterated, including the actual text string itself.

I can also imagine advantages in moving towards asserts using actual functions, with overloaded or templated variants. However thats a moot point until a replacement to __file__, __line__ comes along.

Reading through the open-std docs, there are much more interesting things coming to C++, but this little issue has always niggled at me ever since I've seen it. :)

> I've seen the log macro trick used on titles for PS2.
> Having log functions in the final build is totally
> y pointless. In this case you want the entire thing to be
> obliterated, including the actual text string itself.

Why? I have found that being able to turn on logging on target systems at runtime saves tons of debugging time. I think the value of having that information far outweighs any performance considerations.

> I can also imagine advantages in moving towards asserts
> using actual functions, with overloaded or templated
> variants. However thats a moot point until a replacement
> to __file__, __line__ comes along.

Or some kind of object standard and support for reflection. I use a nifty Trace() in C# that uses reflection to give the context of the trace.

> In the same spirit, I'm very afraid of the compile times
> that all these new features will incur.
>
I also see my compile times skyrocketing.

Templates are largly used as workarounds for missing/incomplete features.
So on the top of my wishlist is:
-- remove Templates and replace them with:
1. subtype polymorphism, higher order functions (for generic programming)
2. make Types first order entities with (compiletime) type operators (for compile time programming/domain specific embedded languages)
3. allow compile time programming with all statically defined objects (explicitly including floats, strings, ...)
4. some access to the lexer (i.e. a _save_ macro replacement), which allows to specially handle user defined types and syntax (for domain specific embedded languages and to finally replace macros)

This should reduce boost, blitz, fc++, loki, ... to 30% of their size and make them compile _much_ faster.

Apart from that I'd like:

--Usable enum's for code like:

enum greyScale{white, grey, black};
int color[greyScale];
Range range(greyScale);
for (range)
{
cout << color[range] << " "; // -> white grey black
}


--Make implicit and default things explicit:
e.g:
class A
{
public:
implicit A(int a) i(a) {} // implicit by demand
default A(A&) {} // generate default constructors only when I say so
int operator(){return i;} // explicit by default
private:
int i;
};

-- direct support for multi threading (processes, threads, IPC)

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...

- properties.
- in-place callbacks (Java anonymous classes).
- guaranteed size of integer variables: int16, int32, uint16, uint32, so on 8 to 64 bits. Size shouldn't be guaranteed to be the same, but rather at least, so that implementation's speed would be decent.
- better enums: strongly typed, in-language way to get value's name (prohibiting to set integer value allows static name table).
- information about throw site on throwing and accomulating of call stack (at least function name if not call site of other functions) on processing exception down the call stack.
- definition of throwing declaration standard and checked exceptions.
- javadoc
- @deprecated
- #pragma once
- virtual (const) static fields for trait types (now it requires private derivation to save that byte in instance).
- standard way to set default calling convention as preprocessor #pragma to #include files from libraries with different default convention without need to patch all function declarations in header files of one of libraries.

> auto it = v.begin();
>
> -or-
>
> let it = v.begin();

I think it would better be

v.iterator it=v.begin

>
> I think it would better be
>
> v.iterator it=v.begin
>
That doesn't scale well with nested structs and typedefs. If I get you correctly, I would still have to specify the full 'path' to some nested type...?