
C++ 11 Approved - feydr
http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/
======
Animus7
Awesome! I've been looking forward to the day I'm no longer relying on
"experimental" C++0x support! Here's a smaller tl;dr for those who want it:

-foreach loop

-first-class rvalue ("temporary") types

-lambda functions + closures

-implicit typing (auto keyword)

-decltype(), getting "declared type" of any expression

-variadic ... templates

-expanded STL -- incl. threading and RNG's

-construction from C-style initializer list

-Unicode literals

-enum class that doesn't auto-decay to int, enums with configurable base type

-explicit strong nullptr constant; no more NULL macro nonsense

The rest of the stuff is (in my opinion) less general/noteworthy.

~~~
vog
_> explicit strong nullptr constant; no more NULL macro nonsense_

What is the point of this? C++ defines the null pointer to be always 0. So I
never needed the NULL macro in C++ anyway, as I'm allowed to simply type 0
instead.

In how far is that new nullptr constant preferable to writing simply 0?

~~~
Someone
The standard example is:

    
    
        void f(int x);
        void f(char *x);
        ...
        f(0);  // calls void f(int)
    

That may seem contrived, but you may not know of the f(int) overload,
especially in combination with templates.

NULL, if #define'd as (void *)0, prevents that error.

~~~
pmjordan
NULL is actually #defined to 0 in C++ as void* is not implicitly convertible
to any pointer type as it is in C. So unlike in C there has been no safety in
using NULL. Until now.

------
malkia
I wonder why the C++ body does not consider things like
reflection/introspection more important than the stuff they came up with.

All that is needed is just an (optional, like RTTI) way to simply explain in
binary format as part of the genereated binary information related to
structures, types, functions, global variables, etc.

For example GUI in some external format (json, xml, do not matter) that has
it's signals/actions/events encoded as simple names, where at runtime you can
map them to actual C++ code (Objective C has it, Java I think, .NET, etc.)

This would reduce the time writing serializers, deserializers, and such. Make
it optional (again like RTTI or exceptions) - but make it there for machines
which can afford it (PC, Unix, OSX, and even mobile devices).

Why this is important? You would find 100+ libraries trying to solve this
simple problem in plethora of weird ways - such as gcc-xml, OpenC++ parser,
boost, etc, etc, etc.

And better preprocessor.

~~~
pmarin
_I wonder why the C++ body does not consider things like
reflection/introspection more important than the stuff they came up with._

The main advantage (and probably the unique) C++ has over other system
languages like Objective C is the "near to C" performance and it does it
maintaining the runtime at the minimum doing all his _thing_ at compiling
time. reflection/instrospection requires a more complex and slowly runtime.

~~~
Jach
Are you saying there's no way to make it optional and, when it's not being
used, maintain the same runtime speeds? Virtual functions are "costly" too,
but C++ has them and it's considered poor form to not declare your destructor
virtual.

~~~
copper
> Virtual functions are "costly" too, but C++ has them and it's considered
> poor form to not declare your destructor virtual.

It's a bit more subtle than that: a virtual destructor is only required when
the class, or its base classes, already have another virtual function (and
it's only really needed if another class inherits from it. hmm.) At that
point, a virtual destructor doesn't add any more cost over and above the
virtual function that's already defined.

~~~
malkia
But not putting one, using foreign code base might get you in trouble
(resource leaking, not de-initializing certain piece of the parent, threads
not closing, etc.).

This would've been prevented if destructors were always virtual.

My take is that if the compiler cannot make the decision, but it's left to
you, in this case it's better to always have the virtual destructors ON.

The problem is more visual than analytical - you would have to dig through the
whole hierarchy in several files to understand whether you need to put a
virtual destructor or not. Compiler/Linker/some post-proc tool should be
better at that job. It already has all that information.

~~~
copper
Hm, I'd rather pay the cost of having to add a virtual keyword in a few places
(easily found using the equivalent of g++ -Wnon-virtual-dtor, and you _do_
ship C++ code that is warning-free, right? :) rather than have to deal with up
to eight bytes extra per instance in all my classes.

~~~
malkia
Thanks for the hint!

Actually I did not know about this option. I've just fixed such bug in one of
our tools, written using wxWidgets for Windows. Have to check MSVC on this
option.

At the same time a coworker was able to get the Xbox360 analyze thing and it
worked finding suspicious stuff in the runtime code.

But we have only the professional version for PC :(

~~~
DCoder
In MSVC, this warning's off by default: [http://msdn.microsoft.com/en-
us/library/wzxffy8c(v=VS.100).a...](http://msdn.microsoft.com/en-
us/library/wzxffy8c\(v=VS.100\).aspx)

------
5hoom
I say this is great news. A lot of the new stuff really does make C++ both
nicer to use and a good deal safer, and it will be interesting to see more
boost-y style of C++ become widespread.

Also glad they waited and went with C++ 11, and not C++0x which sounds like a
l337 speak swearword.

~~~
beza1e1
Die original idea was to replace the "x" with the right year. Since 2009
(C++09) didn't happen, it is C++11 now. Geeky would be hex: C++0B

~~~
notgeekyenough
If you wanted to write a year in hex, using the value mod 100 seems a weird
way to do it. The hex year is 0x07DB, so if anything it would be C++DB. Or
perhaps the first 3-4 hex digits of the Unix time would make sense - C++4E46.

------
huhtenberg
So

    
    
      decltype
    

instead

    
    
      typeof
    

Damn... though not really surprising. To me this exemplifies C++ - it does
reasonable things, but in that slightly ass-backwards way that makes it
annoying... like a light switch that is installed upside down.

~~~
queensnake
I think it's because existing compilers (eg GCC) used typeof already for
experimental implementations, so the standard had to avoid it. Same as with
hashmap, hashset -> unordered_map, unordered_set.

~~~
scott_s
Yes, exactly. The natural words for things are already used as extensions, and
they want to avoid clashes.

------
t413
For those who are curious: <http://en.wikipedia.org/wiki/C%2B%2B0x>

Huge page though, needs a tl;dr of changes.

------
shuaib
Waiting for TC++PL 4th Ed. now.

~~~
queensnake
Heh, probably the books are ready to go, they've just been waiting for the
official word. There's be new editions of all the old standards: "Yet More
Effective C++", "Exceptional C++11" ... I can't wait :)

------
ilitirit
When will we see compiler support?

~~~
ori_b
Now -- at least for the big features, it's already implemented in GCC and
Clang. I have no idea about MSVC++.

~~~
DCoder
VC++ 2010 supports a lot of them:
[http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-...](http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-
language-features-in-vc10-the-table.aspx)

I've gotten into the habit of auto'ing most variables nowadays, it's quite
convenient not having to type

    
    
         LongTemplateName<ClassName> variable = LongTemplateName<ClassName>::StaticCollection.Find(something);

