Talk:C++11/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Evolutionary process?

Programming languages do not use an evolutionary process to develop. Evolution has come to mean that very small accidental changes get selected by spontaneous natural processes, and those "accepted" accumulate in time making up for development on very large timescales. In sharp contrast, in the case of C++ people suggest changes (which are hence not at all accidental), and the Standards Committee selects (so the selection process is not at all spontaneous). If there was no Standards Committee consisting of authoritative people who are in a position to make decisions, C++ would obviously not be the language as we know it today. While biological evolution has been debated ever since it was first conjectured, programming languages obviously do develop, so the parallelism is simply inadequate from this point of view as well. I will reformulate the sentence in the next few days to something like a "gradual development by feedback". —Preceding unsigned comment added by Wolfsson (talk • contribs) 17:51, 8 April 2010 (UTC)

Are you kidding? Evolution is an English word. And English, being a context-sensitive language, allows words to take on different meanings in different contexts. Like evolution. The word "evolution" means "change over time;" that's all. In the biological context, it refers to the change in genetic frequency in populations suffering environmental attrition. In this context, it is a perfectly acceptable word. Korval (talk) 01:50, 9 April 2010 (UTC)

According to Dictionary.com "evolutionary" means basically two things: (1) developmental -- if this is what we mean then the present sentence is equivalent to "programming languages use a developmental process to develop", an obvious redundancy. (2) of, pertaining to, or in accordance with a theory of evolution, esp. in biology---this meaning being inadequate according to my previous explanation. So, either of the two meanings makes the sentence inadequate---of course what you say about context-sensitivity is true, but it means that the meaning is selected from a pool of available meanings according to context. However, if neither of the meanings fits, the sentence needs to be reformulated. --Wolfsson (talk) 06:36, 9 April 2010 (UTC)

No, actually, according to Dictionary.com, "evolutionary" also means "pertaining to or performing evolutions." They provide 10 definitions of evolution. The one used here is #4, "a process of gradual, peaceful, progressive change or development, as in social or economic structure or institutions." So the word is perfectly valid, as this clearly explains how the C++0x specification is being defined (especially the "gradual" part; WG21's got that down pat).

What amuses me is the fact that we're even having this conversation. Because if the word offended you so much, you could have changed it and almost assuredly nobody would have noticed or objected. Yet you felt the need to write an entire 3 paragraph essay on why it was inappropriate. So why the discussion? Korval (talk) 03:51, 10 April 2010 (UTC)

The C++ standards committee is divided into three subgroups. The Core [language] Working Group, the Library Working Group, and the Evolution Working Group. The latter is headed by Bjarne Stroustrup himself, and is responsible for dealing with proposals that seek to add new features to the language - as in "evolving" the language, the way I see it. decltype (talk) 06:57, 10 April 2010 (UTC)

Words are important: they can even make you believe lies. I agree that some of the older and especially the greco-roman meaning ("unrolling"/"unfolding") of the word "evolution" would be appropriate here, but these are not dominant. Because of the biological meaning the word leads to false inferences of the form: "Well, programming languages do evolve, don't they: then probably there is evolution in biology as well!"--Wolfsson (talk) 14:57, 10 April 2010 (UTC)

Oh, now this discussion makes sense. You're one of those anti-evolution people. And you think that the more the word "evolution" gets used outside of biology, the more people will accept biological evolution as well. So you try to confine the use of the word to as few places as possible, on some delusional belief that this will somehow challenge the evidence for biological evolution.

See, if you had just taken the word out without making a big deal over it, I'd likely have just let it pass. However, anti-science is one of my personal pet-peeves. And coupled with Decltype's point about the Evolution Working Group, I'm afraid I'm going to have to roll back your change. Though it did clue me into some odd grammar in the surrounding sentence. Korval (talk) 21:51, 12 April 2010 (UTC)

Just a few concluding remarks because this would lead far from here—but we can continue on my talk page if you like. As you have very sharply pointed out, I'm indeed rather anti-scientistic and anti-evolutionist, to which you may add that I have been a quite successful scientist for quite some time—so I know much more about science than the 99.9...9% of people, who merely believe what they are told. I'm sure there are many for example who sincerely believe that there is analogy between (the conjectured) biological evolution and the "evolution" of C++ —maybe even those who chose the name Evolution Working Group. That's why I deemed imortant in the first place to point out that this is not the case.

