View source for User talk:Space Mission

Javier Estrada!
<br>Thank you for that inspiring [https://www.youtube.com/watch?v=I8lVKve_bEk|CppCon 2020 lightning talk] - El globo es redondo! ; )
Muchas gracias! :-)
<br>[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]])
<br>Most welcome!  And thanks for keeping these efforts "going round and round".
<br>[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 07:10, 5 November 2020 (PST)

Hi Space,
<br>I don't understand why you changed barrier example workers from an initializer-list to an array of char*. -- [[User:Ncm|Ncm]] ([[User talk:Ncm|talk]]) 14:50, 19 April 2021 (PDT)

: Hi, Nathan.
: Great to see you here!
: Yes, it is - the result of refactoring from {{c|const char*}} to an initializer-list:
{{source|1=
auto workers[] = { "anil", "busara", "carl" }; /* fires an error
            ^^                                 */
}}
{{source|1=auto workers = { "anil", "busara", "carl" }; // ok}}
: :) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 16:01, 19 April 2021 (PDT)

::I see, when I meant to change to an initializer-list, I failed to delete the `[]`. BTW, I had fun with trying to use `-fsanitize=thread`, and this example, on Godbolt. It turns out that (1) it has a three-spawn thread limit, and (2) `-fsanitize=thread` uses up one of them. I added a note to the Godbolt FAQ, although it is pretty well-hidden.  -- [[User:Ncm|Ncm]] ([[User talk:Ncm|talk]]) 16:25, 19 April 2021 (PDT)

:::I have run {{tt|1= clang++-12 -fsanitize=thread -stdlib=libc++}}(etc) locally and ... the barrier-example without {{lc|std::lock_guard}} issues an {{lc|ostreambuf}} ''data-race'' warning, whilst the example w/o {{lc|std::lock_guard}} is pure. I'll investigate this later on. --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 17:36, 19 April 2021 (PDT)

::::Strange, Clang trunk and Gcc trunk on Godbolt like it OK. (I reduced it to two elements to run with sanitization there, for the spawn limit.) -- [[User:Ncm|Ncm]] ([[User talk:Ncm|talk]]) 00:34, 20 April 2021 (PDT)
::::: Indeed. I've tested both cases with and without {{lc|lock_guard}}-ing, changing the number of threads from 2 to 6, with the same result - non-locking case generates a warning, as graceful as this:
{{cot|Thread sanitizer data-race report inside (two threads case)}}
{{source|1=
Starting...
  anil worked
==================
WARNING: ThreadSanitizer: data race (pid=22338)
  Read of size 8 at 0x0000006fc8a0 by thread T2:
    #0 std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char) <null> (test_example_std_barier(3)+0x4bfd4a)
    #1 std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) <null> (test_example_std_barier(3)+0x4bfc19)
    #2 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_1, char const*> >(void*) <null> (test_example_std_barier(3)+0x4bf0dd)

  Previous write of size 8 at 0x0000006fc8a0 by thread T1:
    #0 std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char) <null> (test_example_std_barier(3)+0x4bfe56)
    #1 std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) <null> (test_example_std_barier(3)+0x4bfc19)
    #2 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_1, char const*> >(void*) <null> (test_example_std_barier(3)+0x4bf0dd)

  Location is global 'std::__1::cout' of size 160 at 0x0000006fc880 (test_example_std_barier(3)+0x0000006fc8a0)

  Thread T2 (tid=22341, running) created by main thread at:
    #0 pthread_create <null> (test_example_std_barier(3)+0x42ad1b)
    #1 void std::__1::allocator_traits<std::__1::allocator<std::__1::thread> >::construct<std::__1::thread, main::$_1&, char const* const&, void, void>(std::__1::allocator<std::__1::thread>&, std::__1::thread*, main::$_1&, char const* const&) <null> (test_example_std_barier(3)+0x4bef0f)
    #2 main <null> (test_example_std_barier(3)+0x4be8fa)

  Thread T1 (tid=22340, running) created by main thread at:
    #0 pthread_create <null> (test_example_std_barier(3)+0x42ad1b)
    #1 void std::__1::allocator_traits<std::__1::allocator<std::__1::thread> >::construct<std::__1::thread, main::$_1&, char const* const&, void, void>(std::__1::allocator<std::__1::thread>&, std::__1::thread*, main::$_1&, char const* const&) <null> (test_example_std_barier(3)+0x4bef0f)
    #2 main <null> (test_example_std_barier(3)+0x4be517)

SUMMARY: ThreadSanitizer: data race (/tmp/test_example_std_barier(3)+0x4bfd4a) in std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char)
==================
  busara worked
... done
Cleaning up...
  busara cleaned
  anil cleaned
... done
ThreadSanitizer: reported 1 warnings

$ clang++-12 --version
Ubuntu clang version 12.0.0-++20210319082646+4990141a4366-1~exp1~20210319193401.61
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

}}
{{cob}} --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 08:07, 20 April 2021 (PDT)
:: Ah, the option to blame is {{tt|1= -stdlib=libc++}}. Maybe it is a bug in the current clang's implementation of {{lc|std::barrier}}, or something else. Godbolt also fires a ''ThreadSanitizer-data-race'' warning with {{ttb|libc++}}. --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 13:43, 20 April 2021 (PDT)

I just wanted to butt in to say that the array solution is technically superior as it puts the char pointers onto the stack, instead of pointing to char pointers held in read-only memory (one indirection is better than two), not that it matters for cppreference demo code. --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 08:14, 20 April 2021 (PDT)
: Yea, until optimizations do them equal.) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 13:43, 20 April 2021 (PDT)
:: In theory, yes; [https://godbolt.org/z/MeeEYqvsc in practice], compilers tend to respect the programmer's choices of where to store data --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 00:05, 21 April 2021 (PDT)
::: Not necessarily [https://godbolt.org/z/7Yq6fozz4 in theory.] Replacing in yours Godbolt kit {{ttb|gcc}} with {{ttb|clang}} I've occasionally found (to my satisfaction:) that the later generates the same assembly for both "barrier" cases. Anyway, thanks a lot for this link and a stack of ideas to think about.) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 13:42, 21 April 2021 (PDT)

== Formatting in change summaries ==

How are you adding links to pages in your edit change summaries? Also going to take this opportunity to say thanks for the massive amount of contribution you've given to this website. :) --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 02:10, 17 June 2021 (PDT)

: Oh, thanks ;)
: The syntax is like this, by example:
{{source|1=
[[cpp/atomic/atomic/fetch_add#Example|"your text"]]
}}
: This generates the link [[cpp/atomic/atomic/fetch_add#Example|"your text"]].<br>
: Another "trick" is to use the syntax construct like {{c|1=/* Example */}} (yea, C/C++ comment), which gives: [[cpp/atomic/atomic/fetch_add#Example|→]]Example: ...<br>
: Any sections' header can be used in place of "Example", e.g. "Notes" etc.
: Additionally, in case you don't know, if you turn on the {{tt|[x]}} "show edit link" option in your private settings (on this site) it also may help, since then the page's editor will open only the given paragraph for editing, not the whole page. This will also generate "[[cpp/atomic/atomic/fetch_add#Example|→]]Example" (i.e. the name of an appropriate edited section) for you in the Summary. :)
: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 02:30, 17 June 2021 (PDT)

:: Good stuff, many thanks :) --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 06:15, 17 June 2021 (PDT)

::: Also, the link to the beginning of a page is {{c|1=/* Top */}}. But I still do not know how to create links to external resources in the Summary line. It seems such linking is intentionally not supported. The following does not work, as you have seen.<br>
::: {{c|1=[http://cppreference.com This site.]}}: [http://cppreference.com This site.]. So, we are in the sandbox here. :) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 07:19, 17 June 2021 (PDT)

== Regarding the version mark changes ==

Hi Space Mission,

I saw your edit of page {{ltt|cpp/language/do}}. Indeed the double layer version mark looks cooler, but it has a few drawbacks. Consider the page {{ltt|cpp/language/if}}:

The current syntax (1) is
{{sdsc begin}}
{{sdsc|num=1|1=
{{spar|attr}}{{mark optional}} {{ttb|if}} {{ttb|constexpr}}{{mark optional}} {{ttb|(}} {{spar|init-statement}}{{mark optional}} {{spar|condition}} {{ttb|)}} {{spar|statement-true}}
}}
{{sdsc end}}

If version information is also added, the syntax becomes
{{sdsc begin}}
{{sdsc|num=1|1=
{{spar|attr}}{{su|p={{mark optional}}|b={{mark c++11}}}} {{ttb|if}} {{ttb|constexpr}}{{su|p={{mark optional}}|b={{mark c++17}}}} {{ttb|(}} {{spar|init-statement}}{{su|p={{mark optional}}|b={{mark c++17}}}} {{spar|condition}} {{ttb|)}} {{spar|statement-true}}
}}
{{sdsc end}}

From my point of view, the new syntax looks a bit complex. Adding too much information to the syntax weakens the readability: it becomes harder to read the syntax with so many green words.

Also, the 'C++XX' marks addressing the tokens actually means 'since C++XX', which is more closely represented by the 'since C++XX' marks (which are already used in many places). Using them in the syntaxes simply makes them look worse:
{{sdsc begin}}
{{sdsc|num=1|1=
{{spar|attr}}{{su|p={{mark optional}}|b={{mark since c++11}}}} {{ttb|if}} {{ttb|constexpr}}{{su|p={{mark optional}}|b={{mark since c++17}}}} {{ttb|(}} {{spar|init-statement}}{{su|p={{mark optional}}|b={{mark since c++17}}}} {{spar|condition}} {{ttb|)}} {{spar|statement-true}}
}}
{{sdsc end}}

Now the tokens are so far apart from each other that we probably need to scan the syntax a few more times to understand its structure. The version marks (for tokens) only need to be placed in the explanation section: people who wants to read the explanation of a token will eventually read its version requirement there.

Another problem arises when another syntax is introduced in a later standard:
{{sdsc begin}}
{{sdsc|num=3|notes={{mark since c++23}}|1=
{{spar|attr}}{{mark|???}} {{ttb|if}} {{ttb|!}}{{mark optional}} {{ttb|consteval}} {{spar|compound-statement}}
}}
{{sdsc end}}

What should we mark {{spar|attr}} in this syntax? If we mark {{mark since c++11}}, it looks weird as there is a better restriction {{mark since c++23}} applied to the whole syntax. If we mark {{mark since c++23}} or choose not to mark, it does not match the mark {{mark since c++11}} in syntax (1).

(P.S. I found that currently the {{spar|lambda-specifiers}} token in the page {{ltt|cpp/language/lambda}} has different optional and version requirements in different syntaxes. However, the current syntax list does not match the standard syntaxes in N4892 (the latest C++23 draft) 7.5.5.1 and N4860 (final C++20 draft) 7.5.5. The standard syntaxes do not have this problem and I am planning a rework of the syntax list.)

My solution to these problem is to keep version information away from the syntax itself. (Marking the entire syntax with a version is OK) All version information of tokens can be found in the explanation section. The tokens only need to be marked with {{mark optional}} if needed.

For the syntaxes I have reviewed in cppreference, all tokens added in a later standard are
* always optional, and
* never deprecated or removed in another later standard.

These give us two guarantees:
@1@ Including all optional tokens in the latest C++ version never causes a syntax error.
@2@ Excluding all optional tokens in any C++ version never causes a syntax error.

Therefore a syntax with the only mark type {{mark optional}} is sufficient for readers to follow in most cases.

I have already cleared the version marks from some pages and I will revert the 'do' page back to my version. Any comment is appreciated.

<br>
: Hi,  ‎<i>Xmcgcg</i>.

: That's great you have expressed your ideas. I personally accept the logic your have presented.

: Fill free to edit (and undo), as far as new edits follow the established formatting standards. The problem is that the rules quite often are unwritten and one has to deduce them, sometimes erroneously, from existing material. New rules are from the other side the subject of discussion and consensus.

: I've added the double layered template <font style="color:green;"><code><nowiki>{{mark optional syntax|std=Cxx}}</nowiki></code></font> (e.g. {{mark optional syntax|std=c++23}}) guessing that it might (or might not) be a bit more convenient way to express (where appropriate) the versioning of the syntax. But that new template is not a ''holy cow'' and can obviously be rejected, if there are better ways (new or existing) to present the content.

: The only thing I would prefer to be made the other way is the style of the <font style="color:green;"><code><nowiki>(since C++XY)</nowiki></code></font> in the ''explanation section'' - ideally, it should '''not''' be in '''bold'''. Below is not a real {{tt|{{par{{!}}}}}} template, but an imitation of such (as it is somewhat complicated to fix the original one):


: <u>Now</u>:

{|
| style="text-align:right;" | '''attr'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text
|-
| style="text-align:right;" | '''{{mark since c++11}}''' 
| style="width:20px; text-align:center;" | ←
| style="text-align:left;color:light-grey" | <small>this mark should not be '''bold'''</small>
|}


: <u>Desired</u>:

{|
| style="text-align:right;" | '''attr'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text
|-
| style="text-align:right;" | {{mark since c++11}}
|}


: Alternatively, the <font style="color:green;"><code><nowiki>{{mark since c++XX}}</nowiki></code></font> could be moved to the right part, e.g.:

{|
| style="text-align:right;" | '''attr'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | {{mark since c++11}} explanatory text
|}

: Or:

{|
| style="text-align:right;" | '''attr'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text {{mark since c++11}}
|}


: The virtue of the later formatting is that it does not introduce a new line (for the <font style="color:green;"><nowiki>(since C++XY)</nowiki></font> mark).

Compare:
{|
| style="text-align:right;" | '''attr1'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text
|-
| style="text-align:right;" | {{mark since c++11}}
|-
| style="text-align:right;" | '''attr2'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text
|-
| style="text-align:right;" | {{mark since c++11}}
|-
| style="text-align:right;" | '''attr3'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text
|-
| style="text-align:right;" | {{mark since c++11}}
|}


: versus:

{|
| style="text-align:right;" | '''attr1'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text {{mark since c++11}}
|-
| style="text-align:right;" | '''attr2'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text {{mark since c++11}}
|-
| style="text-align:right;" | '''attr3'''
| style="width:20px; text-align:center;" | ''' - '''
| style="text-align:left;" | explanatory text {{mark since c++11}}
|}


: The reminders (mostly for myself.):
:# Dealing with versioning it also worth to remember that C++-revision parts should work correctly with "Standard revision" [[Special:Gadgets|gadget]] (i.e. per page C++-revision chooser on top of most pages here).
:# [https://www.mediawiki.org/wiki/Help:Tables MediaWiki - Tables formatting].

: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 07:58, 30 August 2021 (PDT)

:: Hi Space Mission,
:: Thanks for your suggestions. The reason I chose to place the version mark in a new line is to avoid narrowing the explanation text block. I totally agree with you that a bold version mark does not look nice.

:: I prefer putting the version marks at the beginning of the explanation text. Putting them at the end raises a problem when the explanation ends with a bullet point:

{{par begin}}
{{par | {{spar|token}} | {{mark|OK here}} Main explanation:
* bullet point 1
* bullet point 2 {{mark|option 1-ambiguous: point 2 or whole explanation}}
{{mark|option 2-still need a new line}}}}
{{par end}}


::: I agree with yours

  putting the version marks at the beginning of the explanation text ''[is better]''

::: Yet another alternative is the formatting closed to the following (an imitation made by adjoining three tables):

{{par begin}}
{{par | '' first-param '' | explanation 1}}
{{par end}}

{{rrev|since=c++17|
{{par begin}}
{{par | '' second-param '' | explanation 2}}
{{par end}}
}}

{{par begin}}
{{par | '' third-param '' | explanation 3}}
{{par end}}


::: but correctly adjusted.

::: All the rules for table formatting are here: [https://www.w3.org/TR/html401/struct/tables.html w3.org -> tables formatting].)
::: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 01:19, 1 September 2021 (PDT)

== re: off-beat character literals ==

[http://eel.is/c++draft/tab:lex.ccon.literal By the standard] {{tt|'¢'}} would be called a "non-encodable ordinary character literal" (which isn't necessarily multi-byte if a byte is larger than 8 bits) --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 06:56, 10 June 2022 (PDT)
: oh, thanks :) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 07:08, 10 June 2022 (PDT)

== Request a user block ==

[[User:Cqwrteur]] is now messing up this site. Request a ban for him. --[[User:Guyutongxue|Guyutongxue]] ([[User talk:Guyutongxue|talk]]) 01:31, 16 September 2022 (PDT)