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]

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.

"For example, a std::vector is, internally, a wrapper around a C-style array with a size. If a vector temporary is created or returned from a function, it can only be stored by creating a new vector and having it copy all of the R-value's data into it. Then the temporary is destroyed, deleting its data."

This example is just stupid, because copy-on-write makes the trick right now in old C++. I don't see the point of the move stuff from it... 192.100.124.218 (talk) 14:20, 16 March 2009 (UTC)[reply]

COW will work until you start changing the vector. Consider a function append that takes a vector, appends an element to it and returns the new vector. In COW, it will copy the whole vector every time you execute push_back, even if the original vector is temporary and you don't care about preserving its contents. With rvalue reference, no copy will be done if a temporary is passed, so you can write like this: append(append(append(std::vector<int>(),1),2),3); and there will be no copies made. Try to achieve this with COW. Enerjazzer (talk) 00:40, 12 June 2009 (UTC)[reply]

I was under the impression that a copy-on-write implementation of std::vector would be near-impossible to make. Consider the fact that a user can obtain a pointer to an element of the vector at any time using either &v[n] or &*iter. This pointer must remain valid until a reallocation or an insert in front of the pointee takes place. The same applies to iterators and references. I don't see how an efficient COW implementation can preserve these semantics. Perhaps you were referring to return value optimization, which will probably eliminate the copy in the quoted example decltype (talk) 15:24, 16 March 2009 (UTC)[reply]

I dont see your point. COW is about copy data only if necessary. Pointers and iterators will stay valid for the current container, even if another one (which refers to the same array) makes some writing: cow will cause that it will be than reallocated and copied, but the pointers and iterators will point to the original. In assigments what you change is only a pointer, returning from a function is an assigment (if there is anyone who wants to use the return value).

192.100.124.218 (talk) 09:53, 17 March 2009 (UTC)[reply]

Consider the following example:

decltype (talk) 10:11, 17 March 2009 (UTC)[reply]

In this case, const int& operator[] will be called, so the compiler can assume you wont do any writings. If you get the adress of a const&, its up to you if you want to write on it, so no copy will needed. Im not even sure you can get the address of a const with a non-const-pointed pointer. But this is considered hacking in my terms... 192.100.124.218 (talk) 12:51, 17 March 2009 (UTC)[reply]

No, a copy has to be made even after a call to a operator[] const. Even something like int i = *p; would have undefined behaviour if no copy was made. decltype (talk) 13:06, 17 March 2009 (UTC)[reply]

Otherway, i dont understand you. If you swap the v1 with an empty vector, what does that to make with p? v2 will hold the area, and the unnamed vector too, till the end of the scope. p is not invalidated... 192.100.124.218 (talk) 08:30, 20 March 2009 (UTC)[reply]

No, the unnamed temporary is destroyed at the end of the full-expression, not the enclosing scope. The following example demonstrates the same, but is less subtle:

decltype (talk) 08:40, 20 March 2009 (UTC)[reply]

No, the line v1 = vector<int>(); wont free the memory used by v1, because v2 still points to it. v1 knows that someone else points to its buffer, so wont free it. 192.100.124.218 (talk) 12:05, 20 March 2009 (UTC)[reply]

Try this example:

Can a COW implementation deal with that? -- BenRG (talk) 12:25, 20 March 2009 (UTC)[reply]

Well, if it makes a copy even for operator[] const it should...but that wouldn't be copy-on-WRITE. Which is what I was trying to prove, but failed :) decltype (talk) 14:38, 20 March 2009 (UTC)[reply]

I dont see the point in the example. Lets see what happens. v1, v2 points to the same area on the first line. You give other, const names for v1 and v2, doesnt really matters. You point to the common area with 2 vectors. After that, you change a vector what should be considered const. Do you see my problem with that? C++ is not so hard to hacked, its in the language to give you opportunities. You can always write a const variable with some extra effort, but than the responsibility is on you. Here the v1[42] call is not the const one (obviously), so there will be copy made. Obviously. Iterators/pointers invalidated. Obviously. What did you proved here? Maybe you are right, but i really dont see :( 192.100.124.218 (talk) 15:22, 20 March 2009 (UTC)[reply]

Non-const std::vector<T>::operator[] can't make a copy because it's not allowed to invalidate pointers into the vector. (To put it another way, my example doesn't invoke any undefined behavior.) Non-const std::string::operator[] does invalidate pointers into the string; they made that provision specifically to allow copy-on-write implementations of std::string. But there's no such provision for vectors.

(Even if vectors had been defined differently, the copy-on-write approach would reduce the cost of vector moves but increase the cost of every non-const vector operation. Move semantics reduces the cost of vector moves without any downside.) -- BenRG (talk) 19:34, 20 March 2009 (UTC)[reply]

They at least considered removing the possibility for cow strings for concurrency reasons, N2668[[1]] - and as such I would suspect cow vectors would fare no better. I do not know how to find out if this was accepted or trashed, though. --84.209.14.149 (talk) 14:56, 26 March 2009 (UTC)[reply]

Look, it doesn't matter if a COW implementation of std::vector would be the effective equivalent of what you get with std::move. The fact is that std::move is useful for far more than just the std::vector example. std::auto_ptr, for example, benefits greatly from it, as do similar RAII structures. Even std::shared_ptr passing will be faster, since you don't have to bump a reference count and then decrease it again after the temporary is destroyed. The std::vector example is an easily understood one, which is why I choose it, but it is hardly the definitive value of std::move. The solution to the forwarding problem alone is justification enough for it. Korval (talk) 18:38, 20 March 2009 (UTC)[reply]

I agree. It's a good example, and one of the most oft-cited. Still, in the trivial case, RVO would take precedence and eliminate the copy/move. I also very much like the fact that you can store movable objects like streams in a vector, because of RR. It's a very visible change that you don't have to understand RR at all to benefit from. Of course, for full benefit you'd have to know how to make your own objects movable. decltype (talk) 20:09, 20 March 2009 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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]

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

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

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

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

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

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)[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" [2][3][4], 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]

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: [5] (page 17) and this [6] (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]