Talk:C++11/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

C++0x -> C++1x

Seeing as how the next standard will not be out this year (2009), maybe this article should be moved to C++1x. If anyone is opposed, speak now or forever hold your peace. If I remember, I'll move the article in a week if there are no objections. --Snaxe/fow (talk) 21:38, 8 April 2009 (UTC)

As long as the standard committee still calls it "C++0x" [1][2][3], there is no reason to move.Kxx (talk) 22:47, 8 April 2009 (UTC)

Countervote from me, too. As long as the committee says C++0x, I say that, too. And, as far as I know, nobody ever defined the underlying numerical base for 0x. It could also become C++0xA or C++082 (octal 10). Out of curiosity, Snaxe920, where did you see that it won't come out this year? Phresnel (talk) 14:22, 14 April 2009 (UTC)

C++0x is the name in use, C++1x is an original invention of an editor. -- 98.108.199.9 (talk) 08:56, 13 November 2009 (UTC)

Hmm I heard wrong. According to N2870, they're still aiming for the end of this year. --Snaxe/fow (talk) 23:51, 14 April 2009 (UTC)

They definitely aim for end of 2010. I, for myself, call it c++1x aswell as (who? People of ##c++ and ##iso-c++ in freenode) other people too. But i agree, it would probably be better to keep the name "C++0x" in this article. Not all names are logical, after all :) I created a redirect from C++1x to this article, though.

(and yes, Standard names follow decimal patterns - not hex or anything like that - like "C++98" and "C90". Note how there is even made a difference between C89 and C90). Litb me (talk) 18:53, 17 April 2009 (UTC)

Nevertheless, IRC channels are not reliable sources. I have yet to see one that uses the term C++1x. That's not to say they don't exist, but they sure are under-represented. decltype (talk) 19:12, 17 April 2009 (UTC)

See this: [4] (page 17) and this [5] (page 2). However, i agree most people call it C++0x. What i want to say is that the name that should be taken is C++1x, if at any day one decides to change the name of the article - and that it's not just one of those many other "fantasy" names people come up with. Litb me (talk) 19:17, 17 April 2009 (UTC)

Fair enough. But even so, a name change seems unlikely before the standard is actually approved, since the term C++0x is in such widespread use. But the papers you cite at least justify the redirect. decltype (talk) 19:26, 17 April 2009 (UTC)

Current status: resolved. While the standard will very likely not be released in 2009, C++0x is the most well used name and therefore this article will stay as C++0x until the standard is released.

Resolved by WHO exactly? Not that it should be changed before 2010 arrives. —Preceding unsigned comment added by Promit (talk • contribs) 05:52, 24 July 2009 (UTC)

Unified function syntax

According to the minutes, the paper was not approved at the latest meeting, unless I'm missing something. "We reviewed a new draft of the Unified Function Syntax proposal. ... CWG will produce the best possible proposal and bring it to the full committee for a vote ..."¹ decltype (talk) 19:21, 5 September 2009 (UTC)

It also says, "N2890, "Unified Function Syntax" was discussed, and was moved to Core." It has not been voted directly into the Working Paper yet, but neither has the explicit virtual overrides, and that section is here too.

It isn't wrong to have things in development on this page, so long as there is a clear indication that they will be adopted into C++0x in some form. And I think moving it to the Core WG provides such an indication. Korval (talk) 19:46, 6 September 2009 (UTC)

Yes, the reason I'm a bit wary about this particular proposal is that the previous version, N2763, notably failed to gain consensus to be incorporated into the WP, while the late-specified return type is obviously going to be in C++0x. Possibly the article could be updated to reflect that the latter is separate from the unified function syntax proposal. decltype (talk) 06:58, 7 September 2009 (UTC)

I understand you point. But with borderline cases, I've generally erred on the side of inclusion rather than exclusion. They're interested in it enough to move it to the Core WG, so they seem to want it. And if they later vote it out, we can just change it back. I don't think there is a need for a specific note saying that the -> return type syntax is separate from the [] function notation. Korval (talk) 05:24, 8 September 2009 (UTC)

OK, the minutes of the most recent meeting very strongly suggest that the unified function syntax is dead. They tried to vote it into the working draft, and they specifically decided against it. The minutes also specifically indicate that, because it was voted down here, the proposal is effectively dead. So I have removed the mention of it. Korval (talk) 02:53, 15 November 2009 (UTC)

Great, I've been waiting for this (the minutes, not the death of UFS). decltype (talk) 14:48, 15 November 2009 (UTC)

Property

Nice stuff but why we don't have anything to define properties???? —Preceding unsigned comment added by 216.239.87.88 (talk • contribs) 16:02, February 5, 2009 (UTC)

Thanks

I just wanted to say: really good work here. Very useful article. - Jmabel | Talk 04:02, 25 January 2010 (UTC)

One quibble

Resolved

 – Jmabel | Talk 19:31, 25 January 2010 (UTC)

Not that this is central to the topic, but if I understand correctly, in the printf example for variadic templates, if the string contains "%%" a single '%' should be output (std::cout << '%'); the code provided here throws it away. Lacking that, I spent several minutes staring at it trying to understand the logic of if (*s == '%' && *(++s) != '%'). With that, it would have been immediately clear.

Or perhaps I've misunderstood? If I'm correct and this was just an effort to streamline, I suggest adding back the missing line of code; those of us used to scrutinizing code (and who else would be reading this?) will follow more easily. Or, if I've misunderstood, an explanation would be greatly appreciated. - Jmabel | Talk 18:48, 25 January 2010 (UTC)

I'm not sure I follow. Which missing LOC is it that you refer to? decltype (talk) 19:21, 25 January 2010 (UTC)

Oh! I see now. By skipping past a single character, "%%" is handled by leaving the pointer pointing at the second '%'. The code is correct, and I was confused. Nice approach, my bad. - Jmabel | Talk 19:31, 25 January 2010 (UTC)

New string literals: missing example

Talk 01:02, 26 January 2010 (UTC)

 – Jmabel

The New string literals section mentions the ability to use ] in a raw string literal, but doesn't give an example. I assume it would be like R"delim[using a ] (right bracket)]delim". If I've understood correctly, I think that would be a useful example to add to the article. If I haven't, then an example of doing it correctly would be even more useful. - Jmabel | Talk 19:01, 25 January 2010 (UTC)

