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

There is already a better mechanism for automatic resource cleanup. Take a look at this article:

http://www.hackcraft.net/raii/

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

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

Actually, it uses "size_t", doesn't it? This is much more typable than "unsigned int".

There has been some talk about considering adopting the new integer type names from C99, which would cover your request, but I don't know where that discussion is at.

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.

(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?

> Where are class properties (those things which replace
> calling getter/setter methods in user code)?

I think this is a great idea, in principle, but I'm a little hazy about how to implement it so that it fits well into C++.

First, are we talking about the same thing. I figure we let something like

cout << x.my_prop;

be translated into something like

cout << x.my_prop_get();

And this

x.my_prop = 3;

turns into something like

x.my_prop_set(3);

So far so good? Now, what should we do with this:

x.my_prop += 5;

Do we really want it to become this:

x.my_prop_set(x.my_prop_get() + 5);

That works in (say) Python, but in C++ operator+= is supposed to be efficient. Okay, so we allow umpteen different setter methods to handle all the assignment operators. Now what about this:

void foo(int & i)
{ i = 7; }
foo(x.my_prop);

Do we want this to work at all? How is it going to happen? With a proxy class? Those can let you down; remember std::vector<bool> ?

> They are
> often used in many languages and even some C++ extensions
> have them, but I'v e seen no remark on them.

I am not familiar with class properties in any C++ extension. Do any of the ones you know about provide good solutions to the problems pointed out above?

[About Properties]

FWIW, Microsoft's new C++ for the Whidbey release implements properties similar to the way C# does. It seems pretty reasonable.

This can already be done quite easily with scoped lock guards using the resource acquisition is initialization. The only reason Java has this IMHO language hack (and the 3-state try/catch/finaly) is that is has no scope bound destructors.
The added advantage of doing this inside the language is that it can be used custom lock types not only some primitives.

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());
}


> > Rather than specifying that information for each object
> I
> > I used, and thus potentially screwing it up in numerous
> > places, it would have saved a fair amount of time if I
> had
> > been able to apply that template to the namespace I had
> > wrapped all of those classes in.

yeah, just think of the <algorithm> header. A lot of template argument list are exactly the same.

I think templated namespaces might fit well together with Carl Daniel's proposal about class namespaces.

-Thorsten

I tried your sample with Borland's C++ Compiler, version 5.5:

#include <iostream.h>
class PropTest
{
private:
   int someprop;
   int get_SomeProp()             { return someprop; }
   void set_SomeProp( int value ) { someprop = value; }
public:
   PropTest() { cout << "Hello world!" << endl; }
   ~PropTest() { cout << "Goodbye world!" << endl; }
   __property int SomeProp = {read = get_SomeProp, write = set_SomeProp };
};
 
void foo( int & i )
{
   i = 7;
}
 
void main()
{
   PropTest pt;
   pt.SomeProp = 88;
   cout << "SomeProp is " << pt.SomeProp << endl;
   foo( pt.SomeProp );
   cout << "SomeProp is " << pt.SomeProp << endl;
}

And the output seems to indicate that it worked fine:

Hello world!
SomeProp is 88
SomeProp is 7
Goodbye world!

But that is only because I used a very simple case. If I did something more realistic, involving a calculated value, like this:

#include <iostream.h>
class PropTest
{
private:
   int seconds;
   int get_Minutes()
   {
      cout << "   --> get_Minutes()" << endl;
      return seconds / 60;
   }
   void set_Minutes( int value )
   {
      cout << "   --> set_Minutes(" << value << ")" << endl;
      seconds = value * 60;
   }
public:
   PropTest()  { cout << "Hello world!" << endl; }
   ~PropTest() { cout << "Goodbye world!" << endl; }
   __property int Minutes = {read = get_Minutes, write = set_Minutes };
};
 
void foo( int & i )
{
   i = 7;
}
 
void main()
{
   PropTest pt;
   pt.Minutes = 88;
   cout << "Minutes is " << pt.Minutes << endl;
   foo( pt.Minutes );
   cout << "Minutes is " << pt.Minutes << endl;
}

The results are:

Hello world!
   --> set_Minutes(88)
   --> get_Minutes()
Minutes is 88
   --> get_Minutes()
   --> get_Minutes()
Minutes is 88
Goodbye world!

Anyway, the moral is that reference variables in C++ throw a monkey wrench into the works. That makes sense, since you could also pass a read-only property by reference.

I think the answer is that, in addition to adding properties, the specification would also have to add some rules, such as not allowing properties to be passed by reference. That isn't an unreasonable thing, probably.

It seems like a property would have a special kind of "const-ness" (especially a read-only property).

Another thing the Borland compiler did is allow you to create and use Delphi objects in C++, but in order to do this, you are forced to always create them on the heap (with new). At first that seems really annoying and stupid, but it is better than not having the use of some handy objects. The reason I bring this up is to point out that properties would be worth having, even if some limitations were put on them.

Not wanting to pump my own sales (/sails?) - I've been hanging fire hoping one of my friends would save me from appearing to do so (eh, Chuck! ;)) - but in chapter 35 of my new book Imperfect C++ (http://www.imperfectcplusplus.com/) I show how Properties - method & field, internal and external - can be implemented in C++. It provides 100% space efficiency for all property types, and 100% space efficiency for internal property types (where the property "member" contains the data for which it acts). For external properties, it has a maximum 1-byte space cost for all property members combined, and even this can be avoided if the class has any POD type members.

It uses a ubiquitous, at least as far as the 8 compilers I have tested it on (Borland, CodePlay, CodeWarrior, Comeau, Digital Mars, GCC, Intel, Visual C++), but non-standard facility for declaring a template's parameterising class type to be a friend, as described in http://www.cuj.com/documents/s=8943/cujexp0312wilson2/.

The non-standard nature of it is a risk, to be sure, and I make no guarantees about future support for the facility, but having said that I'd be stunned if compiler manufacturers saw fit to remove it. Note that even the highly conformant Comeau compiler saw fit to add the --friendT command-line option to version 4.3.3 specifically in order to support this technique in --strict mode.

For any of you who aren't moved to dash over to Amazon and buy a copy of Imperfect C++ to read about the technique, I am currently preparing an extract that describes the basis of it for an article for February's Dr Dobb's Journal. You might also take a peek into the stlsoft_method_properties.h and stlsoft_field_properties.h files, in the latest STLSoft (http://www.stlsoft.org/downloads.html) release.

Gah!

"It provides 100% space efficiency for all property types"

=>

"It provides 100% speed efficiency for all property types"


Sorry about that ...