User talk:Maggyero

Plese fill edit summaries=

Your last 43 edits had empty summaries, it is often hard to understand the reasoning behind them. If you go to Special:Preferences#mw-prefsection-editing, there is a checkbox "Prompt me when entering a blank edit summary", which may be helpful. --Cubbi (talk) 07:52, 23 December 2015 (PST)

Thanks for the advice. It was mainly formatting edits but I should have indicated it anyway.

Maggyero (talk) 08:05, 23 December 2015 (PST).

Please be more careful with edits

Your edits [1] and [2] introduced compilation errors to previously working examples. Please at least use the Run this code button before submitting an edit. [3] also broke code examples (those didn't have a Run button, though). This edit: [4] changed (and broke) the anchors in multiple wikilinks to other pages. Please take better care when editing. --Cubbi (talk) 14:32, 25 August 2015 (PDT)

Okay, thanks for the corrections. Maggyero (talk) 13:31, 26 August 2015 (PDT)

Your edit to cpp/language/pointer once again introduced compilation errors to previously working examples. --Cubbi (talk) 19:29, 15 September 2015 (PDT)

9/17/15

Could you please explain the motivation behind the 9/17/15 edit? It was titled "improvements from the standard" and included the following changes (ignoring added wikilinks, which were redundant, but not disruptive, and "pointing at" changed to "pointing to" which is indeed the proper wording)

Yes, sure. I am referring here after to the ISO/IEC Working Draft, Standard for Programming Language C++, number N4140.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

-) Built-in member of pointer and pointer to member of pointer operators

+) Built-in member of pointer and built-in pointer to member of pointer operators

what was wrong with the existing sentence? what makes the new sentence better?

OK: I wanted to highlight that the "built-in" adjective applies to both names, but maybe that was not necessary (English is not my mother tongue).

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Right, it doesn't make it technically wrong, just a little less grammatical (the subject of the sentence is "operators"). If you had made just this edit with the comment above, I would've ignored it, this wiki is full of awkward grammar, as it's a secondary concern. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

-) The second operand of both operators must be an [[../identifiers#In_expressions|id-expression]]

+) The second operand of both operators is an expression

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: I wanted to be consistent, because if we want to be precise and write id-expression for the second operand of the member operators we must keep that precision for the pointer-to-member operators and write cast-expression for their second operand too (according to the standard). So we have to make a choice here: either we write id-expression for member operators and cast-expression for pointer-to-member operators, either we simply write expression for both, but not precise id-expression for the first and unprecise expression for the second as it was the case, or vice versa.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

This introduces an error. By saying that rhs is an "expression", you're saying that these operators may evaluate their right hand operands, but even a.(b) or p->(b) are invalid. The acceptable choice is here is between the human-readable "name" and the standardese "id-expression". I would rather see it go back to "name", which is what it was before you started changing this page last month and I tried to appeal to the standard to stop the degradation. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright, and what is the human-readable version for "cast-expression"?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

The human-readable version for "cast-expression" is part of the table in cpp/language/operator precedence. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

I couldn't find it, I will keep "expression" I think, as it used to be.

— Maggyero (talk) 07:40, 19 September 2015 (PDT).

"cast-expression" is one of the BNF grammar productions that are, in human language, known as "operator precedence and associativity". You won't find it by that name in that table. Like all other expressions (other than the confusingly-named "id-expression"), cast-expressions can perform calculations, make function calls, print to screen, etc. "id-expression" is just a name of a variable, it can do no computation. --Cubbi (talk) 09:04, 19 September 2015 (PDT)

-) member function of T or of one of T's base classes

+) member function of T or of an unambiguous and accessible base class of T

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: The standard states, § 5.2.5. "Class member access", alinea 5:

"[Note: The program is also ill-formed if the naming class is an ambiguous base of the class type of the object expression; see § 11.2. — end note ]"

and, § 11.2. "Accessibility of base classes and base class members", alinea 6:

"If a class member access operator, including an implicit “this->,” is used to access a non-static data member or non-static member function, the reference is ill-formed if the left operand (considered as a pointer in the “.” operator case) cannot be implicitly converted to a pointer to the naming class of the right operand. [ Note: This requirement is in addition to the requirement that the member be accessible as named. — end note ]"

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Right, this edit was an improvement, even if it increases standardese content on the page. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

