Any ideas for C++1y ?

Question

I know that C++0x is not out the door yet, but what would you like to see in C++1y?

---

Update: C++0x to be called C++1x :o(

Answer 1

Most probably C++0x will be C++1x, because it won't be finished in 2009.

And most importantly, I would like to lay my hands on finished, production ready C++(0|1)x :)

Answer 2

I'd like to see modules. I'm getting more sick of #includes and slow compilation every day.

Answer 3

A standard ABI (Binary interface) would be great.

Answer 4

Would be nice:

• virtual constructors and virtual copy constructors. So factories and
  cloning can be done more naturally
• multiple dispatch functions

Answer 5

inline keyword deprecated. Its almost as useless as the old "register" keyword.

(that is to say its a very vague hint at best, not that I'm against inlining).

Answer 6

I don't know if anything similar has been submitted, but I'd very much like an equivalent of typedef that defines a new type so that you would be forced to use a static_cast<> to convert from one type to another.

For example you could define a class like this :

class Person
{
public:
    // the *typedef new* is just an idea for the syntax that could be used
    typedef new std::string name_t; 
    Person(const name_t& name);

    const name_t& getName() const;

    void setName(const name_t& name);
};

And using it like this wouldn't compile

void func()
{
    std::string name("Etienne");
    Person person(name); //<-- this wouldn't compile

}

But this would

void func()
{
    Person::name_t name("Etienne");
    Person person(name);
}

This way you could be sure that the users of your class really use the typedef you intended to use.

Answer 7

I'd really like to see polymorphic lambdas. The lambdas that we get in the next Standard are monomorph only

auto intPrinter = [](int x) { std::cout << x; };
// can only print int!

Polymorph lambdas would allow for more readable code and for less duplication. No need anymore for repeated writing of type-names anymore:

for_each(a.begin(), a.end(), [](x) { x++; });

As you see, we wouldn't need to spell out the type of the parameter. An alternative syntax would be using templates

for_each(a.begin(), a.end(), template<typename T> [](T &x) { x++; });

Answer 8

There are no things I'd like added to already huge and complex language. There are plenty I'd like to see removed or redesigned :(

Answer 9

Another feature i would like to see are string template arguments. This would for example allow for static (compile-time) checking and compilation of regular expressions, file-paths and others.

An alternative would be user defined literal operator templates that accept string literals. That is, the following would be nice to have

template<char... C>
constexpr regex operator "" _regex() 
{ return compile<C...>::value(); }

regex numbers = "[0-9]+"_regex;

And it would check and compile the regex at compile time. This is currently only allowed for integer or floating point literals for the next Standard.

Answer 10

As for the language features - pretty much only modules. Well, maybe multiple dispatch as well :). I'd like to see RTTI removed, but of course it cannot happen.

As for the standard library, I'd like to see: more support for international programming (Unicode, localization readiness, calendars, etc), networking, a better IO library, more string manipulation functions (include Boost String Algorithms?), improved support for concurrency, secure integers (something like SafeInt), decimal floating point numbers, big integers. I don't think adding a GUI library makes sense, and I don't want a non-deterministic garbage collector either - even as an option.

Answer 11

I wouldn't mind seeing a standard way of dealing with time beyond the Unix Epoch. I realize that this might fall under the OS, but I'd like to see it in the standard library. (Does the standard library fall under the c++ spec? I don't know, but the issue needs to be addressed sometime soon, because it isn't too unreasonable to expect embedded systems to still be in use in 20 years or so.)

Answer 12

Here's my wish list:

• named returns. Many compilers have this, It's a fairly obvious optimisation that can be easily ignored on platforms that can't benefit from it (if there are any?)
• signatures, ala g++. these are just handy.
• kernel functions, similar to brook or cuda. without them, it is non-trivial to use any kind of parallelism besides multiple threads.
• I actually want to see more rtti features. If there was a way to iterate over a type's members, you could implement something like the DRY ORM style of database active records seen in Django or Rails, using pure C++.

and my pony:

• I'd like a standardized interface that is richer than iostreams. I'm not quite asking for GTKmm (or any other specific or nonspecific gui lib) to go into the standard, but actually, that would be just fine. This is the only one I'm pretty sure won't ever happen, though,

Answer 13

I want to see all the GC stuff that was cut out of C++0x.

Answer 14

I want more floating posting types, working with DSPs requires me to write custom assembly classes with hacky unions of floats and fixed points to get the maximum out of the hardware.

• short float (16bit float)
• float (32bit float)
• double (64bit float)
• long float (128bit float)

Answer 15

static reflection

We already small amount of reflection available in the type_traits library. I just want to see more. Essentially I'd like to be able enumerate all members and/or methods at compile time. In my mind it would look a lot like the current function traits.

I described it a more completely in my blog. I've also posted many of the same ideas to comp.lang.c++.moderated.

Just a quick list of benefits from compile time reflection

• Powerful unit testing tools
• Good intellisense for external C++ libraries (Boost). The current state of affairs is really pitiful even for Microsofts fabled implementation.
• Cross compiler intellisense libraries
• Powerful refactoring tools like those in Java
• serialization of classes
• marshalling
• network byte order swapping of complex structs
• QT's compiler could be completely implmented compile time instead of with macros and a second compile step
• there has to be a pile of others.

Answer 16

I'd like to see (optional!) statically-checked exception specifications:

void foo () static throw()
{
    throw 1; //ERROR: function marked throw()
}

template <typename T> void bar(T t) throw(auto)
  // will have a specification of every exception it might throw.
{
    return t;
}

There would have to be a whole lot of work to do here, but it would be a fantastically useful feature, and it wouldn't have all the problems that a mandatory checking framework has.

Answer 17

Replace it with D.

Answer 18

I would like to see bignums in c++ std lib. Other languges (LISP, Haskell, Python, Java, C#, Ruby...) already have it.

Answer 19

First of all, removal of C cruft. No const char* to char* cast anymore, no C-style casts, etc. Even if this means that current C++ code will have to be slightly adapted.

And a bunch more ...

• Make "foo" actually an array<char, size-known-at-compile-time>
• Remove redundant keywords (typename/class in template definitions) and redundant ways to define stuff. There should be usually one way to do something, and not two equally good ones (at least for simple stuff).
• Revamp the string handling. Strings should be encoded using Unicode, with strong conversion functions.
• Deeper runtime control. Let me reroute all memory allocations to my custom allocator, stuff like this.
• Cleaned up standard library. binary_search should be replaced with something useful, and the stream classes need an overhaul. They should be byte oriented, and not character oriented, and much simpler than they currently are.
• Reworked RTTI system, with additions to the standard library to do real introspection. At least, give me a guarantee for getting class names!
• Standard library split up into more than one namespace.
• More focus on performance. The STL should inherit some stuff from the EASTL proposal, for example, a useful allocator model. The current one is really problematic at best.
• Oh well, and of course thread pools and abstractions for parallelism in the standard library.
• fix vector<bool>

Answer 20

All this comments put together look amazingly similar to "D" programming language. Did you know that some very big C++ names are already writing articles on "D" ?

I am afraid "D" will be the end of "C++" if the famous ISO comity is not shaken and stirred and than made up again ...

Dusan (London, UK)

Answer 21

Concepts! :)

Answer 22

A standard library like the one Java or .NET offer.

Answer 23

mmm... talking about the new standard name I think if for you all 0x means an hexadecimal number, then it will be C++A or C++a but never C++0A cause this is an invalid octal number and an error compilation in C++ :)