Two short reactions on what you said: (1) There is of course no as indeed cannot be any evidence for evolution—in the sense of a species transforming into another. (Not counting viruses which do not really form species.) (2) I am not "one of those" whom you probably mean because the real alternatives to evolution are not creationism or something like Intelligent Design. These are the ones that get some publicity since they are relatively easy to discredit.--Wolfsson (talk) 18:00, 13 April 2010 (UTC)

If I continue to assume that you are not going off-topic here, then it seems that I have to accept the logic that your discredit the use of a word because you disbelieve what it indicates. But anyways, Merriam-Webster defines the word FIRST as a synonym of derive (before even mentioning its biological meaning). That has nothing to do with natural evolution. Merriam-Webster also explains the word as develop. Both derive and develop fit well into the context. Kxx (talk | contribs) 20:31, 13 April 2010 (UTC)

I thinking linking the term Evolution_(term) will help clear up any disambiguity, and clarify that the word does in fact have more than one meaning and the wikipedia article for evolution only references one of those meanings. -S! —Preceding unsigned comment added by 71.246.211.190 (talk) 17:27, 25 June 2010 (UTC)

Neutrality of article

The article seems bereft of criticism of the new features. I can assure you that there are alternative points of view on the standard to, this will solve all of C++'s problems.</strawman> ᛭ LokiClock (talk) 10:07, 16 May 2010 (UTC)

Quoth, In Standard C++ there are restrictions on what types of objects can be members of a union. For example, unions cannot contain any objects that define a non-trivial constructor. Many of the limitations imposed on unions seem unnecessary, so in the next standard all restrictions on the types of members of unions will be removed, with the exception of reference types. These changes will make unions easier to use, more powerful, and much more useful.

I think it is merely a matter of no~one having written those criticisms. The above quote could be tightened somewhat, why don't you go ahead and either propose a change or just do it? And then remove that "disputed" plate, please. Esben (talk) 10:52, 16 May 2010 (UTC)

While I do agree that the passage you quoted does seem slightly biased, non-fact based, and ambiguous (and have since replaced it with more concrete language), I don't see how this applies to the article as a whole. The article itself does not claim that anything will "solve all of C++'s problems;" most of the sections are nothing more than a more readable version of the current C++0x proposal documents. Each feature solves only what it claims to solve, and they certainly and irrefutably do that. Variadic templates will allow templates to take arbitrary numbers of arguments; the article makes no claim that it make the programmer's life better or anything of that nature.

If you believe that these facts are in dispute, you will need to do as Esben suggests and provide references that show that these facts are in dispute. Korval (talk) 03:38, 17 May 2010 (UTC)

First of all, the burden of proof rests on the claimant, so I need under no circumstances to provide references to discredit a fact. Secondly, the view that they solve X problems is support for the addition, whereas there is not even a general statement to the effect of, "some people feel that the addition of features to the language is unnecessary," much less criticisms, of the necessity or else, of each addition. I got the impression of a strongly biased article from the whole of it, and then scanned the article for a quote to illustrate what I meant. I did not read the Unions section and then say "by golly, this article is biased!" Please don't ask me to remove a neutrality template before the issue has even been fully discussed. ᛭ LokiClock (talk) 11:52, 17 May 2010 (UTC)

I just googled "criticisms of C++0x." This first result should provide some ideas on what can be addressed in the article. ᛭ LokiClock (talk) 11:54, 17 May 2010 (UTC)

Are you seriously claiming that undergraduate's lolcat-ridden blog post is a high-quality reliable source? —Korath (Talk) 13:17, 17 May 2010 (UTC)

No, I'm saying obviously no one's looked for criticism of the standard or they would have easily found it. ᛭ LokiClock (talk) 17:09, 17 May 2010 (UTC)

Thanks for pointing out that section; if you can identify other passages with similar NPOV issues and either correct them or flag them, that would be greatly appreciated. Authoring a well-sourced criticisms section would also be welcomed. But flagging the whole article for NPOV isn't specific enough to let anyone productively address your concerns. --Sacolcor (talk) 16:44, 17 May 2010 (UTC)

I'll post them as I find them. My main concern is the lack of said criticism section, because thats what I came to the article looking for. ᛭ LokiClock (talk) 17:09, 17 May 2010 (UTC)

• A: However, the list of rules in C++03 is overly strict.
• B: As in Mr. Firstresult, the means of achieving a type safe NULL pointer constant and the effects doing so has on the language can be questioned. Such a questioning view is not represented. ᛭ LokiClock (talk) 18:06, 17 May 2010 (UTC)