-) The expression E1->E2 is exactly equivalent to (*E1).E2 for built-in types

+) The expression E1->E2 is converted to the equivalent form (*E1).E2 for built-in types

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: There is no mention of conversion so the wording of the standard is better.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

No, This edit degrades the reference by mentioning and not explaining an irrelevant concept which also happens to share its name with what the rest of the reference refers to as "conversion". This isn't an instruction to compiler writers. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) if E2 is a [[../static|static data member]], the result is an [[../value category|lvalue]] designating that static data member;

+) if E2 is a [[../static|static data member]], the result is an lvalue designating that static data member of the class;

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: There is no need for putting a link at each occurence of the same word in an article, the link is already used before.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Why add the redundant " of the class;"? --Cubbi (talk) 10:29, 18 September 2015 (PDT)

It is used in the standard to highlight that it's not a data member of the instance object E1 but of the naming class of E1 since it's static. But I admit it's not clear enough. What about "if E2 is a [[../static|static data member]], the result is an lvalue designating that static data member of the naming class of E1;"?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

I don't know what "the naming class" means. This page doesn't have to explain core concepts that have their own pages; that's why "static data member" is a wikilink. However, like with static member functions, it could be useful to point out that although E1 is evaluated, its result is unused because E2 is a static data member. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

Alright. I will use "if E2 is a [[../static|static data member]], the result is an lvalue designating that static data member. Essentially, E1 is evaluated and discarded in this case;"

— Maggyero (talk) 07:40, 19 September 2015 (PDT).

-) if E2 has type T& or T&&, the result is an [[../value category|lvalue]] designating the same object as E2

+) if E2 has reference type T& or T&&, the result is an lvalue of type T designating that non-static data member for the object denoted by E1,

What was wrong with the existing sentences? What makes the new sentences better?

OK: I wanted to highlight that this is a non-static data member so a member of the instance of the class denoted by E1, not a member of the class of E1 as for a static data member. I am going to improve the wording.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

This is wrong: the member (E2) in this case is not an object. The member access expression does not give E2, it gives whatever E2 happens to refer to. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright. What about "if E2 has reference type T& or T&&, the result is an lvalue of type T designating that referred-to non-static data member of E1,"?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

Why would it have to be a member of E1? Consider

#include <cassert>
 
struct X { int n; };
struct S { int& r; };
 
int main()
{
    X x = {1};
    S s = {x.n};
    assert(&s.r == &x.n);
}

The member access expression s.r is an lvalue that designates a member of a completely different object x. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

Thanks for this great example, in this case I misunderstood the concept and did introduced a new error. And like in the standard, I will create a separate item for it because it applies not only to non-static data members but also to static data members. I think "if E2 is a reference to a data member (T& or T&&), the result is an lvalue of type T designating that data member;" will do.

— Maggyero (talk) 07:40, 19 September 2015 (PDT).

They are not a separate item on the same level as static/non-static member/function. They are a subclass of non-static members. It would have been a lot less distractful if this page were just discussing value categories and types, instead of venturing into semantics of member access. --Cubbi (talk) 09:04, 19 September 2015 (PDT)

Alright, I had understood only partially what you said. But even now, as you noted in your last edit, E2 can be a static member of reference type. And I have just realized that this reference does not refer necessarily to an object but can also refer to a function.

Example with a non-static reference:

#include <cassert>
 
int f() { return 0; }
struct S { int (& r)(); };
 
int main()
{
    S s = {f};
    assert(&s.r == &f);
}

Same example but with a static reference:

#include <cassert>
 
int f() { return 0; }
struct S { static int (& r)(); };
int (& S::r)() = f;
 
int main()
{
    assert(&S::r == &f);
}

So in both case the sentence should be the same: "if E2 is of reference type T& or T&&, the result is an lvalue of type T designating the object or function to which E2 refers,". That's why I still think the a separate item (as in the standard) would avoid repeating twice the same statement, but I have nothing against keeping the split, that is only a matter of taste.

— Maggyero (talk) 10:05, 19 September 2015 (PDT).

-) if E1 is an lvalue, the result is an lvalue designating the non-static data member

+) if E1 is an lvalue, the result is an lvalue designating that non-static data member for the object denoted by E1,

What was wrong with the existing sentences? What makes the new sentences better?

OK: Same remark as above.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

