Bjarne offers a sneak peek at the next version of standard C++ ("C++0x") which should be complete by 2009.

http://www.artima.com/cppsource/cpp0x.html

I'd like to moderate the proposed aliasing syntax by using as instead of "="

template<class T> using Vec = vector<T,My_alloc<T>>;

becomes

template<class T> using Vec as vector<T,My_alloc<T>>;

REASONS (not in any order of merit)
1) as is already used for aliasing in SQL, a familiar use to many developers

2) as is more evocative of aliasing, both in English meaning and as a visible contraction

3) = is already used frequently for assignment and initialisation. I have encountered confusion amongst c++ programmers of widely varying experience as to the implications of using = in initialisation and how different compilers choose to use copy ctors or not. This will add to the confusion.

4) Semantically, this is a very different form of identifier binding to any other form of assignment. The closest equivalent in current C++ is #define of a macro which does not use = but relies on whitespace separation. I don't think whitespace alone is appropriate here.

CAVEAT
Whilst this means as becomes a reserved word, hopefully it can be implemented as such only in conjunction with a using statement. At worst, it is a two-letter word and so less likely to clash with existing code.

We (the evolution working group of the ISO standards committee) looked at several syntactic variants for expressing template aliases before settling on the version I presented in this article. I think we found is pretty good and it did help us think more clearly about the problems than we had managed to before using more convoluted suggestions (on the WG21 site, you can find a series of papers discussing the problem under the heading "template typedefs"; the latest is posted on my home pages: http://public.research.att.com/~bs/WG21.html).

The closest equivalent to template aliases is typedef rather than #define: We are talking about a mechanism that preserves syntax, type, and scope rules.

"as" would be a keyword and (like any short and nice word) will appear as an identifier in *many* existing programs.

My (long and bitter) comment is here:

http://slashdot.org/comments.pl?sid=172797&cid=14384078

I apologise about it, but I just can not accept the fact that C++ could be so much better, but it is not. C++ has excited me more than any other language, but has also disappointed me just as much.

By the way, there is an error in the article's code here:

Original text:
-----------------------
The difference here is that we don’t have to mention the type of the iterator: auto means “deduce the type of the declared variable from the initializer”. Such uses of auto are far less verbose and also less error- prone than current alternatives, such as:

for (vector< double, My_alloc<double> > p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;
-----------------------

p should actually be declared as vector< double, My_alloc<double> >::iterator

It's interesting and funny that the error is in the code that you point out is more error-prone. I don't think the error was intentional ;)

Another syntax that is (IMHO) a little "easier" on the eyes would be:

template<class T> template Vec = vector<T, My_alloc<T>>;

It replaces "using" (which is too generic) with "template". It is better in that is emphasizes that the result (Vec) is also a template.

It seems that the 'template typedef' with 'using' re-orders the new name to be first, instead of the traditional typedef syntax which puts the new name last... I'm not fond of the use of = here, either.

I think I would rather see something like:

template<typename T> typedef vector<T, My_alloc<T>> Vec;

Although I'm no expert on compiler development and there might be other technical challenges or conflicts that make this impossible.

It was not deliberate.

Sorry.

Yes, it supports my point in a somewhat weird way.

(Actually I had found and fixed that problem, but Artima got caught by a versioning problem with my text).

We tried with "typedef". We found that to be a source of subtle problems. It is much easier to think clearly when the name being declared is first or last. (I am no fan of the convoluted C declarator style syntax - for example see "The Design and Evolution of C++")

-- Bjarne Stroustrup: http://www.research.att.com/~bs

I'm always slightly amused that people *still* believe GC is not available in C++. I've read your "Proposal to Acknowledge that Garbage Collection for C++ is Possible" from '96 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0932.asc ), and I know that the committee has tried to sanction the idea of garbage collection over the years.

Why is the new proposal needed? Or is it a requirement that a standards-conforming compiler have a garbage collecting implementation available on demand?

> I'm always slightly amused that people *still* believe GC
> is not available in C++. I've read your "Proposal to
> Acknowledge that Garbage Collection for C++ is Possible"
> from '96
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0
> 932.asc ), and I know that the committee has tried to
> sanction the idea of garbage collection over the years.

and there are good garbage collectors "out there". C++ is my favorite garbage collected language because it produces so little garbage.