You got it right. The raw string consists of d-char-sequence_opt [ r-char-sequence_opt ] d-char-sequence_opt. Thus, a stray "]" would not terminate the string, unless immediately followed by the d-char-sequence (the delimiter). The delimiter itself can be 0-16 characters, and should not consist of brackets, newlines, tabs, etc. This is hopefully already explained in the article. decltype (talk) 19:26, 25 January 2010 (UTC)

The draft notes that R"delimiter[[a-z]]delimiter" is equivalent to "[a-z]", so that could be added as an example. decltype (talk) 19:28, 25 January 2010 (UTC)

Incoherent sentence

"In the case of the default constructor, it is useful to want to explicitly tell the compiler to generate it."

"...it is useful to want" makes no sense. - Jmabel | Talk 19:24, 25 January 2010 (UTC)

Also "using the actual standard". I suspect that "actual" here is a false cognate of a word in several European languages (but not English) meaning "current". Or perhaps something else is meant. In any case, "actual" is a poor choice. - Jmabel | Talk 20:17, 25 January 2010 (UTC)

Just looked up Merriam-Webster. Actual can mean current.Kxx (talk) 02:53, 26 January 2010 (UTC)

Requested move

C++1x → C++0x —

"Even though the standard will not be delivered before 2010, we have chosen to keep the informal designation C++0X, so as not to introduce any additional confusion. (...) In Committee discussions and email, Bjarne Stroustrup recommended that we keep referring to C++0X to reduce possible confusion. Nobody disagreed, as far as I know. Even if the informal designation were to be the subject of a document or vote (not likely, IMHO), no document or vote would be required to say that we will continue to do what we have been doing, unless someone proposed a change. Nobody did."[6] —Steve Clamage

The name change has been subject of earlier discussion here without consensus to move to C++1x. Reliable sources almost exclusively use C++0x. This is what we base our article name on. Even if the year has changed, the name remains the same. The committee will also continue referring to the new standard as C++0x. decltype (talk) 07:09, 5 January 2010 (UTC)