The remark is different because in this case E2 is in fact an object (and a subobject of E1). The object to which the member access expression refers. Also "member for" is ungrammatical. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright. What about "if E1 is an lvalue, the result is an lvalue designating that non-static data member of E1,"?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

Okay. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

-) otherwise (if E1 is an rvalue), the result is an xvalue designating the non-static data member

+) otherwise (if E1 is an [[../value category|rvalue]]), the result is an xvalue designating that non-static data member for the object denoted by E1.

What was wrong with the existing sentences? What makes the new sentences better?

OK: Same remark as above.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

What about "otherwise (if E1 is an [[../value category|rvalue]]), the result is an xvalue designating that non-static data member of E1."?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) If E2 is not a mutable member, the [[../cv|cv-qualification]] of the result is the union of cv-qualifications of E1 and E2. If E2 is a mutable member, the cv-qualification of the result is the union of volatile-qualifications;

+) If E2 is a mutable member, the [[../cv|cv-qualification]] of the result is the union of the volatile-qualifications of E1 and E2, otherwise (if E2 is not a mutable member) it is the union of the cv-qualifications of E1 and E2;

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: It is exactly the same but the order chosen in the standard is easier to understand because it starts with a property (mutable) instead of the absence of a property (not mutable).

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Old wording starts with the rule and then mentions the exception. Standard usually describes exceptional cases first because that's how compilers are written, but it doesn't make a good reference. Not technically wrong, of course. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) if E2 is a [[../static|static member function]], the result is an lvalue designating that static member function. Essentially, E1 is evaluated and discarded in this case;

+) if E2 is a [[../static|static member function]], optionally ref-qualified, the result is an lvalue designating that static member function without optional ref-qualifier;

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: The mention of the drop of the ref-qualifier is missing. The standard states, § 5.2.5., alinea 4.3.2.:

"Otherwise, if E1.E2 refers to a non-static member function and the type of E2 is “function of parameter-type-list cv ref-qualifieropt returning T”, then E1.E2 is a prvalue. The expression designates a non-static member function. The expression can be used only as the left-hand operand of a member function call (§ 9.3.). [ Note: Any redundant set of parentheses surrounding the expression is ignored (§ 5.1.). — end note ] The type of E1.E2 is “function of parameter-type-list cv returning T”."

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

This introduces an error (or rather, a nonsensical statement). There is no such thing as "{rlp|static|static member function}}, optionally ref-qualified", you are quoting an unrelated paragraph. Also, this edit removes content (the evaluation of E1. Granted it can be inferred from earlier text, but it's the case where it is actually important) --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright. But then I think that the evaluation and discard of E1 also happen if E2 is a static data members so this sentence "Essentially, […]" should be added for that item as well, shouldn't it?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

Yes, I just noted that higher up. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

-) the result is a special kind of prvalue designating that non-static member function that can only be used as the left-hand operand in a function-call expression,

+) the result is a special kind of prvalue equal to that non-static member function that can only be used as the left-hand operand of a member function call, and for no other purpose;

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: As you said earlier, prvalues do not "designate".

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Pending member function call doesn't "equal" anything either. In fact, 'designate' is more suitable here despite its value classification. Think of what it is. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) if .. and .. or .. then the result is a special kind of prvalue that can only be used as the left-hand operand in a function-call expression

+) if .. and .. or .. the result is a special kind of prvalue that can only be used as the left-hand operand of a member function call,

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: For consistency with the other same sentences of the article.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

In the expression "a(b)", a is the left-hand operand of the function call expression (or of the function call operator if you like). The spec mixes syntax and semantics when it refers to "operand of a member function call". Not really an error though. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) This is the only case where the left operand of operator. has non-class type

+) This is the only case where the left-hand operand has non-class type

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: The "hand" word was missing and there is no need to repeat the word "operator.".

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

The resulting sentence is incomplete. Operand of what? I suppose you could say "the only case where E1 may have non-class type". --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) The second operand of both operators is an expression of type pointer to member of class type T or of class type of which T is an unambiguous and accessible base class.

+) The second operand of both operators is an expression of type pointer to member of T or of an unambiguous and accessible base class of T.

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: More consistent wording with other parts of the article.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Besides changing the meaning to the opposite (correctly!), it should have said "or to .." instead of "or of ..". Pointer to base, not "of" base. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright. What about "The second operand of both operators is an expression of type pointer to member of T or pointer to member of an unambiguous and accessible base class of T."?

