From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id BA7833858D28 for ; Tue, 11 Jan 2022 01:09:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA7833858D28 Received: by mail-wm1-x32b.google.com with SMTP id d187-20020a1c1dc4000000b003474b4b7ebcso909925wmd.5 for ; Mon, 10 Jan 2022 17:09:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7zLzcBKLq0dn1wwGgvvToZc3Z0jjLBvBHqcvaxj6pLg=; b=bu4Dcxq+XTD15vvudbJAyCiFszgWiRfglZHc1I+6ISroHhnosqaiA9sV/poa4wWAFz sYvOu2+7SgR34ByW8hAKNkpZfUFvjXFSHVJvuhZ1UcxJ+XdrdfXhqkmSzeMuiFOKqS/6 dUEYiXh8eeJKuJ+2FZx/pbpXYycHgiv6a+QE7DxqExAaCCjhj14lDgPhUAVQO3VsI9y3 J64uHRQc5OVqdMJ59AXWlTaEpckx4J8j9Lv+HhEGxnfKjEfJLa+nSoIpd+6h5/+se7Zj NHZRkwsTzx13Zt1dZtSu9mbf0ch/DWd43yscYiRm5bdgaICOrwlumVkFqKmZ6R/Qx4Y+ fAbQ== X-Gm-Message-State: AOAM532cdvRjCt4fuNXKH/DbrZ59YFzNgGW+xY7K09KwxxLgK32gwNOW ZubNO00fpr4aPcCgJ/qX38HuyKO8FjBzEtB3ZOg= X-Google-Smtp-Source: ABdhPJw+ZobhiEB/pQg/BwFknWOD1SlmNSIXvSKhsIR4g2n9JbmaHCZ2xs2KD/3fVZpqcot7J42LU0mu88bn++R9jGY= X-Received: by 2002:a7b:c310:: with SMTP id k16mr286941wmj.169.1641863356750; Mon, 10 Jan 2022 17:09:16 -0800 (PST) MIME-Version: 1.0 References: <20210714212609.GA78610@ldh-imac.local> <1ee79d3c-a373-cb2a-f975-e62d182f1882@gmail.com> In-Reply-To: From: Jonathan Wakely Date: Tue, 11 Jan 2022 01:09:03 +0000 Message-ID: Subject: Re: ostream::operator<<() and sputn() To: Lewis Hyatt Cc: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= , "libstdc++" , Dietmar Kuehl X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 01:09:19 -0000 On Mon, 10 Jan 2022 at 23:18, Lewis Hyatt wrote: > Thanks a lot for circling back to this. I feel like your change is a > pure improvement with little downside, so it would be great to have > it. Let me know please if I should do anything more there. Leave it with me. > To me, the whole situation with sputn() is just unfortunate, because I > think it should not have been specified to always make the virtual > call to xsputn(), but rather only make it if needed. Then everything > would work as well as possible. Like after this change to the > single-char overload, a similar unexpected performance issue will > affect something like: cout << "a" compared to cout << 'a', where > now the former will make a virtual call every time and the latter > won't. libstdc++ could handle the char* overload case as well, but > then it still would not be permitted to handle a string or > string_view, so at some level the standard specification is the > constraint... Seems unlikely it will change though, so I think it > means that avoiding sputn() wherever permitted will always be an > avenue towards improving performance. I think the standard is overspecified, and changing it makes sense. It will take some time though.