I don't have time at the moment for a full scan of the article, and again the main problem is what isn't there, not was is, so I'm gonna tie up my part of this with a birdfeeder if that's alright with you all. ᛭ LokiClock (talk) 03:00, 18 May 2010 (UTC)

I removed this section because it was empty, without reading this page. (Sorry about that; I should have at least checked to see if it was added recently before removing it.) Someone pointed me to this conversation, so I restored it for now. Nevertheless, it seems silly to have an empty section sitting there with an "expand this" tag, so if it's still in that state in a week or two, I'll probably remove it again unless there's consensus here against that. (Of course, if it's filled out with cited objections, I'll leave it.) EvanED (talk) 19:24, 26 May 2010 (UTC)

I spent some time looking for criticism the other day, but couldn't come up with anything from reliable sources. Keeping WP:DUE in mind: If a viewpoint is held by an extremely small (or vastly limited) minority, it does not belong in Wikipedia (...) in determining proper weight, we consider a viewpoint's prevalence in reliable sources, not its prevalence among Wikipedia editors or the general public. Unless reliably published criticism of C++0x can be shown to exist, the article should not have a criticism section. decltype (talk) 05:23, 28 May 2010 (UTC)

I agree, but also don't see any need to rush the removal; it's not really hurting anything. How about we wait until 18 Jun 2010 (1 month after the section was added)? That should provide adequate time for someone to research and write the section if the material for it is out there. If it's still devoid of sourced content at that point, we take it out. Sound agreeable? --Sacolcor (talk) 18:28, 1 June 2010 (UTC)

Opaque Typedefs

As far as I remember Opaque Typedefs were on the plan for C++0x for some time. But they neither appear in the descriptions of the new features, nor in the section containing the abandoned features. I'd appreciate if anybody with appropriate knowledge could amend that. Schabi.de (talk) 11:49, 9 July 2010 (UTC)

Can't find it in N3092. Probably the idea has been dropped. Kxx (talk | contribs) 13:46, 9 July 2010 (UTC)

The proposal was in N1891 and n2141. It was dropped in early 2007. --Sacolcor (talk) 21:44, 9 July 2010 (UTC)

I do not think that this feature has the necessary notability to be included in the article. Being dropped rather early in the standardization process puts a big question on its importance. A good number of features were reviewed and abandoned. This article is not to be littered with every single one of them. Kxx (talk | contribs) 20:20, 15 July 2010 (UTC)

To be honest, for me, opaque typedefs would be the only reason to update to the new version. But maybe I'm biased. Schabi.de (talk) 20:53, 22 July 2010 (UTC)

I should have been clearer that by importance I meant importance to the article. It is not about how great your favorite feature is. It is about notability. Kxx (talk | contribs) 15:17, 23 July 2010 (UTC)

Naming style in code samples

Stroustrup in his book 'Programming -- Principles and Practice Using C++' (pages 76-77) suggests to use underscore as word separator in multi-word identifiers/functions and to use first capital letter style only user-defined types. Because Stroustrup has most influence guiding the development of C++, shouldn't we use this scheme in the article, as it's indeed about standard of C++? 1exec1 (talk) 12:43, 5 August 2010 (UTC)

Also, usage of using namespace std; is strongly discuraged.1exec1 (talk) 13:27, 5 August 2010 (UTC)

'virtual void f() final;'

In the section "Explicit overrides and final" there is the line

virtual void f() final;

I think 'virtual' and 'final' are contradicting. Is this valid C++11? What is the intension to but both keywords into that line? Would 'void f() final;' be better? — Preceding unsigned comment added by Lars Winterfeld (talk • contribs) 20:14, 13 September 2011 (UTC)

"final" prevents a function from being overriden - but only virtual functions can be overriden in the first place, so it only makes sense to apply "final" to virtual functions. So the example in the article is correct; perhaps this could be explained in the article.VoluntarySlave (talk) 16:48, 15 September 2011 (UTC)

constexpr

'const int GetFive()'

In the section about constexpr, there was the following example:

int GetFive() {return 5;}
int some_value[GetFive() + 7]; //create an array of 12 integers. illegal C++

A couple days ago, an anonymous editor changed it to add 'const' before the GetFive() definition:

