Namespaces
Variants
Actions

User talk:Xmcgcg

From cppreference.com
Revision as of 23:00, 12 August 2024 by Xmcgcg (Talk | contribs)

On the character sets

I believe my edit is OK even if P2314R4 is not a DR.

The behavioral changes are described in translation phases which is full of rev-boxes currently. And I don't think we should describe same character sets twice in a page. ----Fruderica (talk) 23:24, 28 September 2022 (PDT)

The charsets before C++23 are now collapsed at the bottom. See this page for an example: the old semantics of 'inheriting constructor' have been replaced by a DR, but there is still a collapsed section describing it. ----Xmcgcg
There is still duplication. I think the "historically known as" I wrote is sufficient to descibe the old terminology. Note that "the charsets before C++23" and "the charsets since C++23" are almost the same things, except that
  • the term translation character set based on UCS scalar values is newly introduced, and
  • the term extended source character set (seemly never properly defined) is removed by P2314R4,
and they are generally not equivalent. ----Fruderica (talk) 01:51, 29 September 2022 (PDT)
I get your point, but for me it still does not justify the removal of the old charsets, and the related changes in other pages. In my opinion, 'XXX is equivalent to YYY in an older C++ standard version' should be avoided in the descriptions (OK to note it in the "Notes" section) because this is an indirection across different versions. Having these revboxes there is the simplest way to maintain accuracy, you can add a footnote there to state the equivalence if you wish. ----Xmcgcg
I think I've never attempted to remove the "old" charsets. Currently there are just old and new style tables and terms representing the same charsets (except for the translation character set). Duplication of the tables would distract readers from knowing that the tables are essentially unchanged, because the UCS scalar values are exposition-only for non-UTF encodings. I think the duplication would result in inaccuracy of comprehending the changes in P2314R4, which might violate the accuracy-maintaining intent. ----Fruderica (talk) 08:15, 29 September 2022 (PDT)

I've done what I think right again. I believe the current rev-boxes and notes are correctly representing what are changed and what are unchanged. ----Fruderica (talk) 09:48, 29 September 2022 (PDT)

I am OK with that as long as the related sections in other pages remain the same. ----Xmcgcg

Regarding the binary search algorithm wording updates

Just wanted to say that's a wording update I can get behind, good job :) --Ybab321 (talk) 12:06, 29 February 2024 (PST)

Thank you! Any future suggestion is welcomed :) --Xmcgcg

Breaking StandardRevisions

Your recent edit (174749) breaks StandardRevisions under multiple conditions.

  • For example, you include a link to the register keyword for all revisions of Storage class specifiers, including: (C++11), (C++20), (C++23), (C++26) and even future ones.
This is clearly bad, as the register keyword "is unused and reserved" (since C++17).

Desired convention for StandardRevisions has been established in Jan 2022 and there were no objections since then, even yours. I find your edit harmul as it includes redundant keywords for revisions, where they are not related to the content they are bound to. I really appreciate your attentive edits, but those few like mentioned one, are unnecessary — they break StandardRevisions, and this despite the convention.

While I respect your comments like that not to include keyword usage in keyword sections (despite I still think they really useful), I'd like to ask you to stop making edits that include keywords into revisions where they are not bound to, like in the example above.

Thank you in advance, Benio (talk) 23:32, 12 August 2024 (PDT)

The standard revision gadget is for advanced users, and there is a bunch of features that are not affected by this gadget (syntax list, feature-test macro list, defect reports list, code box and even the main page). Specifying a version does not prevent you from entering a page marked (until C++XX) or (since C++XX) either, so there is no hard error resulting from my edits.
The reason I am removing the revboxes and usages in the “Keywords” section is that the main (or “only” in my opinion) purpose of this section is to provide links to the cpp/keyword pages. The usages and revisions are already provided in the main description, adding redundant information does not help readers to navigate to the keyword pages. Unless there is a strong advantage for this style, I am not going to approve it.
Desired convention is not approved by any administrator as the official or recommended style. My edits were also altered or reverted by other users, and I have never requested anyone to follow any particular convention. The edit page says:
Please note that all contributions to cppreference.com may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
--Xmcgcg (talk) 00:00, 13 August 2024 (PDT)