Talk:C++11

N3337 ≅ C++11… forever

There seems to be a tendency for editors to ‘update’ the Working Draft link to N3376 (and perhaps later documents in the future). These are drafts of C++14, not C++11. N3337 is closest to the published C++11 standard. kpschoedel (talk) 16:31, 2 November 2012 (UTC)

Alternative function syntax

This section ends with the line "The use of the keyword “auto” in this case means something different from its use in automatic type deduction."

Nothing else I read in the article suggests this is true, could we get some actual explanation? It seems like the other section of this article suggests that using auto as a method to set the return type automatically does exactly that when paired with decltype. Decltype sets the type the expression is going to return, and auto subsequently picks that up.

HacksawPC (talk) 15:37, 2 May 2012 (UTC)

You're conflating two things, which is why I specifically put that sentence there. All `auto` does is say "the return type will be specified after the function arguments". That's it. You do not have to use `decltype` with late-specified return types. This is perfectly valid:

auto SomeFunc() -> int;

No type is being deduced by the compiler; it's explicitly specified as `int`. Again, "The use of the keyword “auto” in this case means something different from its use in automatic type deduction." No type is being automatically deduced here. It's simply a placeholder for the compiler. There was even debate in the committee for using `[]` instead, as a way to unify function definitions. This was overturned, primarily for reasons of causing confusion.

The thing doing the type deduction is the `decltype` keyword, and only `decltype`. For example:

int someGlobal;
decltype(someGlobal) SomeFunc();

This does actual type deduction, but without `auto`. So no, `auto` in this use is not deducing anything.

The reason why late-specified return type and `decltype` are used frequently together is because of why you would want to specify the return type after the parameters. If you don't late-specify the return type, then this would not be possible:

template<typename T> decltype(v.func()) SomeFunc(T v);

You have to late specify the return type because the expression that `decltype` uses depends on the parameter names. And those parameter names don't exist until after the parameter name is parsed. So you late-specify the return type.

template<typename T> auto SomeFunc(T v) -> decltype(v.func());

This does type deduction, but only because of the `decltype`, not the `auto`. Korval (talk) 23:31, 3 May 2012 (UTC)

{{visible anchor}} at chapter Rvalue references and move constructors

I have changed the two following redirections:

• http://en.wikipedia.org/w/index.php?title=Move_constructor&redirect=no
• http://en.wikipedia.org/w/index.php?title=Rvalue_references&redirect=no

Before my change, theses pages was redirecting to {{visible anchor}} in the middle of the section text. Therefore, I was lost on the Article page, and I thought about a browser bug (I was expecting to see the chapter title). I noticed the {{visible anchor}} after this change. Actually, I do not think putting {{visible anchor}} in the middle of a section is a good idea. Because the reader expects to see the Article title or the section title, not to be redirected in the middle of a sentence. What should be the {{visible anchor}} usage? Oliver H (talk) 15:41, 28 September 2012 (UTC)

I had not thought of this when I had added those visible anchors. Your changes are a tremendous improvement. Thanks.

We could replace the visible anchors with plain (hidden) anchors, placed right before the section title. See Template:Anchor/doc.

Or we could move the description of rvalue references and move constructors to its own page. — Tobias Bergemann (talk) 17:29, 28 September 2012 (UTC)

use case for "final"?

Why is it necessary to declare a member function or a whole class final? I can't see any and I cannot find any rationale in the standard. --RokerHRO (talk) 21:33, 27 December 2012 (UTC)

The standard doesn't provide rationale; it simply says what the behavior is. As for rationale, it comes from the functionality. `final` stops people from being able to derive from a class or overriding a virtual function. The rationale is that you don't want someone to derive from a particular class or override a particular virtual function. Some schools of OOP thought will decide when it is a good idea to do this. Other OOP doctrines don't believe that `final` should ever be employed. Korval (talk) 16:00, 29 December 2012 (UTC)

I know that the standard provides only a few rationals for its decisions. :-( Stroustup's books provides some rationales (especially in the "D&E" which is full of rationales and proves of not working alternatives etc.) so I must wait for C++11 versions of his books ;-()

I know what finally does, but I cannot find any good example or use case where finally is necessary or at least a very good idea.

--RokerHRO (talk) 10:14, 20 January 2013 (UTC)

Stroustrup gives kind of an answer in his C++11 FAQ: [1]. Tigrisek (talk) 12:43, 20 January 2013 (UTC)

First, it's not finally; it's final. Second, as stated, whether it is a good idea or necessary is a matter of opinion. Some people don't believe it ever is necessary. Others think you should use it for any virtual function or class you don't want someone to override later. Some would argue that if your class doesn't have a virtual destructor, you could declare the class final to prevent people from overriding it and thus potentially causing problems. It's not a simple issue; the feature is there for people who want it. Korval (talk) 01:00, 21 January 2013 (UTC)

Insert section about new __func__ identifier

Would it be worth including a paragraph about the new __func__ identifier which is defined in section 8.4.1 of the standard and was (almost exactly copied) from C99 to C++11?

This is the corresponding paragraph from the standard (citing working draft N3337):

The function-local predefined variable __func__ is defined as if a definition of the form

static const char __func__[] = "function-name ";

had been provided, where function-name is an implementation-defined string. It is unspecified whether such a variable has an address distinct from that of any other object in the program.

[Example:

struct S {
  S() : s(__func__) { }             // OK
  const char *s;
};
void f(const char * s = __func__);  // error: __func__ is undeclared

—end example ]

Keilandreas (talk) 17:19, 21 January 2013 (UTC)