const int GetFive() {return 5;}
int some_value[GetFive() + 7]; //create an array of 12 integers. illegal C++

This was just reverted by another editor. I liked the original edit that added it, so I changed it back (to include the const). I think it serves a useful pedagogical purpose.

The argument made in the revert was that a const return value doesn't matter, and the const is discarded. While true, IMO it sort of misses the point of this example. For instance, it's also true that

int five = 5;
int some_value[five + 7]; //create an array of 12 integers. illegal C++

isn't legal C++, but in some sense this is for a different reason than the non-const GetFive example. In this case, the code would be legal if you told the compiler that five was constant. In the GetFive example, the code can't be legal because there is no way to tell the compiler that GetFive returns a constant, even with the const keyword.

By having it there, it emphasizes the fact that constexpr does something more than what you already get with const.

I don't feel strongly on this issue, and I won't contest it any more if someone changes it again. EvanED (talk) 15:08, 30 July 2010 (UTC)

The problem is that however much you may want to communicate that "constexpr" is doing something more than "const" is, this example is not communicating it. This is simply because "const int GetFive()" is syntactically identical to "int GetFive()", whereas "const int five" is not syntactically identical to "int five". If you feel the body of the text is not as effective in telling the reader how "constexpr" is different from "const" as you think it could be, then a more effective way to show this is to change the text where you feel it is deficient. This change simply doesn't tell the reader what you think it can. At least, not without adding to the text itself the specific contrast between "int five" and "const int five".

That being said, I really don't care one way or another. Korval (talk) 07:50, 2 August 2010 (UTC)

Since you, EvanED, don't feel strongly about it, but I do, I took the liberty of reverting it again. "const" on the return type is a very controversial issue, and IMO has no place in this example. It's only misleading/confusing. Also it implies that "const" and "constexpr" are somewhat similar, only one more powerful than the other. This isn't so, they're almost entirely different beasts. --80.120.4.2 (talk) 17:47, 8 April 2011 (UTC)

I find this example somewhat strange. Why would one want to write

int GetFive() {return 5;}
int some_value[GetFive() + 7];

instead of

#define GetFive (5)
int some_value[GetFive + 7];

I would like to have an example where I cannot use macros. — Preceding unsigned comment added by 217.253.103.95 (talk) 15:19, 25 June 2011 (UTC)

The macro version works fine and is simple, but it has one big problem: The GetFive identifier is valid for the rest of the source file instead of just the current block. In other words, macros do not obey the normal identifier scope rules. So if your write, for example

if (bla bla bla) {
  #define GetFive (5)
  int some_value[GetFive + 7];
  ...
}
else {
   double GetFive = 3.8;
   ...
}

you will get a compiler error on the last declaration. This means that if you use macros, you need to employ a different discipline than if you use "ordinary" variables.. --Oz1cz (talk) 09:27, 26 June 2011 (UTC)

Reason for a new specifier constexpr ?

According to the restrictions enclosing the use of constexpr, I am asking why such a keyword has been added to the C++ standard. The inline keyword was not a bad idea in its time (even in C), and when the function was as simple as a return, the optimizer was able to do the same job as constexpr i.e. determine that a value is not dependent of the software execution and thus the value could be computed at compile-time. Recurring functions were not optimized ; however with smarter optimizers looking at lifespan of data, it should be possible in many more cases.

So, is this constexpr specifier only a way of giving a hint to the optimizer ? Moving this job of the optimizer to the compiler ? Or standardizing some optimization by defining it in the language ? Teuxe (talk) 11:47, 13 January 2012 (UTC)

It is doing neither; you have a misunderstanding of how certain things work. For example, the inline keyword is only a hint for member functions in headers. For non-member functions, declaring them inline has different semantic consequences for that function with regard to ODR violations and the like. These semantic consequences are what actually allows them to be defined in headers at all (and therefore inlined).

Similarly, constexpr is more than just a hint; it allows new semantics. User-defined types that have constexpr constructors can be literal types if they fill certain criteria, and can therefore be used in certain situations. Without constexpr, literal types would be restricted to aggregates. Also, C++ defines this as ill-formed:

const int GetFive() {return 5;}
int theArray[GetFive()];

This does not work in C++. If a compiler did allow it, it would have to do so as a compiler extension, which is rather different from a compiler optimization like inlining. You can take code that you expect to be inlined and compile it on a compiler that doesn't inline it just fine. It'll just likely be slower. The above code does not compile unless your compiler allows you to do some extra-C++ stuff.

