Quote:Original post by SiCrane

Quote:Original post by Rydinare
Practicality aside, if some of the internal C++ assumptions, such as the backwards compatibility and the archaic linking model were non-issues, export would've been great. As it was, I agree export was a definite misstep.

No, the way export was specified was broken in ways that had absolutely nothing to do with backward compatibility and the linking model.

Well, I think we're going in circles. What I'm trying to say (and apparently failing at) is that export would've likely been specified differently if they could've done it fresh and in that case, it may have succeeded. Or, even moreso, an export keyword may have never been necessary.

Quote:Original post by the_edd
template aliases?!

Unnecessary, not to mention given stupid syntax.

Quote:
overloading of "auto" keyword for type inference?!

By definition unnecessary and I'm not convinced that the way that they're currently specified will be problem free.

Quote:
variadic templates (will speed up function<>, bind, etc compilation no end)?!

It will, in theory, speed up compilation for those libraries. However, until you've got a working C++09 compiler, you can't actually make a definitive statement that the compile will be faster. Integrating of new language features will increase compiler complexity and more complex compilers tend to be slower. Furthermore, the unpacking mechanism leads to increased number of instantiated templates which then means that the optimizer and linker have more work to do. Parsing might be faster, but you've simply pushed work off to the backend.

In any case, I'm currently unconvinced that the feature will be applicable to enough situations to warrant the addition to the language given the weakness of the unpacking notion. It seems that you'll largely be trading using boost::preprocessor for specifying your variadic templates for writing obtuse recursive definitions. For simple forwarding issues variadic templates might be nice, but when you try to actually do something with the arguments then you've got issues.

Quote:
inherited and delegating constructors?!

Not worth the chaos they generate with respect to the notion of a fully constructed object.

Quote:
memory model for threads!?

Meh.

Quote:
automatic virtual destructors (if at least one method is virtual)?

Ok. I'll add this one to my list.

Quote:Original post by Rydinare
Well, I think we're going in circles. What I'm trying to say (and apparently failing at) is that export would've likely been specified differently if they could've done it fresh and in that case, it may have succeeded. Or, even moreso, an export keyword may have never been necessary.

Ok, how would you keep the semantics of C++ templates and avoid the problems for separate compilation of templates mentioned in the Sutter article either with or without the export keyword? Feel free to change whatever you like about the classic linkage model so long as the end product of a program build contains a classic executable.

I firmly believe that C++ is carrying far too much baggage to be significantly enhanced without falling apart under its own weight - adding new features to the language without removing old ones or breaking backwards compatibility or legacy code is too huge of a problem. For C++XX (do people think C++09 is a realistic prospect?) , the committee should abandon all new language features, instead focus only on features that will allow legacy C++ code (i.e. all of it) to be used from more modern languages - that means a multithreaded execution model and a C++ ABI. Microsoft created the concept of interop assemblies for using COM components from .NET and then dropped support for VB6 - I don't see any reason why C++ shouldn't go the same way.

Unfortunately, the committee seems more interested in in attempting to produce a 12 legged octopus by nailing 4 extra legs onto the festering corpse of the 8 legged octopus produced by nailing 4 legs onto a dog :)

Quote:
Original post by SiCrane

Quote:
Original post by the_edd
template aliases?!

Unnecessary, not to mention given stupid syntax.

@SiCrane: Why do you say this? Ok the syntax with the "using" keyword might not be very pretty but there seem to be many people, including myself, that find this feature quite useful.

By the way, does anyone have any idea why did the committee choose this syntax instead of something more intuitive like, for example:

template<typename T1, typename T2>typedef MyClass<T1, T2> MyClass_T1<T2>;

?
The only possible explanation I can think of is that the chosen syntax is in some way easier for the compiler..

Quote:
By the way, does anyone have any idea why did the committee choose this syntax instead of something more intuitive like, for example:

template<typename T1, typename T2>typedef MyClass<T1, T2> MyClass_T1<T2>;

?
The only possible explanation I can think of is that the chosen syntax is in some way easier for the compiler..

I assume it's because typedef introduces a new name for an existing type, whereas a template alias does something very different,even if they initially appear to be conceptually similar.