User talk:Cubbi




Hi! Welcome to the wiki. Your contributions look awesome:) Just one note: could we have only one example per page? It can quickly become a mess, especially if these examples demonstrate more or less the same feature used in the similar way.P12 14:29, 17 August 2011 (PDT)

No problem, I felt that the return value of std::for_each deserved a special mention since so few people even know it exists, but it's true that for the most part that example was a duplicate. I don't mind it gone or anything -- I just put it together on the spot. Also, nice to know I can use range for loops here! --Cubbi 14:41, 17 August 2011 (PDT)
Well, any feature in C++11 can be used, provided that the examples become simpler. After all, it's not the for loop that is being demonstrated, but the particular function, so there should be as little auxiliary code as possible.P12 14:53, 17 August 2011 (PDT)
Incidentally, why do so many examples here use std::endl where '\n' is implied? It makes it look unprofessional, as if the next line is going to be system("pause") --Cubbi 19:43, 17 August 2011 (PDT)
Did you mean that there's no reason to use std::endl as '\n' is a shorter alternative, or that there's no reason to output newline at the end of the program? The former choice actually has no strong rationale behind, just I felt that std::cout is better for the examples. As for the second, most examples would be run only in interactive mode and most probably not edited in any way, so the newline helps produce clear output. Compare:
p12@p12-laptop:~$ ./a.out 


p12@p12-laptop:~$ ./a.out 

P12 01:25, 18 August 2011 (PDT)

I mean that << std::endl is premature pessimization: it is, by definition, equivalent to << '\n' << std::flush and flush is only needed before system("pause") and in some other multiprocessing/multithreading situations or when debugging a program that segfaults (in which case always-flushed cerr works better anyway). Stroustrup's "hello world" uses \n in "The C++ Programming Language". Also, recent discussion on SO and a not so recent one --Cubbi 06:53, 18 August 2011 (PDT)
Well, I wasn't aware of that. Let's dump std::endl then. I'll instruct my bot account to search/replace every occurrence of std::endl with '\n', except where std::endl is indeed intended.P12 07:43, 18 August 2011 (PDT)

Lambda / Example

Hi! Good point on the std::function usage being already promised. //

Nitpick: isn't it better to say "stored" instead of "captured" in "captured in std::function"?

Clarification: shouldn't we at least say that there's a difference between these two cases? Note that std::function in this case can introduce severe inefficiencies (regardless on whether it is common or not, this makes it a bad practice, IMHO).

Compare the results of the following benchmark:

Further references:

// Edit: if we do decide that keeping it is a good idea (I'm not convinced), I think <functional> header needs to go back in, too.

// Request for clarification: just to make sure I'm not breaking any rules, is it better to discuss issues like this here or at the page-specific discussion section? // which would be

Note I'm not trying to be pedantic, my thinking is simply that we should strive to provide "the best practices" code in the examples whenever possible (unlike that certain other C++ reference...) and it seems to be possible in this case.

Md 13:14, 1 May 2013 (PDT)