Under C++11, this does compile:

constexpr int GetFive() {return 5;}
int theArray[GetFive()];

So it's not just a hint; it has an actual semantic meaning. It changes the definition of what is and is not a constant expression. That's why I used the array definition as the example for constexpr. Korval (talk) 02:43, 14 January 2012 (UTC)

Attributes

Is it intentional that the article does not mention attributes? They are present in the latest working draft and are certainly worth being described here.--Tigrisek (talk) 23:42, 18 March 2011 (UTC)

C++11

Unless something highly unlikely happens in the standardization process, it looks like we will have C++11. However, I would suggest that, until it is actually a finished ISO standard, we should not rename/move the page to C++11. — Preceding unsigned comment added by Korval (talk • contribs) 05:06, 26 March 2011 (UTC)

Agreed. But since it's likely that people will be searching for C++11 in the near future I've gone ahead and added a redirect from there to here. When it becomes official, the redirect and page can be swapped. --Shirik (Questions or Comments?) 06:09, 8 April 2011 (UTC)

Now is the time? http://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/ Alexk7 (talk) 05:48, 13 August 2011 (UTC)

C++11 is by no means an official name (cf. ISO/IEC 14882:2011) and nowhere as widely used as C++0x. Kxx (talk | contribs) 06:31, 13 August 2011 (UTC)

Is there a way to get the C++11 redirect page to show up in search engine searches. As of today, 'C++11' pulls up nothing related to C++ at all on Google. 70.129.197.15 (talk) 21:11, 11 April 2011 (UTC)

Sure; just press the "make my page top of the search engine results" button at the bottom of the Google homepage. Tomalak Geret'kal (talk) 11:13, 14 April 2011 (UTC)

Agreed here too. Tomalak Geret'kal (talk) 11:13, 14 April 2011 (UTC)

ISO has approved C++0x and it's now officially named C++11. Should this page be moved? ClassixRetroX (talk) 17:09, 20 August 2011 (UTC)

Care to point to an ISO-published document officially promotes this name? At least for ref's sake. Kxx (talk | contribs) 20:40, 20 August 2011 (UTC)

I don't think we will see an official ISO reference to C++11. The C++98, C++03 and now the new C++11 are informal names used by the C++ community. I will suggest that we either change the name to C++11 (Herb Sutter already using this ) and redirect any C++0x to it or that we actually rename it to the official standard name (when that happens), i.e. something like ISO/IEC 14883:2011 and redirects both C++11 and C++0x to it. Personally I would prefer the informal name C++11. Misuo (talk) 07:51, 24 August 2011 (UTC)

The point is that it's not C++11 yet. If the spec is published in 2012, then it will be C++12. Calling it C++11 is premature. Korval (talk) 08:52, 25 August 2011 (UTC)

I can accept that we wait until it is published. Accordingly to Herb Sutters update to his blogentry ISO intends to publish it within a matter of weeks. He is chair of the ISO C++ standards committee and has himself started to use the C++11 name. Misuo (talk) 17:56, 25 August 2011 (UTC)

Bjarne Stroustrup keeps using "C++0x" on his FAQ page and says that C++11 might just become C++12 due to ISO bureaucracy. There is no need to WP:CRYSTALBALL just for a name. Let general acceptance decide whether and when an informal name as "C++0x/11" is should be used. Wait until "C++11" picks up on popularity, then we make the change. Kxx (talk | contribs) 17:03, 26 August 2011 (UTC)

If I'm not mistaken ISO has pr 2011-09-01 pulished the new/updated C++ standard under the name ISO/IEC 14882:2011 . --Misuo (talk) 22:30, 2 September 2011 (UTC)

Fair enough. The C++11 page is a redirect to this one. How do we go about the task of swapping this page for the C++11 page?Korval (talk) 10:47, 3 September 2011 (UTC)

Since nobody else wanted to do it, I moved it. Korval (talk) 22:53, 5 September 2011 (UTC)

FDIS: new, explicit, final, override

Herb Sutter writes that the new and explicit markers, mentioned in "Explicit virtual function overrides", have been removed and that final (which is apparently not mentioned in this article) and override remain in the language's Final Draft International Standard. (See also his full report on the FDIS, and the Slashdot post from which I learned of it.)

I guess those changes only impact that section of the article, but I'll leave it to others to edit in case I misread. --an odd name 00:18, 27 March 2011 (UTC)

