Talk:C++11/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Would rvalue references warrant an own article?

Per the above, and the fact that there's much more to be said. Move assignment isn't mentioned at all, and much could be said about how move ctors and move operator= are defined. Examples of perfect forwarding could also be shown. At the same time the main article is getting very large and difficult to navigate. decltype (talk) 20:09, 20 March 2009 (UTC)

I think they do. This article is truly very looooooooooog. It looks pretty bad to stuff more about move semantics and perfect forwarding here.—Kxx (talk) 06:13, 23 March 2009 (UTC)

Hey, thanks for explanation, i think i got it. And agree: it would worth an article. 192.100.124.218 (talk) 10:30, 23 March 2009 (UTC)

The idea was that, once C++0x is a finalized spec, we would break the important and complex sections (rvalue-references, concepts, etc) into their own separate pages. There is certainly enough material to warrant having its own article, but I'm not certain that we should have multiple articles based on something that isn't yet final. Korval (talk) 01:18, 24 March 2009 (UTC)

I don't see much problem in moving rvalue references and alike out. We can leave 100–200 words here to briefly introduce these concepts and refer whoever is interested to their own articles using Template:Main. Doing so gives the immediate benefit of shortening an article that is already WP:TOOLONG. We can assume a bold attitude despite everything is not yet finalized. Given the standard committee's adamant position in avoiding C++0a, C++0b, …, chance is presumably small that drastical changes would occur. As long as we don't go into too much detail here, we are most likely safe to have separate articles on subjects worth elaboration.—Kxx (talk) 03:51, 24 March 2009 (UTC)

If you insist, you can move it to a new article. But you should also move Concepts to a new article as well. Maybe even variadic templates. Korval (talk) 22:52, 25 March 2009 (UTC)

variadic templates already have their own article..but it looks very sandbox-y at the moment. decltype (talk) 06:28, 26 March 2009 (UTC)

Yes, that article was originally created because I removed someone's original research proposals for Variadic Templates, so they moved it to another page. I'd be totally fine with that page being improved. Korval (talk) 19:02, 26 March 2009 (UTC)

Rvalue references probably should go into Reference (C++). But that article itself may need some overhaul in the first place. I can't tell what exactly is wrong with it. It just looks unnatural to me, and immediately merging rvalue references into it seems to make things worse.—Kxx (talk) 20:17, 26 March 2009 (UTC)

Hmm..I didn't even know about that article. It could use some improvement. decltype (talk) 06:33, 27 March 2009 (UTC)

Concepts have their own article, too.—Kxx (talk) 04:39, 28 March 2009 (UTC)

axioms

I am a bit surprised to see that axioms are not mentioned at all. They are mentioned on Bjarne Stroustrup's webpage: http://www.research.att.com/~bs/C++0xFAQ.html#axioms —Preceding unsigned comment added by 193.254.175.108 (talk) 09:31, 25 March 2009 (UTC)

Yes, axioms are an interesting concept (pun intended), that will almost surely be in the new standard. Definitely worth a mention. decltype (talk) 09:43, 25 March 2009 (UTC)