You're right about the header of course (I tested with gcc and just pasted it as-is), and yes, discussion of language/lambda is better on the language/lambda's talk page -- that's where visitors would look for comments and opinions such as these. std::function of course has the potential for overhead, but I think the best place to expand on that is std::function's main page, in a ===Notes=== section, where implementation details and caveats would be appropriate (e.g. compare to std::shared_ptr's Notes). Wrapping a lambda in a function is not justified in the example, but it is justified in enough real-life use cases (to pass to a non-template function, to apply std::not1, etc) --Cubbi 14:13, 1 May 2013 (PDT)

"must return"?

Regarding the comment on this and other diffs. int main() does not require a return statement, Not in C (since 1999), not in C++ (ever). Stroustrup's "hello world", again, has no return statement. But if its a good idea to have all code here include that statement, Help:Manual of style needs to be updated. --Cubbi 14:20, 23 August 2011 (PDT)

Oh great. I must have wasted a lot of return statements. If they are not mandatory, we can omit them. BTW, could you start discussions like this in my talk, so that I get a notification?P12 02:09, 24 August 2011 (PDT)
Okay. BTW, the reference for it: 3.6.1[basic.start.main]/5 (same in C++03 and C++11) "If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;" --Cubbi 03:17, 24 August 2011 (PDT)

using std::less in std::lower_bound

Is this edit correct? What if the argument types to std::less are not convertible to each other, yet have a comparison operator defined? Is there's a solution to that problem?P12 14:43, 24 August 2011 (PDT)

You're right, that less is missing the second type. In LLVM's libc++ library, the first form of std::lower_bound is defined exactly this way:

template <class _ForwardIterator, class _Tp>
lower_bound(_ForwardIterator __first, _ForwardIterator __last, const _Tp& __value)
    return _VSTD::lower_bound(__first, __last, __value,
                             __less<typename iterator_traits<_ForwardIterator>::value_type, _Tp>());
I'll edit accordingly. --Cubbi 15:15, 24 August 2011 (PDT)

Oh, wait, standard less only takes one argument.. --Cubbi 15:18, 24 August 2011 (PDT)
So it looks like we'll have to duplicate this one, or come up with a two-argument functor or lambda just for the sake of that one example equivalent function. --Cubbi 15:24, 24 August 2011 (PDT)
So let's keep the duplicate then. Unrelatedly, I think there's no need to have exact permutation, sort and other long algorithms outlined in the equivalent function section. They're too complex for anyone to grasp quickly, so it might be a better idea just to leave a 'black box' instead.P12 15:38, 24 August 2011 (PDT)
Even std::random_shuffle can be hard to grasp if you're unfamiliar with Fisher-Yates-Knuth algorithm. I think implementations of the permutations are rather simple for what they do, and to me it was educational to learn how the three permutation functions are implemented (identically in both libraries I looked at, too). I agree about sorts, stable_partition, and anything that does something different "if additional memory is available" - those are complex and they are implemented differently in different libraries. If I were to cut one, I'd cut std::minmax_element, it's too complex for what it does. But there's so much work to be done on this wiki still, it feels like a minor thing anyway. --Cubbi 18:57, 24 August 2011 (PDT)
Ok, after coming across the page of std::is_permutation I reversed my opinion. The algorithm is quite clear if there are some comments about how the code works. Maybe all we need is a very short explanation above the code for the most complex functions? Anyway, equivalent functions, like examples, reside at the very end of the page, so they aren't really important. Since probably the only people, who will come across those sections, are the ones who're looking for additional reference, lots carefully selected information will be certainly beneficial.P12 13:03, 25 August 2011 (PDT)

wide character strings

Wide character strings are not the same as multibyte character strings. There are actually three character string types:

  • character / byte / narrow-character null-terminater string, e.g. ASCII-8
  • multibyte null-terminated string, e.g. UTF-8
  • wide / wide-character null-terminated string, e.g. UCS, UTF-16, etc.

Multibyte character string is like an 'extension' to regular byte character strings, since a multibyte character string is always a valid byte character string, so it is can be processed by all functions at cpp/string/byte, but not the functions at cpp/string/wide.

Anyways, this is a quite complex subject, it needs to be explained better in the article lead sections.P12 15:49, 2 September 2011 (PDT)

You're right, the definition of NTMBS is not suitable for string/wide at all. An NTMBS is more like what a std::wstring_convert().to_bytes() would produce from a wchar_t[]/wstring. But yes, it would be nice to detail the differences between C++'s four character types and the data that can be stored in them. --Cubbi 16:44, 3 September 2011 (PDT)

Template:ddcl list namespace

Hi. My edits adding {{ddcl list namespace}} were a mistake, since the namespace can easily be deduced from the page title as is done e.g. std::this_thread::sleep_for. I'll revert them. Sorry for inconveniences.P12 13:34, 4 October 2011 (PDT)

Ah, okay, sorry about running along with it. --Cubbi 13:36, 4 October 2011 (PDT)

{{param none}}, {{return none}}, {{throw none}}

Hi. I decided that {{param none}}, {{return none}}, {{throw none}} serve no purpose as the current style is adequate and probably won't change in the future. I'll replace these templates with the text they resulted in - (none). I hope this will make editing easier. P12 13:03, 11 October 2011 (PDT)

Re. mem=

Hi. I've fixed the inconvenience caused by the necessity to use mem parameter in the dcl list mem * templates. Now if a dcl list mem * template is placed in a page which is not a sibling or parent of the target page the template links to, member of std:: is added automatically. E.g.

Template:cpp/memory/shared ptr/dcl list get

So the mem= parameter is not needed anymore. P12 13:23, 19 January 2012 (PST)

Cool, thanks. I wish i could understand that code you just changed! --Cubbi 13:27, 19 January 2012 (PST)
The idea is not very complicated, the syntax is. The dcl list * templates always get a path to function/class page they represent. When used, the template now checks whether the target page and the page they are used in have common ancestor. If yes, everything is as in the past. Otherwise, the template acquires and displays the name of the parent class of the target page. Here it knows that if we have a/b/parent/member_function, then there's always Template:a/b/parent/title and if the title template gets #MAGICTITLESTRING#, then it just yields in the part of the title which would be displayed in the smaller font. So for e.g. {{cpp/container/vector/title|#MAGICTITLESTRING#}} we get std::vector which is what we want. P12 16:50, 19 January 2012 (PST)

sorry for being such a pain

I'll try to avoid making radical changes without searching first. I need to actually look more into the standard before modifying things. >.< --- Undeterminant 12:29, 11 February 2012 (PST)

adding a function or two is nothing radical. It's a wiki. If someone thinks it can be improved, they will. --Cubbi 12:32, 11 February 2012 (PST)

operator++ with or without (int) overload in links

Hey, thanks for all the work on the iterators. I only wondered why you put the (int) overloads into the links for the ++ operators, for example

advances the iterator
(public member function of std::reverse_iterator)

Usually the overloads are not specified in the links (e.g. constructors, operator[]).

Would you be ok, if I started changing this to the shorter version below?

advances the iterator
(public member function of std::reverse_iterator)

Or are there some caveats that I missed?

Tobi 03:23, 3 April 2012 (PDT)

They are not overloads, they are post-increments. Post-increment and pre-increment are fairly different (but not different enough to have separate pages).. On second thought, I suppose it does clutter the link unnecessarily. Ultimately, style decisions are up to P12, I'm just an editor. --Cubbi 05:43, 3 April 2012 (PDT)

Russian translation

Hi. Could you take a look at the Russian wiki and translate the most frequently used templates if you have time? Most of the templates are only few words or sentences, so the translation would need at most several tens of minutes. I then would import the rest of the English content and add some advertising at the Dokuwiki version too gather attention of other editors. Thanks! -- P12 09:37, 25 April 2012 (PDT)

I started, but can't promise to be fast. --Cubbi 10:40, 26 April 2012 (PDT)
Nevermind, I think Krtkr won't return anytime soon. I'll just import the current content of Dokuwiki. -- P12 10:20, 30 April 2012 (PDT)

Svg conversion of the File:Streambuf.png

Hi. I've created an explanatory image for std::basic_streambuf based on your initial draft. Your image was really helpful, thanks! P12 18:02, 16 May 2013 (PDT)

Alas, poor dynarray

...we hardly knew ye. I wonder if it makes sense to leave the std::dynarray and std::optional content in place (with the hope that at some point they'll return) and just attempt to remove other links to/uses of them? --Nate (talk) 17:06, 30 September 2013 (PDT)

I vote for leaving the content in place. There are lots of links to these pages over the internet already and people who come through them won't like 404s being served. We could even replace the (since C++14) tags with something like (removed from the standard draft). --P12 18:28, 30 September 2013 (PDT)
It's getting moved to a separate TS (along with some other things that got dropped from the WP), so it's still going to exist and worked on, just not getting released in C++14.. Until there's a new draft to reference, I'd keep it, maybe with a note that it was voted out as far as we know. (here's relevant StackOverflow chat session where I picked that up - scroll up for more notes about Chicago) --Cubbi (talk) 18:29, 30 September 2013 (PDT)
Another prooflink (from gcc library maintainer, regarding dynarray and VLA): --Cubbi (talk) 07:17, 1 October 2013 (PDT)
Any information on why optional got mothballed too? As opposed to dynarray, it doesn't look like a risky addition without implementation experience. --P12 09:03, 1 October 2013 (PDT)
Two National Bodies comments were asking for (more) relational operators for it, and there was a pre-Chicago paper about all the different approaches to that, sounds like no consensus. SO chat suggests that, too --Cubbi (talk) 09:28, 1 October 2013 (PDT)

C++14 status

Just out of curiosity, do you have any estimates how much C++14 stuff we're still missing? --P12 13:57, 10 November 2013 (PST)

I just went up the Chicago issues in libc++'s checklist today and added whatever I found missing in the library, I didn't double-check every earlier issue, but I think the library is actually complete at this point (although a few simple redlinks remain, e.g. the literals for complex numbers and some durations). Core language is certainly missing some C++14 improvements (polymorphic lambdas and return type deduction in functions, for example), but it's work in progress anyway --Cubbi (talk) 17:02, 10 November 2013 (PST)
Thanks. I guess it's time to update the news template. --P12 03:07, 11 November 2013 (PST)

Mistakenly reverted edit

Sorry for this, it was an accident :) --P12 16:52, 20 February 2014 (PST)

Must we enclose some big chapters with {{rev}} template (such as in [1])?

I realized that it is for gadget StandardRevisions and it does look nice in C++03, C++11 and C++14 mode. But if someone view the page in the default mode, I'm afraid it would be a little difficult for him to find the (since C++14) sign and it would be confusing. --D41D8CD98F (talk) 20:05, 6 June 2014 (PDT)

actually that part could use both the (C++14) right on the heading and the rev box for the gadget. Perhaps you can bring it as a case study to Talk::Main_Page to revive the old revbox discussion/brainstorming. Good work by the way. --Cubbi (talk) 21:00, 6 June 2014 (PDT)
Thank you. The link is really informative. I've added a section in Talk:Main Page to discuss this issue.--D41D8CD98F (talk) 00:30, 7 June 2014 (PDT)

Contributions to the standard revisions gadget


I'd like to commit this change to the cppreference-doc Github repo. What name and email should I use to attribute your contributions? Cheers. --P12 15:16, 18 November 2014 (PST)

It's about time I started using this github thing myself. --Cubbi (talk) 19:39, 18 November 2014 (PST)

Automatically linking _t aliases

Right now, std::add_pointer<int> automatically links std::add_pointer, but std::add_pointer_t<int> doesn't. I believe this takes an admin to fix :) T. Canens (talk) 14:13, 7 July 2015 (PDT)

correct, if no one else from admins does that first, I'll go over the _ts from type_traits. --Cubbi (talk) 14:21, 7 July 2015 (PDT)

Conjunction in odr-use

Hi, I've made an edit that changes the meaning of some of your text:

This arose at where the asker was (rightly) concerned about a contradiction between the Standard, SO and cppreference. I think my change makes it clearer and more correct but thought I should give you a heads up in case you want to make further changes.

I wonder whether we should further expand on the "potential results" business - it's come a long way from the original meaning of the two legs of a ternary, but perhaps some mention of that evolution might help readers understand what the text in the Standard is trying to accomplish. (talk) 04:31, 13 July 2015 (PDT)

Thanks for editing! Yes, it would be very helpful to drop in a note explaining the intent: I feel a little bit defeated whenever standardese appears here without any sort of informal summary or background info (ODR here begins with an informal summary) --Cubbi (talk) 07:17, 14 July 2015 (PDT)

Updates to indexes

Hi. I've synchronized the new API you've added to the search indices with the XML files in the cppreference git repo and only now noticed that you've likely edited the XML too instead of some manual way. Could you please do a PR to the github repo so that the effort is not duplicated? Many thanks for all the improvements! Cheers. --P12 18:56, 7 August 2015 (PDT)

it was actually manual (hence "fingers crossed" in my edit summary!), well, vim-assisted --Cubbi (talk) 22:17, 8 August 2015 (PDT)

Member access operators

Could you please stop canceling all my work on this page? You can correct my edits, but please don't cancel everything without reading my improvements, especially when you bring back a version that is less consistent.

1. You state that the subscript operator is not only for arrays. No problem, but then please be consistent and remove the word "array" in the summary table. Because the current situation is "array subscript" in the table, "Built-in subscript operator" in the title of the section and "Array subscript operator provides access to the elements in the internal array" in the explanation. What a mess for the reader!

2. I corrected the prototypes of the summary table from this source: [2] so please don't revert my edit or improve it from a better source. Plus I added missing semi-colons in the last prototypes of the tables and you reverted it, this is counter-productive.

3. In the 1st paragraphs of the sections "Built-in member operators" and "Built-in pointer-to-member access operators", the description of the operands are not in the same order, that's why I changed it (1st—or left—operand THEN 2nd—or right—operand for BOTH sections) but you reverted my changes again. Please.

4. In these same two sections, I used the same symbols "A" and "B" and you are persisting to keep "expr" and "member" in the 1st section and "E1" and "E2" in the 2nd section. I have nothing against these symbols, but again be consistent in your notations and use the same identifiers for the two sections (either textual identifiers or symbolic identifiers, but not both!)

5. I insist: please be consistent!

6. By the way: I appreciate your other corrections on the other pages that I edited.

Maggyero (talk) 13:11, 26 August 2015 (PDT).

Yes, I was a little jumpy after the mess at value_categories and various earlier problems with your edits, sorry about that. This edit ([3]) was in fact mostly viable and I restored much of it after giving it some thought.
1 The summary table and the "explanation" blurb under it shouldn't say array, that's a good point. They haven't received much attention over all.
2 Wikipedia's C and C++ pages are bad sources. Cppreference:FAQ here explains where to get actual language specs.
3 The loss of the link to id-expressions and of the note on evaluation of the left operand were the main triggers for the revert. I did restore your general wording later after bringing back that lost content.
4 the right-hand operand of the member access expression is a very special beast, it is nothing at all like the operands of all over operators used on this page: the other operands are expressions that can perform arbitrary computations, but this operand is just the name of a member. I couldn't find a clear single-letter way to describe that differently from how the other expressions are described, so I used words. Perhaps a better approach would have been to use syntax parameter templates (expression . member-id), but that ended up unappealing too. The grammar still classifies the second operand as an expression (id-expression) and designates "E2" when described in the standard, so I restored your E2. --Cubbi (talk) 13:36, 26 August 2015 (PDT)
Thank you for the restore and the information, especially the FAQ advice. I have just downloaded the last Working Draft of C++ 14 so now I have THE reference and I will be able to make fewer errors :).
Maggyero (talk) 03:31, 27 August 2015 (PDT).
Good, the other extreme to avoid is copying too much standardese since it is often incomprehensible (try reading through 14.7.3[temp.expl.spec]/7!). See the poll I started at Talk:cpp/language/operator_member_access#Naming_bikeshed (I don't care that much about address-of's name to be honest, but saying "address-of" helps connect it mentally with its better-behaved cousin std::addressof) --Cubbi (talk) 03:39, 27 August 2015 (PDT)
Hi Cubbi! I have just answered on my talk page about your last comments.
Maggyero (talk) 16:47, 18 September 2015 (PDT)

Value categories

Hi Cubbi. My edit on the Value categories page was only about member access operators in order to make the statements match with the ones that are on the Member access operators page. I also uniformized the wording (the word "first operand" "second operand" was used everywhere in the page except in member access operators) and only changed the order of some item so that everything is symmetric for the 3 primary categories. Then I replaced the vague "some ternary conditional expressions" with the exact cases (it holds in a very short sentence so there is no need to remove the details) like for all the other operators. Finally I added a forgotten prvalue in the list: the one that is used for the pseudo destructor call. So except for this new prvalue I didn't really add or change anything apart for the style, it's just more consistent so easier to read. Should I split this edit in several small edits like they are in this step-by-step explanation?
Maggyero (talk) 18:02, 19 September 2015 (PDT).

It was a complex disruprive edit made to a sensitive page with no prior discussion. Changes to the conditional were wrong (it's "some" for a reason), changes to member access removed content. Granted with all these non-technical edits from last month, it's becoming increasingly hard to even understand what those sections is talking about, it should really go back to what it said before august. Pseudo-destructor is covered by the PMFC section and does not belong with regular rvalues. I don't agree with the reordering either, but it wasn't a technical error. --Cubbi (talk) 19:38, 19 September 2015 (PDT)
Just to elaborate on the conditional part, since I'm the guy who introduced the "some ternary conditional expressions" wording: a correct (I think) description of when an conditional expression is an lvalue is
  1. if one of the second and third operands is a (possibly parenthesized) throw expression, and the other one is an lvalue; or
  2. if the second and third operands are lvalues of the same type; or
  3. if the second and third operands are lvalues of the same type except for cv-qualification, and one is more cv-qualified than the other; or
  4. if the second and third operands have different types, at least one of which has a class type, and one of the second and third operands (call it X) is an lvalue of type T, and the other operand (call it Y) can be unambiguously converted to the type T&, subject to the constraint that the reference must bind directly to an lvalue, and Y cannot be converted to match X.
And I even cheated a little above by not describing what "Y cannot be converted to match X" actually means. I think you can see why I went with the vague version instead.

While we are here, I'm not really a big fan of the current wording at cpp/language/operator_other#Conditional_operator. The previous version was inaccurate in a number of ways, so I rewrote it by tracking [expr.cond] pretty much exactly, and the new version is probably correct, but it's also pretty dense and hard to understand. If anyone knows a way to simplify it without sacrificing correctness, I'm all ears. T. Canens (talk) 00:55, 20 September 2015 (PDT)

1. Since the standard states, § 5.16. "Conditional operator", alinea 4, 5:
"If the second and third operands are glvalues of the same value category and have the same type, the result is of that type and value category and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields. Otherwise, the result is a prvalue."
I thought it was a sum up for all cases (especially for the void cases listed in alineas 2 and 3), but apparently not (so I find the standard a little messy about the value categories here). So OK Cubbi an T. Canens, no problem for keeping the vague "some ternary conditional operator expressions".
2. OK Cubbi, if it does not really belong to "real" prvalues I will remove the special kind of prvalue I introduced.
3. OK Cubbi, for the moment I will keep the order as it was because it makes the edit very hard to read for everyone with the comparison tool, and we will come back to it later.
4. Not OK Cubbi about the "changes to member access removed content". I have only replaced the "every member access operators except" by "member access operators where" like it is in all the other items (consistency), but if you check with care I have not forgotten any case.
Maggyero (talk) 03:33, 20 September 2015 (PDT).
You lost the value categories of a->b and a->*b by writing "using operator ." and "using operator .*" in the wrong place. Also, you added text where this page really needs a lot less text than what it has today: it is not a page about member access or about ?:, it shouldn't duplicate technical details covered on the pages it links to. --Cubbi (talk) 06:13, 20 September 2015 (PDT)
You say that I lost the value categories of a->b and a->*b by writing "using operator ." and "using operator .*" in the wrong place, that is to say the value categories of the first operand, but a->b and a->*b are automatically converted to (*a).b and (*a).*b and in the Member access operators page the value categories are always given for E1.E2 and E1.*E2, that is for the first operand E1 = (*a) and not for E1 = a, so that we don't care about the value category of E1 = a and therefore about the operators a->b and a->*b. For this reason we have to write "using operator ." and "using operator .*" everywhere the first operand is mentioned. With the old wording of the page Value categories, there was no need to precise "using operator ." and "using operator .*" for listing the lvalue cases because they were listed negatively ("everything except…") and these exceptions do not depend on the first operand. But when listed positively (nothing except…) some lvalue cases depend on the first operand so it has to be explicitly said that this first operand is the one of the operators . and .* (after possible conversion from -> and ->*) and not of the operators -> and ->*. And by the way, the old wording (the current one actually, since you undid me) did have an error:
"a built-in pointer-to-member access operator expression where the first operand is an lvalue and the second operand is a data member;"
is a wrong statement since in the Member access operators page which has the same statement it is explicitly written that the operands that we are talking about are "In the expression E1.*E2:" (so after possible conversion from a->*b). So actually my last edit did correct one error but didn't introduce new ones.
Maggyero (talk) 14:21, 20 September 2015 (PDT).
There is no "automatic conversion" here, you are mixing up unrelated concepts. Yes, the word "pointer" is missing, that would have been an acceptable edit. --Cubbi (talk) 19:11, 20 September 2015 (PDT)
Could you elaborate on this because I am not sure that I follow you here. To my understanding, since the standard explicitly states, § 5.2.5. "Class member access", alinea 2.:
"The expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of 5.2.5 will address only the first option (dot). Note that (*(E1)) is an lvalue."
that means that the second option (arrow) is addressed the same way, considering as the object expression (*(E1)) instead of E1. So for instance the statement given in the standard for the first option (dot, that is E1.E2), § 5.2.5. "Class member access", alinea 4.2.:
"If E1 is an lvalue, then E1.E2 is an lvalue; otherwise E1.E2 is an xvalue."
would become for the second option (arrow, that is E1->E2 = (*(E1)).E2):
"If (*(E1)) is an lvalue (which is always the case), then E1->E2 is an lvalue; otherwise (which is never the case) E1->E2 is an xvalue."
But according to you, the statement given for the first option would remain the same for the second option (arrow, that is E1->E2 = (*(E1)).E2):
"If E1 is an lvalue, then E1->E2 is an lvalue; otherwise E1->E2 is an xvalue."
Did I understand you correctly? Do you confirm that my understanding of what is happening for the second option (arrow, that is E1->E2) was wrong?
Maggyero (talk) 01:34, 21 September 2015 (PDT).
I think you're off-track. The built-in a->b can be lvalue or prvalue, depending on what b is (e.g. memeber variable vs. member enumerator). The edit I reverted removed a->b from the value categories page (and I admit it's badly represented there, hidden in semi-standardese "member access operator expression". We'll look at it after cppcon). --Cubbi (talk) 15:16, 21 September 2015 (PDT)
Alright. However I think you have not read my last answer correctly (or maybe I was not clear enough). I have never said that a->b cannot be a prvalue. The statement that I quoted from the standard was in the context of E2 being a non-static data member of non-reference type of course. So maybe I should reformulate my question better: when E2 is a non-static data member of non reference-type, what is the value category of E1->E2? The standard only address this case for E1.E2, stating:
"If E1 is an lvalue, then E1.E2 is an lvalue; otherwise E1.E2 is an xvalue."
So in other words, what this sentence would become for E1->E2?
  • This?
"If E1 is an lvalue, then E1->E2 is an lvalue; otherwise E1->E2 is an xvalue."
  • Or that?
"If (*(E1)) is an lvalue, then E1->E2 is an lvalue; otherwise E1->E2 is an xvalue."
If it would become the latter, since (*(E1)) is always an lvalue anyway, then E1->E2 would always be an lvalue (when E2 is a non-static data member of non-reference type).
— Maggyero (talk) 01:54, 22 September 2015 (PDT).