Very funny indeed!

--212.27.60.48 (talk) 07:04, 11 February 2009 (UTC)[reply]

This is Wikipedia. If you have found errors, feel absolutely free to correct them. You don't even need an account. Korval (talk) 22:52, 11 February 2009 (UTC)[reply]

This is a discussion page, where discussion of problems with an article and how to improve it are relevant. Your sort of comment is not helpful. -- 98.108.199.9 (talk) 08:42, 13 November 2009 (UTC)[reply]

Yes, the wording of the null pointer section was in fact problematic. I think it looks ok now, unless one wants to get extremely pedantic. For example, while 0 is an integer constant in C, it is an integer-literal in C++. —Preceding unsigned comment added by Decltype (talk • contribs) 07:20, 12 February 2009 (UTC)[reply]

Alright I made a large edit on this section. I think I addressed all the issues outlined. --Snaxe/fow (talk) 17:47, 20 April 2009 (UTC)[reply]

Current status of this issue: resolved.

What does it mean? If it's almost 100% compatible it's by definition not 100%. I think that sentence is pretty stupid. 159.149.106.5 (talk) 09:36, 20 March 2009 (UTC)[reply]

I agree, but that's what the man said :). Of course, there will be subtle differences in semantics, and some old code will be broken due to the addition of new keywords, among other things. decltype (talk) 09:43, 20 March 2009 (UTC)[reply]

I think almost 100% means 80% or 99%, depends on metrics we use. I dont see the stupidity. Though im not native speaker (or in this case writer) of english, so. 192.100.124.218 (talk) 10:51, 23 March 2009 (UTC)[reply]

Well, neither am I, nor Bjarne Stroustrup himself. But since it's his exact quote, I don't see the problem. decltype (talk) 11:52, 23 March 2009 (UTC)[reply]

I have put the exact phrase as Bjarne Stroustrup wrote in quotation marks. So let him take any applause or blame for his own words. —Kxx (talk) 19:43, 23 March 2009 (UTC)[reply]

I don't understand the problem with the wording myself. The phrase "almost 100%" means exactly that: almost 100%. By definition, as you say, it is not 100%, but very close to it. That is a good description of the number and potential problem of the backwards compatibility issues that C++0x provides. In short: you might need to change a couple of lines of code, but it's nothing you should worry about. Korval (talk) 22:49, 25 March 2009 (UTC)[reply]

Pretty stupid is the the comment by 159.149.106.5. Of course anything that is "almost X" is by definition not X; duh -- it's almost X. -- 98.108.199.9 (talk) 08:49, 13 November 2009 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]