Axioms are not mentioned because they are not a part of the working draft, nor are they a part of any proposals on the table for discussion (as listed here. Until they are, they should not be discussed in this article.Korval (talk) 22:46, 25 March 2009 (UTC)

N2857, the working draft dated Mar 23, has axioms under 14.10.1.4. N2800 also had them, but under 14.9.1.4. Does that justify a mention here?

By the way, what precisely does the word "report" refer to in the last sentence of the opening paragraph? A working draft or a document of some other sort?—Kxx (talk) 23:38, 25 March 2009 (UTC)

Yes, axioms has been in the draft since concepts were added (N2798), since they were part of the concepts proposal. Apparently, the shift in numbering was to make room for another section on exported templates. Such changes are more or less expected since it's a draft. decltype (talk) 06:25, 26 March 2009 (UTC)

I have created Axioms under Concepts (looks pretty odd in the table of contents as the only subsubsection), using an example copied from N2857. I am thinking about furthering the example to show how axioms actually work. SGI STL's power algorithm seems to suggest some idea. But I am not sure about the details yet.—Kxx (talk) 23:12, 26 March 2009 (UTC)

Publication in 2010 or later?

N2697 seemed to have said little about whether the timetable proposed by Herb Sutter represented standard committee consensus. The following straw poll only dealt with the Sep 2008 committee draft and had nothing to do with the official international standard. Moreover, even if the standard committee plans its work according to that timetable, it will be publishing a final draft international standard after the third meeting of 2010. According to a talk by Lawrence Crowl and Matt Austern, it would take another six months or more before the official international standard is published. That will probably push the publication date into 2011. I think the lead section needs some clarification about that.Kxx (talk) 03:11, 20 April 2009 (UTC)

Erm, the lead section already does clarify this. Also see the talk section prior to this, C++0x -> C++1x. --Snaxe/fow (talk) 17:46, 20 April 2009 (UTC)

Current status: resolved. See the previous talk section, C++0x -> C++1x.

The point I wanted to put forward was not about whether the standard will come out in 2009—it is pretty sure that it won't—but that the citation is too weak in supporting the claim. N2697 said nothing about the publication date of the official international standard and thus certainly didn't nail that date in 2010. Furthermore, judging from N2697 alone, it is unclear whether the standard committee endorses Sutter's timetable. Therefore IMHO, N2697 itself does not stand firm enough to back up the claim that "[the standard] would be published in 2010". (BTW, given that the FDIS won't be ready until the third meeting of 2010, personally I would suspect that the official IS will actually come out in 2011.) And the lead section should be less specific about the publication date unless stronger citations are found.Kxx (talk) 19:31, 20 April 2009 (UTC)

I have tagged that sentence with {{verify source}}. Correct me if I missed something.Kxx (talk) 19:40, 20 April 2009 (UTC)

Reading over N2697 carefully, there is still some discussion over the timetable, as you pointed out. The main problem here is what exactly the standard being "published" means. Are we going with when the final draft is issued, once the draft makes its way around ISO, or some time entirely different? According to N2697 they do have a meeting planned for October this year, however I think that doesn't keep the final draft from being issued by the end of this year. I propose we clarify this by saying something like "There is some debate over when the standard will be published. The final draft of the standard may be issued either by the end of 2009 or early 2010, however WG21 expects it to take six months to a year before the standard is published by ISO." --Snaxe/fow (talk) 16:02, 21 April 2009 (UTC)

According to here and here, the ISO is very specific about what something being published means, not approval of drafts but publication of the official document. So probably we should follow the same definition.

Comparing with how things worked for C++98 (see here), there is still a long way to go for C++0x. The current status of C++0x is similar to what C++98 was in the first half of 1996, with the FCD yet to be completed. Projecting the timeline of C++98 into that of C++0x, we can expect an FCD by the end of 2009, an FDIS by the end of 2010 (in accordance with the timetable in N2697) and final publication in 2011.

Based on the above, I propose expanding your text into:

There is some debate over when the standard will be published. The final committee draft of the standard may be issued by the end of 2009, and the final draft international standard by the end of 2010. However, WG21 expects that it will take another six months to a year before the standard is published by the ISO.

Kxx (talk) 20:25, 21 April 2009 (UTC)

I like that wording. I'll merge it in right now. --Snaxe/fow (talk) 05:58, 22 April 2009 (UTC)

The like the wording too. Seeing how long it took for C++98's FDIS to become the official Standard (i read somewhere it only takes a few weeks for ISOs, but apparently C++98 did take way longer), i think it's reasonable to expect something around early 2011. Litb me (talk) 18:59, 22 April 2009 (UTC)

Why talking of PODs while standard clearly defines the aggregate terminology ?

I'm curious of why it has never been mentioned in the paragraph of new POD definition and Initialize lists. would by any chance an aggregate be a POD ? I still havn't read the entire 1300 pages of the standard (PITA...) so i wouldn't know. what i know for sure is that an aggregate IS the condition to be initializable with initialize list. —Preceding unsigned comment added by Lightness1024 (talk • contribs) 21:55, 22 April 2009 (UTC)

