Update on the C++-0x Language Standard

Update on the C++-0x Language Standard

  • Comments 20

Hello: the standards body that controls the C++ language (SC22/WG21) is in the process of revising the C++ language – this new revision of the C++ language, which is currently known as C++-0x, should be finished and approved by the end of the decade. As part of this process at the recent meeting of this committee (near Oxford, England) several new language features were added to the current Working Paper for the C++-0x Standard.

 

New character types in C++

 

This adds the keywords char16_t and char32_t as well as u”…” and U”…” and u’<char>’ and U’<char>’ literals. Together these new language features give a user a way to encode a 16-bit (i.e. UTF-16) string literal/character constant and a 32-bit (i.e. UTF-32) string-literal/character-constant. The proposal also includes some library functionality.

 

Template Aliases

 

This feature has been around for a while and was finally approved for inclusion in the C++ Standard. It allows for code like the following:

 

#include <vector>

template<typename T>
class MyAllocator {
};

 

template<typename T>
using MyVector = std::vector<T, MyAllocator<T>>;

 

MyVector<int> vec;

 

Note: those amongst you with sharp eyes might notice that the nested template argument list in the example above ends with ‘>>’ instead of ‘> >’ this is because one of the first changes to the C++-0x Standard was to get rid of the need to insert whitespace between the nested ‘>’ terminators when closing multiple template arguments lists.

 

Sequence Points Revised

 

This shouldn’t actually change anything in the C++ language it just provides clearer wording – it gets rid of the term “sequence point” and instead describes an operation A being sequenced before an operation B (i.e. the evaluation of the arguments of a function call are sequenced before the execution of every expression or statement in the body of the function) or being un-sequenced (i.e. the evaluation of the different arguments of a function call are un-sequenced wrt each other).

 

It is hoped that this paper will lay the foundation for the future C++ memory model work – especially the concurrency aspects. The should review papers and proposed wording on the memory model and concurrency at the upcoming meetings.

 

Variadic Templates

 

This was the biggest feature that was added this time around. It allows for code like the following:

 

template<typename... Mixins>

class X : public Mixins...{

public:

   X(const Mixins&... mixins) : Mixins(mixins)...

   {

   }

};

 

If you specialized this class with say:

 

class A { };

class B { };

class C { };

 

X<A, B, C> x;

 

Then the compiler will generate the following specialization:

 

class X<A, B, C> : public A, public B, public C {
public:
   X(A const& __a, B const& __b, C const& __c) : A(__a), B(__b), C(__c)

   {

   }

};

 

This feature has a big impact on class templates like tuple and according to Doug Gregor it can lead to a huge compiler-time performance boost – as the compiler now only has to process one class template instead of N (where I believe for tuple N is usually 20). One unintentional side-effect of this feature is that it makes the following well formed:

 

class<typename… Types>

struct X {
   void f(Types......);

};

 

Yes – that is six ‘.’ in a row J.

 

As this feature was approved the Library Working-Group went ahead and updated the Library sections of the Working Paper to make appropriate use of Variadic Templates.

 

Allow sizeof to apply to non-static data members

 

Currently the C++ Standard does not allow the following:

 

struct S {

   int m;
};

 

sizeof(S::m)

 

This featurette makes such code legal.

 

Generalized Constant Expressions

 

This feature was almost approved but at the last minute Core decided to withdraw it. A Generalized Constant Expression is something like the following:

 

constexpr int square(int x)

{
   return x * x;

}

 

This feature really helps in situations (like bitmasks) where the result of the expression is not strictly a constant expression because, for example. it involves a cast; or for cases where a function call is required and thus turns a static initialization into a dynamic initialization (Note: I suspect that Visual C++ would currently convert these dynamic initializations back into static initializations).

 

The problem that came up is that as these are constant-expressions they are valid as non-type template arguments but as they are also functions there use could require a compiler to do overload resolution during template-argument deduction. This is very similar to core issue – 339 which deals with function calls within sizeof expressions. It was decided that Core would hold off on approving Generalized Constant Expressions until this issue is resolved – which we hope to do at the next meeting.

 

The next meeting of SC22/WG21 will be in Toronto in July. At this meeting it is hoped that the committee will start to approve some of the larger changes to the C++ language: this includes features like concepts and the memory model/concurrency proposals. Hopefully after the Toronto meeting I’ll be able to update you on the further progress of the C++ Committee.

 

