Difference between revisions of "User talk:Xmcgcg"

Latest revision as of 15:32, 1 October 2024

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)

The convention wording in FAQ discussion I've linked is literally written by an administrator of this wiki as response to my question made on Jan 2022. Telling it's not approved by any administrator while it's literally written by them in FAQ discussion is just irrational. Benio (talk) 22:40, 13 August 2024 (PDT)

If you are referring to this reply, I do not think that means an “approval”. As the first two setences clearly say:

much of these details emerge as informal implicit agreement between active editors, and there's always a thousand things to do to improve content before polishing formatting. It's low priority.

--Xmcgcg (talk) 23:25, 13 August 2024 (PDT)

Stop vandalisms

Your vandalisms make my work almost impossible, not only have to re–revert your reverts, but also I keep loosing track on when changes were made (for example, I've almost forgot to mark last usage of extern as (since C++11), because you keep reverting my edits, and this have to be marked, as the page cpp/keyword also marked it before, to keep consistency). You keep doing ongoing harm to readability and consistency on site, not only wasting my time, but removing useful information and breaking StandardRevisions. Your vandalisms are too annoying and you directly oppose convention written directly by an administrator, and ignore my direct ask to follow the convention. Please, stop. Benio (talk) 04:03, 14 August 2024 (PDT)

Xmcgcg clearly isn't a vandal, so lets drop the exasperational tone please. What admin-written convention are you referring to? --Ybab321 (talk) 06:25, 14 August 2024 (PDT)

If only you had spent that time reading instead of writing. I didn't expect anything by contributing here and still got disappointed. Despite exasperational vandalisms, I've finally finished my planned work here and hope it shall help people in future, but based on the experience here, it won't happen again any time soon, if at all. Wish you more productivity and less stress. Following conventions will help you with the last one. Farewell, Benio (talk) 14:49, 14 August 2024 (PDT)

Just a reminder, any convention is just “informal implicit agreement between active editors”, so do expect discrepancy in opinions. Getting disappointed is an essential step to become a good editor, and welcome back anytime. --Xmcgcg (talk) 18:23, 14 August 2024 (PDT)

P0616R0 isn't DR-backed by any implementation

All known implementations (libc++, libstdc++, and MSVC STL) start to use std::move in these algorithms since C++20. Is there any reason to say all of them need to be fixed by backporting move to older modes? --Fruderica (talk) 05:51, 14 September 2024 (PDT)

The discussion for LWG issue 2055 seems like LWG took it as a DR, but it is OK to make the changes since the implementations never agree with it. --Xmcgcg (talk) 18:46, 17 September 2024 (PDT)

Do we need {‏{dm*}} (=#Data members) shortcuts?

Hi, Xmcgcg!

What do you think about adding the following wiki templates, considering that there are so many links to the exposition-only data members (i.e. to #Data members section):

For current page section links:
{{dmt|name}} => [[#Data members|{{tt|{{{1|{{error|no member name}}}}}}}]]
{{dmi|name}} => [[#Data members|{{tti|{{{1|{{error|no member name}}}}}}}]]

For parent page section links:
{{dmpt|name}} => {{rlpt|/#Data members|{{{1|{{error|no member name}}}}}}}
{{dmpi|name}} => {{rlpi|/#Data members|{{{1|{{error|no member name}}}}}}}

Then the link to current/parent #Data members section would be like (a breeze): {{dmpi|iterator_}} ? Or would that be over-specialization? --Space Mission (talk) 05:30, 25 September 2024 (PDT)

I would prefer updating {{dsc expos mem obj}} by adding an anchor to it. For the links to anchor of the current page, maybe we can generalize {{ttt}} to create shorthands for [[#anchor_name|anchor_name]], [[#anchor_name|{{tti|anchor_name}}]] etc. --Xmcgcg (talk) 23:03, 25 September 2024 (PDT)

I've added id=anchor-name param to {{dsc expos mem obj}}. Now it is possible to use, e.g., {{rlpsi}} in sub-pages to create exact links to expos-only members listed in parent's page.

What is not implemented is an auto-generation of the anchor (by default), when its name is copied from expos-member's name, which would require sometimes to trim the trailing underscores (if any). I haven't gotten to that point, because this has its own cons, such as generation of unused anchors or potential double anchor's name per page. --Space Mission (talk) 12:47, 28 September 2024 (PDT)

Nice. I will have a try. --Xmcgcg (talk) 18:22, 28 September 2024 (PDT)

Oh, the way to create local links is to skip "path" part in {{ls}}, {{lsd}}, {{lsi}} family. Additionally, I've added {{lst}} to complete the set of short-hands.

The next useful thing would be to add the "id=" param to a few other templates, e.g. to {{dsc mem obj}} etc, with admins assistance. --Space Mission (talk) 16:32, 1 October 2024 (PDT)