> Why is the new proposal needed? Or is it a requirement
> that a standards-conforming compiler have a garbage
> collecting implementation available on demand?

To clarify "optional"
To exactly define what it means for an object to be alive
To give the programmer a way of knowing whether GC is happening
To define what "delete p;" means whan a garbage collector is running
...

That said, please note that GC isn't a panacea and isn't for every program.

--- Bjarne Stroustrup; http://www.research.att.com/~bs

> It seems that the 'template typedef' with 'using'
> re-orders the new name to be first, instead of the
> traditional typedef syntax which puts the new name last...
> I'm not fond of the use of = here, either.
>
> I think I would rather see something like:
>
> template<typename T> typedef vector<T, My_alloc<T>> Vec;

No, I think the "using" keyword is much better, and could be treated as a general way to import symbols and also create new symbols:

using vec = vector<string>;

And yes, this would also elliminate 'typedef':

typedef int array10i[10];
<==>
using array10i = int[10];

I would be also glad to see it used for importing global variable names, while global variables usage (inside a function) should be disallowed without prefix. That is

g_global_variable = 0; // ERROR
::g_global_variable = 0; // ok

But:

using g_global_variable;
g_global_variable = 0; // ok

This is somewhat similar to importing global variables in Tcl.

> and there are good garbage collectors "out there".

Hmm... maybe, but I think GC is such a kind of feature that it better have language support. Like exceptions.

> > Why is the new proposal needed? Or is it a requirement
> > that a standards-conforming compiler have a garbage
> > collecting implementation available on demand?
>
> To clarify "optional"

First of all, it needs to be decided whether the type definitions should be strictly bound to their memory management issues, or they can be separate, while the storage is used directly by using appropriate, say, syntax.
So far the garbage collectors use the second method because they simply don't have another choice.

And I disagree that you can just "use garbage-collection for any type". The ability of an object to be garbage-collected or not should be a treat of its type.

This is moreover important that the manual memory-managed objects are simultaneously guaranteed to be freed in strictly specified places. Removing an object by GC does not occur in specified moment. This, for example, implies that the GC'd objects must be trivially-destructible because many "typical" destructors try to do something in other objects.

If it is strictly stated that garbage-collected and non-garbage-collected are separate types, then the garbage collector can be optional and will not make additional costs for those, who are not interrested with it.

Others, on the other hand, point that the environment should be either fully garbage-collected or not. With such statements, the GC is simpler to be implemented. However I can't imagine, how SUCH C++ would compose with its existing libraries.

> To exactly define what it means for an object to be alive

When accessible from other alive objects ;). Of course, this is a complicated thing, but I think GCs today are mature enough and some reasonable method can be developed for C++.

> To give the programmer a way of knowing whether GC is
> happening

Is there a way to inform a user that exception throwing is happening in any other way than by caching the exception?

> To define what "delete p;" means whan a garbage collector
> is running

Nothing. Unless 'p' points for an object, which is of a garbage-collected type. This would be prevented at compile time, if GC had a language support.

> That said, please note that GC isn't a panacea and isn't
> for every program.

I saw only few situations, when GC would be suitable. A lot of examples from Java's uses for GC (for example, to return a large object by reference) can be done in C++ without GC (this one, for example, with auto_ptr).

/* [Stroustrup] To exactly define what it means for an object to be alive

[Malecki] When accessible from other alive objects ;). Of course, this is a complicated thing, but I think GCs today are mature enough and some reasonable method can be developed for C++.
*/

The current "best practice" (aside from linking to a GC) is to use smart pointers to determine whether a reference from another object should be considered strong, and which should be considered weak.

In truth, this isn't usually necessary, as using STL containers can handle many of the memory management pitfalls. And using stack objects can lead to determinism (which is sadly lacking in Java). But that's what Stroustrup has been preaching for over a decade.

What about more advanced features, like "import"? Putting templates into headers is not would I want to do. On Slashdot site people are asking for other features that are interesting for me too: Vtable manipulation, static virtual, properties, reflection. I would also like to see G++ signatures back - not everything has to be a template. Closures are also nice, but they will require GC, because otherwise it will be difficult to track all internal objects and clean them up.


And now - standard socket and threading libraries.