Please keep the name C++0x until the standards committee and Stroustrup rename it! Using a nonstandard name confuses everyone, while a redirect might remedy for the possible confusion of someone searching for C++1x in Wikipedia. (This is the dry humorless editor standard opinion). Rursus dixit. (^mbork³!) 18:36, 29 January 2010 (UTC)

Article is now out of date

The Portland meeting in October 2006 established what will be the main additions to C++0x. Many items that were originally considered for inclusion (and mentioned in the current article) are now no longer so considered. A good overview of the Portland decision was written up by Herb Sutter here.

Daveed V. 22:12, 15 February 2007 (UTC)

I've replaced the dispute template with {{update}}, which is more specific and looks better. Hairy Dude 17:59, 24 April 2007 (UTC)

yeah okay this does not change that 80% of that article is entirely made up see also http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2228.html

I've read much of the stuff in from the n228.html webpage, and I have a pretty good handle on what C++0x is shaping up to be. I'm willing to take some time to rewrite the article, but I have a few questions about how to do it (with appropriate citations).

Should I make any attempts to specify how likely one feature is to be added to the final C++0x spec? Should I make some effort to categorize the new features, or should I just list them one (perhaps alphabetically)? Korval 01:58, 30 May 2007 (UTC)

Be bold! Do what you feel would be best for the article. However as a suggestion, the more details (with app cite) you can provide the better, avoid just a list of items. KTC 09:03, 12 June 2007 (UTC)

"The final committee draft of the standard may be issued by the end of 2009" - did this indeed happen? This needs to be updated. Reinderien^{talk/contribs} 08:09, 4 January 2010 (UTC)

Nope. Updating accordingly. decltype (talk) 08:19, 4 January 2010 (UTC)

The first paragraph states the libraries will be extended, "The new standard will include several additions to the core language and will extend the C++ standard library, " Yes the language is getting additions that is obvious, Perhaps a re-wording to the former is in order, are the libraries getting extended? I don't think so, neither does Bjarne Stroustrup http://www2.research.att.com/~bs/C++0xFAQ.html#what-libraries 124.171.211.84 (talk) 11:15, 21 February 2010 (UTC)

The libraries are definitely being extended. See C++0x#C++ standard library changes. In the link you posted, BS links to this. decltype (talk) 11:32, 21 February 2010 (UTC)

What exactly is the subtract_with_carry PRNG engine?

There is no article on the subtract_with_carry engine. The name looks similar to what is found in a paper by G. Marsaglia and A. Zaman (“add-with-carry” and “subtract-with-borrow”), which is cited by N1452. Can anyone confirm whether the engine really comes from that paper?Kxx (talk) 19:16, 26 January 2010 (UTC)

According to N1452, a subtract_with_carry engine produces integer random numbers using x(i) = (x(i-s) - x(i-r) - carry(i-1)) mod m; carry(i) = 1 if x(i-s) - x(i-r) - carry(i-1) < 0, else carry(i) = 0. . m, r, and s are constants. decltype (talk) 20:39, 26 January 2010 (UTC)

It seems that subtract_with_carry as it is in N1452 and N3000 really is Marsaglia and Zaman’s subtract-with-borrow. Maybe we can have an article to explain how the PRNG works.Kxx (talk) 22:28, 26 January 2010 (UTC)

Collision between UTF-8 and other string literals and string concatenation with macros

What about the following code:

#define u8 "I will be concatenated"
char *s = u8"I'm a UTF-8 string.";

How will this ambiguity be resolved? Icek (talk) 16:59, 1 February 2010 (UTC)

From looking at the proposal, it will work the way it does for the current L"" strings. A UTF-8 string literal in C++0x is considered a single token. So a UTF-8 string in C++ is not a 'u8' token followed by a string token, but it is a UTF-8 string token. And macro replacement operates at the token level, not by search-and-replace. It's the reason why this is perfectly legitimate C++ code:

#define fo "Not For"
for(;;);

The macro does not affect the token "for". It affects only the token "fo". For the same reason, the macro 'u8' will not affect a UTF-8 string token. Korval (talk) 19:39, 1 February 2010 (UTC)

Where does n3000.pdf state that a long long int is at least 64 bits?

It seems common parlance that a long long int is defined to be at least 64 bits long on common systems.

But as I grok the current draft, n3000, long long is only defined to be at least as long as a long int, in turn at least as int, etc., as it always was since 1998.