Good point. When the mailing is released and the new wording made available, we can update the article more specifically as to how these things work. Right now, we just don't have the details to say how the functionality works now. Korval (talk) 01:59, 31 March 2011 (UTC)

The article has been updated to match the current version of the specification. Korval (talk) 20:56, 14 April 2011 (UTC)

Multitasking memory model

The article currently says "The memory model defines when multiple threads may access the same memory location, and specifies when updates by one thread become visible to other threads. The C++0x draft ensures sequential consistency for programs that do not explicitly specify weaker memory ordering constraints".

Depending on how this is interpreted it is either false or very misleading. The standard makes "seq_cst" the default for operations on atomic types. The quoted text however implies that every memory access (non-atomic, non-volatile) has "seq_cst" ordering by default (which is not true). --80.120.4.2 (talk) 17:25, 8 April 2011 (UTC)

I removed the parts in question. 90.146.147.218 (talk) 01:07, 22 April 2011 (UTC)

May be a quote

The section I just added a requested citation to might need to be annotated as a quote from the cited article. I'll leave that to who ever put it in the article in the first place, as this is all i have time for right now. Good Night, Good luck and God^h^h^h Thor Bless. Jjk (talk) 19:38, 28 May 2011 (UTC)

N3281 or N3291?

In two places (lead and C++ Standards Committee papers) the link (URL and link text says N3291, but the PDF linked to is N3281. Also, there is a dead link to a final draft N3290. Guy Macon (talk) 21:25, 12 June 2011 (UTC)

They're both caused by the same problem: the C++ committee has un-released the final draft and FDIS specifications. Technically, they weren't supposed to release them in the first place. The ISO site automatically attempts to correct bad links, so it turned the N3291 link to the N3281 page. And the N3290 link is dead for similar reasons. The best bet is to just remove these links entirely. Korval (talk) 23:23, 12 June 2011 (UTC)

Random number generators

Where did the table of properties of random number generators come from? It looks a bit dubious; one would not expect the high-quality mersenne_twister algorithm to be "fast" if the simplistic linear_congruential algorithm is only "medium" speed. —Preceding unsigned comment added by 68.33.168.195 (talk) 00:53, 11 September 2010 (UTC)

I don't know any implementation of a Mersenne Twister that is (or has the potential to be) faster than a simple linear congruential generator. I guess the "speed" column in the table needs an update. —Preceding unsigned comment added by 134.93.143.104 (talk) 15:08, 4 January 2011 (UTC)

Don't make guesses. If you have sources supporting whichever is faster, put them in.Kxx (talk | contribs) 16:18, 4 January 2011 (UTC)

There's nothing about speed in the ISO standard (as one would expect), and the state size column directly contradicts the standard. I've updated the table (replaced it with a list), and also extendedthe incomplete list of distributions that was below, to reflect what is verifiable. Chrisjohnson (talk) 12:18, 12 June 2012 (UTC)

Compiler Support

Could we perhaps have a section or table which describes which compilers support C++11 and which features are supported in which versions?

For example: gcc 4.2 supports C++11 except Lambda's. RustyBadger (talk) 13:03, 18 April 2012 (UTC)

GCC 4.2 most certainly does not. 4.2 was released in 2008, which was well before the standard was finalized. 4.2 supports a few C++11 things, but really only those things that it always supported as extensions. There's a good reason not to have this stuff here: it changes far, far too quickly. There are websites that track this stuff much better than Wikipedia can. Korval (talk) 23:20, 3 May 2012 (UTC)

This is the best source that most people refer to: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport - Andrewmp (talk) 13:18, 21 May 2012 (UTC)

C++11 is here now

Reading through this article, there is a lot of talk of features C++11 'will' have. Should this not be updated to say that C++11 does support these features. I would have changed them, but it seems like it could be a deliberate thing. Thecoshman (talk) 14:38, 14 March 2012 (UTC)

No, it's just a holdover from when C++11 was still the future. Sometime back, I did a pass to clean up most of them, but apparently I missed a few. Korval (talk) 02:32, 2 April 2012 (UTC)

I have not given it a full look over, but if I am not mistaken, there are still a few 'C++11 will have' bits in the article. I will do my best to remove update to be what C++ does have when I get a chance, but if any one else can confirm it is all cleared up, can you just follow up to this. Thecoshman (talk) 09:53, 17 September 2012 (UTC)

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)