User talk:Space Mission

Thanks!

Thank you for the disambiguation on the deprecated -- I am waiting to hear back from the paper's author to have him correct it in his mailing. I appreciate all the work that you do on the site!! I love reading the standard and working on implementing the STL. I am a professor of CS and teach C++ and this site is vital for the students and I know that it is only because of the work that you do to keep it up! Thanks again!

hawkinsw (talk) 18:06, 13 January 2024 (PST)hawkinsw

Javier Estrada!
Thank you for that inspiring 2020 lightning talk - El globo es redondo! ; ) Muchas gracias! :-)
Space Mission (talk)
Most welcome! And thanks for keeping these efforts "going round and round".
ticotico (talk) 07:10, 5 November 2020 (PST)

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

Hi, Nathan.

Great to see you here!

Yes, it is - the result of refactoring from const char* to an initializer-list:

auto workers[] = { "anil", "busara", "carl" }; /* fires an error
            ^^                                 */

auto workers = { "anil", "busara", "carl" }; // ok

 :) --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. -- Ncm (talk) 16:25, 19 April 2021 (PDT)

I have run clang++-12 -fsanitize=thread -stdlib=libc++(etc) locally and ... the barrier-example without std::lock_guard issues an ostreambuf data-race warning, whilst the example w/o std::lock_guard is pure. I'll investigate this later on. --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.) -- Ncm (talk) 00:34, 20 April 2021 (PDT)

Indeed. I've tested both cases with and without 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:

Thread sanitizer data-race report inside (two threads case)

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

--Space Mission (talk) 08:07, 20 April 2021 (PDT)

Ah, the option to blame is -stdlib=libc++. Maybe it is a bug in the current clang's implementation of std::barrier, or something else. Godbolt also fires a ThreadSanitizer-data-race warning with libc++. --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. --Ybab321 (talk) 08:14, 20 April 2021 (PDT)

Yea, until optimizations do them equal.) --Space Mission (talk) 13:43, 20 April 2021 (PDT)

In theory, yes; in practice, compilers tend to respect the programmer's choices of where to store data --Ybab321 (talk) 00:05, 21 April 2021 (PDT)

Not necessarily in theory. Replacing in yours Godbolt kit gcc with 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.) --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. :) --Ybab321 (talk) 02:10, 17 June 2021 (PDT)

Oh, thanks ;)

The syntax is like this, by example:

[[cpp/atomic/atomic/fetch_add#Example|"your text"]]

This generates the link "your text".

Another "trick" is to use the syntax construct like /* Example */ (yea, C/C++ comment), which gives: →Example: ...

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 [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 "→Example" (i.e. the name of an appropriate edited section) for you in the Summary. :)

--Space Mission (talk) 02:30, 17 June 2021 (PDT)

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

Also, the link to the beginning of a page is /* 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.

[http://cppreference.com This site.]: This site.. So, we are in the sandbox here. :) --Space Mission (talk) 07:19, 17 June 2021 (PDT)

Regarding the version mark changes

Hi Space Mission,

I saw your edit of page do. Indeed the double layer version mark looks cooler, but it has a few drawbacks. Consider the page if:

The current syntax (1) is

attr(optional) if constexpr(optional) ( init-statement(optional) condition ) statement-true	(1)

If version information is also added, the syntax becomes

attr(optional)(C++11) if constexpr(optional)(C++17) ( init-statement(optional)(C++17) condition ) statement-true	(1)

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:

attr(optional)(since C++11) if constexpr(optional)(since C++17) ( init-statement(optional)(since C++17) condition ) statement-true	(1)

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:

attr(???) if !(optional) consteval compound-statement	(3)	(since C++23)

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

(P.S. I found that currently the lambda-specifiers token in the page 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 (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 (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.

Hi, ‎Xmcgcg.

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 {{mark optional syntax|std=Cxx}} (e.g. (optional)(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 (since C++XY) in the explanation section - ideally, it should not be in bold. Below is not a real {{par|}} template, but an imitation of such (as it is somewhat complicated to fix the original one):

Now:

attr	-	explanatory text
(since C++11)	←	this mark should not be bold

Desired:

attr	-	explanatory text
(since C++11)

Alternatively, the {{mark since c++XX}} could be moved to the right part, e.g.:

attr

-

(since C++11) explanatory text

Or:

attr

-

explanatory text (since C++11)

The virtue of the later formatting is that it does not introduce a new line (for the (since C++XY) mark).

Compare:

attr1	-	explanatory text
(since C++11)
attr2	-	explanatory text
(since C++11)
attr3	-	explanatory text
(since C++11)

versus:

attr1	-	explanatory text (since C++11)
attr2	-	explanatory text (since C++11)
attr3	-	explanatory text (since C++11)

The reminders (mostly for myself.):

1. Dealing with versioning it also worth to remember that C++-revision parts should work correctly with "Standard revision" gadget (i.e. per page C++-revision chooser on top of most pages here).
2. MediaWiki - Tables formatting.

--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:

token

-

(OK here) Main explanation: bullet point 1 bullet point 2 (option 1-ambiguous: point 2 or whole explanation) (option 2-still need a new line)

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):

first-param

-

explanation 1

second-param - explanation 2

(since C++17)

third-param

-

explanation 3

but correctly adjusted.

All the rules for table formatting are here: w3.org -> tables formatting.)

--Space Mission (talk) 01:19, 1 September 2021 (PDT)

re: off-beat character literals

By the standard '¢' would be called a "non-encodable ordinary character literal" (which isn't necessarily multi-byte if a byte is larger than 8 bits) --Ybab321 (talk) 06:56, 10 June 2022 (PDT)

oh, thanks :) --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. --Guyutongxue (talk) 01:31, 16 September 2022 (PDT)