I'll refine that section if nobody will give evidence for a long long being at least 64 bits.

edit: sidenote: Yes, I know that the original proposal n1811 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf) defines a long long as 64+ bits, but it's not in n3000.

Phresnel (talk) 17:05, 3 February 2010 (UTC)

Like in C++03, the minimum sizes of the integer types can be inferred from the <climits> header. Its contents should be equivalent to its C counterpart, limits.h. The minimum values there require at least 64-bit precision. decltype (talk) 17:43, 3 February 2010 (UTC)

I see. So we actually have two definitions of the minimum sizes, the one being all in relation to type char (char<=short<=int<=long<=long long), and the other being of absolute, minimum magnitudes (e.g. signed char max >= 127), though the C++ standard does only refer to C, and does not mention the minima itself. Thanks for the pointer. Phresnel (talk) 08:53, 4 February 2010 (UTC)

That's right. The paper you cite even mentions this fact. "... apparently the only thing that establishes minimum sizes for the integral types in the C++ standard is the requirement that they match the <climits> macro values like INT_MAX ... This is being split off as a separate core issue." Note that C99 also introduced fixed-width integer types, these will be in C++0x as well — An implementation must suitably define typedefs such as int_fast32_t and uint_least64_t. decltype (talk) 09:09, 4 February 2010 (UTC)

Shouldn't C++1x be mentioned in the main article?

A Google search restricted to en.wikipedia.org for C++1x comes up with C1X ("C1X is the unofficial name of the planned new standard for the C programming language.") and other C references. This is somewhat confusing.

If C++1x was mentioned in the main article search results could be less confusing.

E.g. there could be section that answers the question "If C++0x was supposed to be released/finalised in the period 2000-2009 and this did not happen, why is it still called C++0x, and not C++1x?"

What do you think?

--Mortense (talk) 15:42, 7 February 2010 (UTC)

Would putting “C++1x” in just cause search results to be even more confusing, considering that some people already use the term to refer to something beyond C++0x (e.g., Bjarne Stroustrup, N2893)? Kxx (talk | contribs) 20:59, 7 February 2010 (UTC)

C++1x redirects to C++0x here on Wikipedia. So according to Wikipedia C++1x and C++0x are equivalent. It is not primarily the search engines I am concerned about, but more that there is no information about C++1x on Wikipedia. --Mortense (talk) 19:21, 4 March 2010 (UTC)

Nothing to do about it. We have no control of the Google search engine, which have some annoying quirks regarding searches for non-letter characters. Rursus dixit. (^mbork³!) 14:51, 16 February 2010 (UTC)

Move Transparent Garbage Collection?

Hi, I am too shy to edit, but I think the section about transparent garbage collection should be moved to "Features planned but removed or not included". I missed a heartbeat when I browsed through the TOC and found it there just to get disappointed from the "C++0x will not feature transparent garbage collection directly." ;-) 84.179.112.180 (talk) 20:34, 16 February 2010 (UTC)

I took it out. If anyone disagrees, feel free to revert. decltype (talk) 06:27, 17 February 2010 (UTC)

C++1x?

I guess you'll all have heard that the new standard is delayed to 2010 or later.[7]

It's funny, I didn't realize until last night that the 0x in C++0x was a partially instantiated year number, like C++93 and so forth. I'd thought it was a reference to C/C++'s syntax for hexadecimal constants, just like the ++ in C++ is a reference to C's increment operator. 70.90.174.101 (talk) 19:02, 23 July 2009 (UTC)

AFAIK, there's still a couple of months left of '0x, and the current draft is published in '09, and if there's no more changes to that, it would still be '09 even if the ratification and publication dates will be in '10 or even '11. Let's change the name if and when the name is changed. -- Henriok (talk) 23:07, 11 September 2009 (UTC)

I'm shocked to find that the article has been renamed to C++1x. The inofficial preferred code name is still C++0x even if we have the year 2010 already, see usenet postings by committee members in comp.std.c++. Zerpi (talk) 19:34, 5 January 2010 (UTC)

The standard is most definitely delayed to 2010 or later. While the per pattern of Windows 95 (ready 1996) they can use all 2010, they will probably not succeed. Suddenly, in the late part of the process, they decide to add a pretty elaborate threads support. Nice, but the standard won't be finished during 2011, and it will take to 2015 till the standard is fully covered in gcc. Rursus dixit. (^mbork³!) 18:32, 29 January 2010 (UTC)