From what i know, an aggregate in the new Standard is the same as in the old Standard as explained in the section about declarators/initializers. An aggregate can be initialized with an initializer list, that's right. However, in C++1x, initializer lists can be used to initialize other things too. Like class types with an initializer list constructor.

Aggregates have little to do with PODs, other than that POD structs are aggregates (in C++03, at least) (but not the other way around: struct x { string f; }; is an aggregate, but not a POD). However, now in C++1x there are several changes to the definition of PODs and the rules of the associated text. So, now you can memcpy non-PODs, as long as they are trivially copyable. And you can use offsetof on classes that are standard-layout classes. Litb me (talk) 15:32, 26 April 2009 (UTC)

Very interesting answer, making me want to read a little more about this, for clarity. --Lightness1024 (talk) 21:53, 14 May 2009 (UTC)

Inaccuracy With Concept Maps?

The article says that concept maps

allows a pre-existing object to be converted, without touching the definition of the object, into an interface that a template function can utilize.

From what I understand, concept maps can only adapt operators and free functions, but not member functions, so the object is not converted to any type. Maybe one should clarify this? Mstocker (talk) 07:47, 7 May 2009 (UTC)

Given the example in 14.10.2.1/1 of N2857, I think the quoted sentence is fine.Kxx (talk) 08:48, 7 May 2009 (UTC)

pack and unpack in variadic template

IMHO, the original description of pack and unpack operator in variadic template is wrong. The point is not the "..." at the left or right hand side of _type_, but the place.

For example, see template<typename... Params> void printf(const std::string &strFormat, Params... parameters);,typename... Params is the template "parameter", and Params... parameters is the function "parameter". "..." here are pack operators.

In printf(*s ? ++s : s, args...); and static const int value = 1 + count<Args...>::value;, arg... is function "argument" and Args... is template "argument". They are doing unpack.

Say "When the operator is to the right of the type, it is the "unpack" operator." is wrong because in the above, arg... is not collection of type.

That's what I have got after reading n2080(Variadic Templates (Revision 3)). I'm not a native speaker of english so my modification is in poor english and got rejected. :( Hope for some discussion and advice. —Preceding unsigned comment added by 220.135.250.105 (talk) 05:58, 11 June 2009 (UTC)

Take words from n2087(A Brief Introduction to Variadic Templates): "The ellipsis therefore has two roles: when it occurs to the left of the name of a parameter, it declares a parameter pack; when it occurs to the right of a template or function call argument, it unpacks the parameter packs into separate arguments." —Preceding unsigned comment added by 220.135.250.105 (talk) 06:14, 11 June 2009 (UTC)

Concepts

I've read here (http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441) that concepts have been voted out of C++0x. Should this article be updated to reflect that? Mattsnowboard (talk) 14:12, 18 July 2009 (UTC)

Yes, definitely. This is a monumental change. While blanket removal may be a bit drastic, everything indicates that concepts will not be a part of C++0x in any shape or form. decltype (talk) 03:39, 19 July 2009 (UTC)

The removal of concepts seems very solid. Unless they're not going to have C++0x for the next 3-5 years, it's gone. So I'm going to go ahead and remove the section, but leaving a note saying that it was removed. Personally, I think they made the right decision. C++ is more than templates, and concepts are *only* useful for templates. Concepts was slowing down C++0x, and it's best to just cut it and release it in a TR or something. Korval (talk) 01:30, 21 July 2009 (UTC)

The range-based for-loop now needs som clarification. 194.237.142.20 (talk) 06:43, 21 July 2009 (UTC)

You're right. Unfortunately, there is no paper (yet) on how "foreach" will behave now that concepts are gone. Korval (talk) 18:19, 21 July 2009 (UTC)

Sounds like a good decision (to remove it from the article, that is). decltype (talk) 09:59, 21 July 2009 (UTC)

The section should NOT be removed, since concepts are still historically relevant, and anyway the fallout from the committee vote will go on for ages. I just heard about the committee vote to remove concepts from the standard and came to the WP article to find out just what it was that had been removed (I'm a fairly low tech C++ user and wasn't familiar with concepts). It's pretty bogus to chop the section out of the article now that a bunch of us are here wondering what the fuss was about. To exaggerate a little, it's sort of like deleting Michael Jackson's biography because he died. (Note: having skimmed the deleted section, it looks like concepts are sort of like Haskell's type classes and associated types, and might have been a bit ambitious for C++. Maybe they will come back in some form someday.) 70.90.174.101 (talk) 05:48, 22 July 2009 (UTC)

