public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Théo Papadopoulo" <papadopoulo@gmail.com>
To: libstdc++ <libstdc++@gcc.gnu.org>
Subject: operator<< and int8_t and uint8_t types....
Date: Mon, 23 Oct 2023 13:36:32 +0200	[thread overview]
Message-ID: <32b868eb-2569-471c-8f19-aac7fc362c42@gmail.com> (raw)

     Hi,

I suspect that this will probably receive an answer "this is the 
intended/normal/expected  behavior", but from what I saw on the internet
this is a kind of gray area in the standard and I did not found any 
(even closed) report on bugzilla, so I thought of asking here.

Currently, printing a int8_t of uint8_t number with operator<< basically 
prints it as a (u)char. I think this is very unfortunate and is somewhat 
deceptive to
users which expect a "int" like behavior.

#include <iostream>
#include <cstdint>

namespace std {

     std::ostream& operator<<(std::ostream& os,const int8_t v) {
         return os << static_cast<int>(v);
     }

     std::ostream& operator<<(std::ostream& os,const uint8_t v) {
         return os << static_cast<int>(v);
     }
}

int main() {
     std::int8_t a  = 65;
     std::uint8_t b = 66;
     char         c = 'c';
     std::cerr << a << ' ' << b << ' ' << c << std::endl;
}

Without the operator<< overloads: this code prints:

A B c

whereas I think a programmer would expect to see:

65 66 c

which is what is obtained with the overloads.

There is an old and extended discussion on stack overflow on the 
subject, in which from some comment it seems that
it is the promotion to int vs the conversion to char that plays a role 
here (and that gcc like many over compiler favors the char
conversion over the int promotion, but I'm not so sure about the 
validity of this discussion).

Certainly from the user's perspective, one would expect to see and 
integer value and not a char... and it does not look very difficult to do.

     Thank you in advance,

         Theo.






             reply	other threads:[~2023-10-23 11:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-23 11:36 Théo Papadopoulo [this message]
2023-10-23 11:45 ` Jonathan Wakely
2023-10-23 11:53   ` Jonathan Wakely
2023-10-23 12:01     ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32b868eb-2569-471c-8f19-aac7fc362c42@gmail.com \
    --to=papadopoulo@gmail.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).