It is quite possible that GCC won't be standards conformant even in 2015. To the best of my knowledge, there are no plans to implement export in gcc (which would bring it closer to C++03 conformance). decltype (talk) 18:38, 29 January 2010 (UTC)

Byebye "export". Rest in Peace. http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ --84.179.96.245 (talk) 17:26, 22 March 2010 (UTC)

Good riddance :) decltype (talk) 17:56, 22 March 2010 (UTC)

Although it may be appropriate to rename the article to C++1x, we do not yet know if the standards committee can travel to the past and finalize the standard. Putting in this information now would constitute original research, but if anyone has any sources stating that they can't or won't travel to the past please add it to the article. —Preceding unsigned comment added by 76.108.120.98 (talk) 05:46, 19 June 2010 (UTC)

One of the reasons why C++0x is still called so, is because x can be treated as hexadecimal digit. So the committee still has a few years left. —Preceding unsigned comment added by 129.79.244.161 (talk) 18:08, 15 July 2010 (UTC)

reference_wrapper usage example

IMHO the code given as an example of reference_wrapper typical usage is misleading. If I want to wrap a function which is incrementing given variables the template function should look like:

template<class F, class P> void g( F f, typename std::tr1::add_reference<P>::type t)  { f(t); }

You seem to have missed the point of the use case. Also, "typename add_referece<T>::type" is a non-deducible context. Since P cannot be deduced, you would have to explicitly provide the template parameters F and P. Zerpi (talk) 19:10, 11 January 2011 (UTC)

User defined String Literals

I think there is a discrepancy in the text:

 Literals can be extended in both raw and cooked forms, with the exception
 of string literals, which can only be processed in cooked form.
 [...]
 User-defined literals processing the raw form of the literal are defined as follows:
 _
 OutputType operator "" _Suffix(const char *literal_string);
 OutputType someVariable = "1234"_Suffix;
 _
 The second statement executes the code defined by the user-defined literal function. 
 This function is passed "1234" as a C-style string, so it has a null terminator.

If string literals can only be processed in their cooked form, but the example is about the raw form, how does this fit together? I would expect an cooked form example, if just before was sait that there can only be a cooked form. Right?

The Spec says in `[2.14.8.5]` that user-defined-string-literal operators shall have the form `operator "" X(str,len)`. In `[13.5.8.4]` it is said, that the raw literal operator gets `const char*`, like in your example. Thus, `operator ""X(str,len)` must refer to the cooked form. Then, the example, where `"1234"_Suffix` is parsed would be (as mentioned) about the raw form -- and still it has been said, that strings must be processed in cooked form.

confused... —Preceding unsigned comment added by Torsten Will (talk • contribs) 11:30, 2 March 2010 (UTC)

Pronunciation

I was hoping to find this in the article: How do you pronounce C++0x? Is it "C plus plus ox"/"C plus plus oh ex"/"C plus plus oh nine"? "C plus plus zero nine"? "C plus plus nine"?

Would be cool to have it in the article. Most topics put pronounciation of the lemma in the first sections when it's not obvious. —Preceding unsigned comment added by 134.102.55.227 (talk) 14:09, 4 March 2010 (UTC)

I've heard several committee members and others pronounce it as "See plus plus oh ex". decltype (talk) 14:16, 4 March 2010 (UTC)

Thanks, added it!~~----

I'd argue these people (the ones who say "see plus plus oh ex") are pronouncing it wrong. "Oh" is a letter. The round symbol in "C++0x" is the number zero, not the letter "oh". The correct pronunciation should be "see plus plus zero ex". Moulding (talk) 16:25, 16 June 2010 (UTC)

In certain contexts it is natural to pronounce 0 as "oh (ˈoʊ)". decltype (talk) 11:34, 17 June 2010 (UTC)

"See plus plus oh ex" is such a mouthful, compared to "C" or "Java." Would it be horrible to have it called "See-pox" or if C++1x goes through, call it "See-pix"? -S! —Preceding unsigned comment added by 71.246.211.190 (talk) 17:15, 25 June 2010 (UTC)