Jonathan Caves

  • Nice features. Since we are in the Visual C++ blog, i suppose this standard will be implemented faster in VC++ than the previous standard. At least, I hope so. :-)

    The character types were sorely missing (wchar_t didn't cut it) and variadic templates are really cooooooool.

    Other features I long for are foreach and auto (automatic type deduction)

  • Oh, i forgot.

    Is there any plans for C99 support?

    I know C99 has some weird features (tgmath and new meaning for static) and others that conflict with C++ (clog, _Bool), but there are some really useful cleanups there. For example: snprintf (slightly different than VC++'s _snprintf), declarations allowed after statements (just like C++), better aggregate initialization, VLAs, new math rounding functions and other library improvements.

    /* I guess that long long, "//" comments and trailing comma in enum declarations are already supported. */

  • Does the next version of Visual C++ implements this part? or should we wait till ISO release the laguage Specification at the end of this decade?

  • Oh brother, guess we have to wait _yet_ another decade:

    * to add 24-bit chars, char24_t "aaa"24

    * get rid of that short, long, and long long crap

    * bool constants, 0z11011101

    * macros that are type safe, #macro foo( int x, float x)

    * standardized way of disable up-casting; NO doubles for you Mr. PS2

    * standardized & automatic __FUNCTION__

  • Mr Pohoreski, aren't templates /all about/ being typesafe macros?

    But I agree on __FUNCTION__ and 0z01010101 bit constants.

  • Long time ago I have read about something like auto typing such as;

    float a = 0.12f;

    autotype b = a;

    and b gets the type of a automatically , it would help much when writing iterators;

    vector<int> a;

    -vector<int>::iterator it = a.begin();

    instead

    +autotype it = a.begin();

    it would have been much nicer ...

  • Long time ago I have read about something like auto typing such as;

    float a = 0.12f;

    autotype b = a;

    and b gets the type of a automatically , it would help much when writing iterators;

    vector<int> a;

    -vector<int>::iterator it = a.begin();

    instead

    +autotype it = a.begin();

    it would have been much nicer ...

  • I'll address some of these comments:

    C-99 - we have added support for 'long long' and variadic macros: we'll add more support for other features once there is enough customer demand (and up until now there has been very little).

    auto, foreach, and __FUNCTION__ - these features are still under consideration by the C++ Committee: once they are in the Standard we will look at implementing them.

  • Nice!

    Michael, what do you mean with __FUNCTION__?

    Is it the same as C99's __func__?

    Ahmet, autotype is going to be spelled "auto" (reusing the keyword). I really look forward to using this feature with iterators and other complex types!

    It seems that this blog post is more up-to-date than this page:

    http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2228.html

    Since there is no mention about the withdrawal of "Generalized Constant Expressions".

  • Cool, variadic macros are in VC++2005. I hadn't noticed them, but now that i know they are implemented it is likely that i will start using them.

  • Yet other features i forgot to mention:

    stdint.h and inttypes.h

    Fortunately, C++ has equivalents for them in boost :-)

    And what about TR1?

    Will we be able to use TR1 libraries before the next standard is complete?

  • Hi

    How can I post message from one class to another? In detail, suppose I have class-1 which contains a user-defined message (say WM_OVER) and its corresponding function. I have another one class (say class-2). From class-2, by simply having reference to class-1, can I post/send the message (WM_OVER) so that the corresponding function in class-1 will be invoked?

    MyClass1.h

    ----------

    CPP / C++ / C Code:

    #include "MyClass2.h"

    class class1

    {

    ......

    ....

    BEGIN MESSAGE_MAP

    OnMessage(WM_OVER,fun_in_class1)

    END MESSAGE_MAP

    .......

    void fun_in_class1()

    {

    ....

    }

    void call2class2()

    {

      class2 obj_of_class2;

      obj_of_class2.fun_in_class2(this);

    }

    };

    /***end of class-1****/

    MyClass2.h

    ---------

    CPP / C++ / C Code:

    class class2

    {

    ...

    ...

    ..

    void fun_in_class2(class1 &obj_of_class1)

    {

    obj_of_class1.PostMessage(WM_OVER,0,0);

    }

    };

    /***end of class-2****/

  • Hey, did you forget rvalue reference and std::move? IMHO,  that is the single-most important feature. I hope that will be part of the standard

  • The Microsoft compiler creates a warning when using "this" in a constructor's initializion list.

    Is this because of a standards issue, or what exactly IS the issue?

    I have rummaged around online for a sufficient amount of time to find some information on this question.  I guess I am looking for answers in all the wrong places.

    Any help would be appreciated.

  • [John (Jay) Meyer]

    > The Microsoft compiler creates a warning when

    > using "this" in a constructor's initializion list.

    > Is this because of a standards issue, or what

    > exactly IS the issue?

    While unrelated to Jonathan's blog post, I can answer this.

    C4355 exists for a simple reason: paragraph 12.6.2/8 of the C++ Standard. It is okay to call member functions of an object under construction in the constructor's body (inside the braces). However, during the initialization of bases and members (inside the init list, before the opening brace of the ctor body), calling member functions of the object being constructed results in undefined behavior.

    In an init list, passing the "this" pointer to a base or member constructor makes it very easy to violate 12.6.2/8. Therefore, the compiler emits a warning.

    [Sohail]

    > Hey, did you forget rvalue reference and std::move?

    > IMHO, that is the single-most important feature.

    > I hope that will be part of the standard

    You're in luck! Rvalue references and move constructors have already been integrated into the Working Paper (see ikk's link to the N2228 paper above). This means that, barring catastrophe, they will be a part of C++0x.

    In his introduction, Jonathan explained that he was describing only those features added to the Working Paper in the most recent Committee meeting.

    [ikk]

    > And what about TR1?

    > Will we be able to use TR1 libraries before the

    > next standard is complete?

    A Microsoft Connect bug was filed about adding TR1 to Visual Studio 2005 and Orcas. Please read Martyn Lovell's response here:

    http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=170831

    Summary: Although TR1 will not be in Orcas RTM, "We will definitely be revisiting TR1 in future versions."

    --

    If anyone has further questions, feel free to E-mail me.

    Thanks,

    Stephan T. Lavavej (stl@microsoft.com)

    Visual C++ Libraries Developer

Page 1 of 2 (20 items) 12