You have a point, in that there should be something on the page that explains what Concepts used to be. But the original concepts section was a fairly detailed description; what is needed is just a brief glossing over of what the proposal was intended to do and how it would have done it. Korval (talk) 20:39, 22 July 2009 (UTC)

There were things that were initially planned for C++0x but were removed later, namely garbage collection and modules. I think it's worth having a separate section listing all these things, and the concepts should go there. Also, to avoid page bloat, this section should probably contain only links to separate pages where each feature will be described in detail. Enerjazzer (talk) 00:13, 23 July 2009 (UTC)

I've made the change [1] and created a separate page Concepts (C++0x). Please review. Enerjazzer (talk) 01:06, 23 July 2009 (UTC)

I'm not sure if it's a good idea to have a page for the Concepts proposal, but I know it's a bad idea to have C++0x in the title, since it's not going to be in C++0x. Also, the additions you made mention "Macro Scopes" as being postponed. What are those? I don't recall seeing a paper about a feature called that. Korval (talk) 05:03, 23 July 2009 (UTC)

To me (not only to me, actually: ...all expressed support for "concepts," just "later" and "eventually."...The discussion focused on timing and ... the vote was decided primarily on timing concerns), the importance of the Concepts is high and from what I see in the committee members' blogs, they will be reconsidered and moved back to the Standard at some point (maybe not in the same form). Regarding C++0x/C++ in the title - it's all up to you, I'm not a Wikipedia guru. Regarding "Macro scopes" - they were active until Portland meeting, 2006, the proposal is here [2]. With some other features, I didn't scan all past pages, but it's probably good to have the full list here. Maybe, not in the list markup, so save page space. Enerjazzer (talk) 00:08, 24 July 2009 (UTC)

I don't think there's any doubt that Concepts are important, and clearly meet our guidelines for inclusion. I therefore believe a separate article is appropriate. decltype (talk) 16:18, 25 July 2009 (UTC)

Thanks, moving it to a separate page seems reasonable. I added an introductory paragraph (feel free to change it) and will try to read the article more carefully in the next few days. The article should probably be recast somewhat to be more in the "past", but preferably with some references to how the idea might keep developing. It does seem like a worthwhile addition to the language, that was removed due to time constraints but may stay around in implementations and reappear in a future standard. Templates themselves were like that for quite a long time. 70.90.174.101 (talk) 06:15, 23 July 2009 (UTC)

Article moved from Concepts (C++0x) to Concepts (C++) per above. auto / decltype (talk) 12:36, 23 July 2009 (UTC)

Explicit virtual function overrides

I couldn't find any references about that (base_check, override and higind attributes) in the most recent working draft (N2914)... Has it been removed ?? Did I miss something ?

--Heretik 0127 (talk) 03:40, 17 September 2009 (UTC)

According to the minutes of the last meeting, the proposal has been voted into the WD, but the WD has not yet been updated with these features. There may be several entries that have been voted in but the WD does not contain them. Korval (talk) 19:35, 18 September 2009 (UTC)

undefined proposals

This article talks about yet to be defined proposals for certain features. the commitee does not accept any proposals other than those outsources from current proposals (as they are better handled as single proposals). therefore some of these features mentioned here are definetly not to be added to C++09. Also some of the features mentioned here will (if at all) only go into TR2 which will be *after* C++09. —Preceding unsigned comment added by 84.177.98.143 (talk • contribs) 22:48, 12 February 2007 (UTC)