Okay --Cubbi (talk) 20:00, 18 September 2015 (PDT)

-) where D is either the same class type as B or a class type derived from B

+) where class type B is either the same class as D or an unambiguous and accessible base class of D

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: As you noticed later, the argument types were wrongly swapped so it was an error of the article that I corrected.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Right, and if you had made just this edit (plus the one just above and the one to the declaration for the purpose of overload resolution below), it would have been wonderful and well appreciated. This was the one real error on this page (it was contradicting the example, even). --Cubbi (talk) 10:29, 18 September 2015 (PDT)

-) T is either object or function type,

+) T is either an object or function type

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: Missing article "an".

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Right, it is a correct edit, although it makes the sentence somewhat harder to parse ('object' looks like the noun at first) --Cubbi (talk) 10:29, 18 September 2015 (PDT)

-) T& operator->*(B*, T D::*);

+) T& operator->*(D*, T B::*);

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: Again, as you noted later, the argument types were wrongly swapped.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Right, this would have made a great edit. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

-) The expression E1->*E2 is exactly equivalent to (*E1).*E2 for built-in types.

+) The expression E1->*E2 is converted to the equivalent form (*E1).*E2.

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: Same remark as for member operators.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Right, and it is a bad edit for the same reason as above --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) If E2 is a pointer to data member, the result is an expression that has the same value category as E2 designating that data member;

+) if E2 is a pointer to data member: if E1 is an lvalue, the result is an lvalue designating that data member, otherwise (if E1 is an rvalue), the result is an xvalue designating that data member;

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: The result cannot be a prvalue, that was an error in the article, so I corrected it according to what the standard states, § 5.5. "Pointer-to-member operators", alinea 6:

"The result of a .* expression whose second operand is a pointer to a data member is an lvalue if the first operand is an lvalue and an xvalue otherwise."

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

The page quoted an earlier revision of the C++ spec. The proper fix would have been to wrap the old and the new wording in appropriate standard revision markup, but I did change it to the current wording for now. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright. Does the old wording was for C++11 and the current one for C++14?

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

Old wording was correct for C++98 and C++03. It was published as part of C++11, but it was actually an error in the C++11 standard. It was processed as core working group defect report 616 in 2013. The new wording was published as part of C++14, but it applies retroactively to C++11 compilers. Our (new) policy is to post new wording under "c++11" tag and add a line to the defect reports table at the bottom. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

-) the result is a special kind of prvalue designating that member function that may only be used as the left-hand argument of a function call expression

+) the result is a special kind of prvalue equal to that member function that can only be used as the left-hand operand of a member function call,

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: "Operand" and "function call" (not "function call expression") are used everywhere else in the article so this is more consistent.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

As above, while not technically wrong, it mixes syntax and semantics where they were separate --Cubbi (talk)

Alright.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

-) if E2 is a null pointer value

+) if E2 is a null pointer-to-member value

What was wrong with the existing sentences? What makes the new sentences better?

Not OK: It's not a "pointer" but a "pointer-to-member", as stated in the standard, § 5.5. "Pointer-to-member operators", alinea 6:

"If the second operand is the null pointer to member value (4.11), the behavior is undefined."

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

Correct, although unnecessary. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Please be specific, these changes are significant and some of them in fact corrected errors that were present on this page, while others introduced new errors. --Cubbi (talk) 19:18, 17 September 2015 (PDT)

Done. Could you please elaborate here on these newly introduced errors? I reverted back my version since you undid it instead of correcting it, and found out later that my version actually corrected several errors.

— Maggyero (talk) 08:30, 18 September 2015 (PDT).

The edit was reverted because it introduced errors (that it also made some good changes and some meaningless changes doesn't make the edit). Please be more careful and more focused. --Cubbi (talk) 10:29, 18 September 2015 (PDT)

Alright, I will try. When you agree I will make a new edit taking all our discussion into account.

— Maggyero (talk) 16:44, 18 September 2015 (PDT).

Yes, at this point I wouldn't roll back what you're suggesting already. --Cubbi (talk) 20:00, 18 September 2015 (PDT)

Perfect, thanks for your great insight, it was really helpful :).

— Maggyero (talk) 07:40, 19 September 2015 (PDT).