GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Paul Cantrell (inthehands@hachyderm.io)'s status on Monday, 10-Mar-2025 05:24:28 JST Paul Cantrell Paul Cantrell
    • luna, only carbon now

    Print statements in C++ are not threadsafe.

    This language…!

    @luna https://pony.social/@luna/114134087099804076

    In conversation about 3 months ago from hachyderm.io permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: cdn.pony.social
      luna, only carbon now (@luna@pony.social)
      from luna, only carbon now
      Attached: 2 images Consider this code. One thread repeatedly prints the number 100 in decimal to std::cout. Another thread repeatedly prints the number 0x100 in hex (which will output as '100') to std::cout. You might reasonably expect that the output will simply be '100' over and over and over. Unfortunately, the calls to operator
    • Embed this notice
      Paul Cantrell (inthehands@hachyderm.io)'s status on Monday, 10-Mar-2025 05:40:50 JST Paul Cantrell Paul Cantrell
      in reply to
      • luna, only carbon now
      • Johan Baltié

      @johan @luna
      I would not describe having a nondeterministic race condition between format specifiers from different threads as being “thread safe,” except in the most uselessly pedantic way imaginable.

      And no, I can’t think of another language that has this problem, because all of them use that magic native internal buffer we refer to as “local expression evaluation.”

      In conversation about 3 months ago permalink
    • Embed this notice
      Johan Baltié (johan@pouet.chapril.org)'s status on Monday, 10-Mar-2025 05:40:51 JST Johan Baltié Johan Baltié
      in reply to
      • luna, only carbon now

      @inthehands @luna they are thread safe.
      The interleave pb is a different issue
      I am not aware of languages that keep natively internal buffer per thread to avoid interleaving.

      Do you have any example ?

      In conversation about 3 months ago permalink

      Attachments


    • Embed this notice
      PaulDavisTheFirst (pauldavisthefirst@fosstodon.org)'s status on Monday, 10-Mar-2025 06:20:24 JST PaulDavisTheFirst PaulDavisTheFirst
      in reply to
      • luna, only carbon now
      • Johan Baltié

      @johan @inthehands @luna yeah, precisely. The "print statement" in C++ is the same as in C: printf and cousins.

      operator<< is ... an operator and is not inherently more (or less) thread-safe than operator+ or operator=.

      I also agree that is may be considered strange to promote an operator as the default way of printing.

      In conversation about 3 months ago permalink
    • Embed this notice
      Paul Cantrell (inthehands@hachyderm.io)'s status on Monday, 10-Mar-2025 06:20:24 JST Paul Cantrell Paul Cantrell
      in reply to
      • PaulDavisTheFirst
      • luna, only carbon now
      • Johan Baltié

      @PaulDavisTheFirst @johan @luna
      `cout <<` is the generally accepted idiom for printing to stdout in C++, no doubt able that — and yes, promoting that way is strange!

      Technicalities about implementation(“`<<` is just another operator,” “it’s thread-safe at the level of individual stream insertions”, etc) are missing the point. The •standard idiom• is a footgun. That’s the point.

      In conversation about 3 months ago permalink
    • Embed this notice
      Johan Baltié (johan@pouet.chapril.org)'s status on Monday, 10-Mar-2025 06:20:25 JST Johan Baltié Johan Baltié
      in reply to
      • luna, only carbon now

      @inthehands @luna ok I see where we disagree.
      Stream operators are not equivalent to print statement, each data being fed asap by design.

      And I agree this might be considered as a strange choice to promote this as a default way of printing.

      In conversation about 3 months ago permalink
    • Embed this notice
      Paul Cantrell (inthehands@hachyderm.io)'s status on Monday, 10-Mar-2025 07:46:05 JST Paul Cantrell Paul Cantrell
      in reply to
      • PaulDavisTheFirst
      • luna, only carbon now
      • Johan Baltié

      @johan @PaulDavisTheFirst @luna
      Ha, that’s hilarious! Everything is terrible.

      In conversation about 3 months ago permalink
    • Embed this notice
      Johan Baltié (johan@pouet.chapril.org)'s status on Monday, 10-Mar-2025 07:46:06 JST Johan Baltié Johan Baltié
      in reply to
      • PaulDavisTheFirst
      • luna, only carbon now

      @inthehands @PaulDavisTheFirst @luna

      Oh, researching other languages choices I discovered that Python as a very strange behavior:

      https://stackoverflow.com/questions/42867866/what-makes-python3s-print-function-thread-safe#64283201

      In conversation about 3 months ago permalink
    • Embed this notice
      Michael Kohne (mhkohne@mastodon.social)'s status on Monday, 10-Mar-2025 09:22:33 JST Michael Kohne Michael Kohne
      in reply to
      • luna, only carbon now

      @inthehands @luna I think it might be better if it just threw a fucking pointer and crashed rather than do this shit.

      In conversation about 3 months ago permalink
    • Embed this notice
      Paul Cantrell (inthehands@hachyderm.io)'s status on Monday, 10-Mar-2025 09:22:33 JST Paul Cantrell Paul Cantrell
      in reply to
      • Michael Kohne
      • luna, only carbon now

      @mhkohne @luna
      Why not both!

      In conversation about 3 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.