null pointer constant (not "null pointer"!)

There are many very significant and sadly common errors in this section. This is shows a superficial understanding of C++. —Preceding unsigned comment added by 212.27.60.48 (talk • contribs) 07:04, February 11, 2009 (UTC)

null pointer constant (not "null pointer"!)

A null pointer is a possible value of a pointer:

int *p = 0;

if (!p) 
  std::cout << "p is null pointer\n";

A null pointer constant is an expression (used to set pointers to the null pointer value). It is not a value. (An expression is a part of the program source, while a value exist at runtime - except for some compile-time values of integral or pointer type.)

In C++98, a null pointer constant cannot have pointer type.

The whole section is about null pointer constants not null pointers. There is no change in C++ with null pointers. —Preceding unsigned comment added by 212.27.60.48 (talk • contribs) 07:04, February 11, 2009 (UTC)

integer vs. pointer

The statement foo(NULL); will call foo(int), which is almost certainly not what the programmer intended.

Since the dawn of C in 1972, the constant 0 has the double role of constant integer and null pointer.

No. 0 is not a null pointer, it isn't a pointer; it's integral constant expression.

It's very important not to confuse programmers about the fundamental fact that: The expression 0 never has a pointer type in either C or C++.

In either language, any expression (given a set of declarations of course) has only one type. For the expression 0 the type is always int, end of story.

That you can write :

void foo (int*);

foo (0);

doesn't mean the expression 0 suddenly has type int*, just as 1 doesn't has type float in the following:

void foo (float);

foo (1);

the preprocessor macro NULL, which expands to either ((void*)0) or 0.

...or OL or ((short)0) or (2*2-4) or ((void*)(2*2-4)) or any integral constant expression (compile-time computed expression with type char, short, int, long, unsigned char...) with value 0, or any such expression casted to void*.

However, the only two common choices in C are 0 or ((void*)0).

When C++ adopted this behavior, additional ambiguities were created due to other design decisions in C++. Implicit conversion from type void* to other pointer types is not permitted, so NULL must be defined as 0 in order for statements like char* c = NULL; to compile.

No, this is unrelated and a deep mistake (and BS made confused statements about it).

In either C or C++, an integer (an arbitrary expression with integral type) isn't convertible to a pointer :

int i = 0;
int *p = i; /* error in both C and C++ */
int *q = 0; /* ok */

but the expression 0 is convertible to a pointer, because it's a null pointer constant.

So it's only a matter of how null pointer constants are defined. Had C++ (BS) defined ((void*)0) as a null pointer constant, the following would be valid:

int *p = (void*)0;

BS didn't made this choice, the committee didn't revisit his decision, but to say this was about converting void* to T* is dishonest. It was and is only about the definition of null pointer constants. —Preceding unsigned comment added by 212.27.60.48 (talk • contribs) 07:04, February 11, 2009 (UTC)

Overloading

void foo(char *);
void foo(int);

The statement foo(NULL); will call foo(int), which is almost certainly not what the programmer intended.

Not so fast! Only true if NULL is defined as 0 or (2*2-4) or ((short)0).

If NULL is defined as 0L, for example, the first function will match with a pointer conversion (long -> char*), and the second with an integer conversion (long -> int); both implicit conversion sequences have conversion rank, and none is better than the other. As no match is better than all others, the call is ambiguous.

C++ compilers usually simply define NULL as 0 but they don't have to according to C++98 or C++03, so the statement needs to be qualified properly. —Preceding unsigned comment added by 212.27.60.48 (talk • contribs) 07:04, February 11, 2009 (UTC)

Deprecation

If the new syntax is a success, the C++ committee could declare deprecated the usage of 0 and NULL as null pointers, and eventually abolish this double role.

Very funny indeed!

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

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)

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)

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)

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)

Current status of this issue: resolved.

Almost 100% compatible?

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)

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)

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)

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)

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)

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)

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)