Talk:C++11

{{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)

Incorrect example for regular expression.

It seems to be incorrect.