|
Boost : |
From: Hadriel Kaplan (hadrielk_at_[hidden])
Date: 2020-10-02 17:30:35
> On Oct 2, 2020, at 6:08 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
>
> My only complaint is that unsigned char and signed char (and thus uint8_t and int8_t) are streamed as their char values, and thus as their unadorned ASCII characters. Since they can be non-printable values, I consider this behavior undesirable.
>
> But should this complaint target PFR or C++ in general?
> This program outputs "4". What is broken is that `uint8_t` is an alias on `unsigned char` but as humans we expect something different from `unsigned char` and from `uint8_t`. I think PFR makes the right choice here: stream uint8_t the same way as if a user streamed it manually with `std::cout << u`. It is consistent in replicating the error-prone behavior.
Of course std::ostream in general has this problem, but weâre not talking about what it does - weâre talking instead about what PFR does. :)
And by that I mean, to me, how PFR chooses to stringify char-type struct members is an implementation detail of PFR and not an API contract to the user. The public API of PFR offers a streaming operator, obviously, but as far as the user knows you could choose to use any number of ways to achieve that under-the-hood for char-types.
As a user, I neither know nor care how it achieves that - I only care that the output is usable. Right now, the output isnât usable in what I would argue is the far more common use-case. But of course I could be wrong; Iâm not claiming to have crystal ball.
(Also, on a side-note: why shouldnât Boost provide such things _without_ repeating mistakes in the standard library? Can we not use hindsight and real-world results to provide something better than the standard libraries?)
> I think it is better to have the error-prone behavior consistent in all places than to apply fixes at random places with dubious effect:
>
> ```
> struct Encoding {
> char alphabetLetter;
> int ocurrences;
> };
>
> Encoding e {'a', 112};
> ```
> I really expect that to be output as "a 112â.
You shouldnât want it to, imo. One of the big benefits of using PFR is you can stream structs out for debugging/logging. Itâs completely useless to stream a char as a char for debugging, because the whole point is you donât know whatâs in the char, which is why youâre debugging it. *You* happen to know (or think) the `alphabetLetter` is a printable character because you named it that and are using it for that - but really itâs just a `char`, and despite being called `char` fundamentally nothing requires them to be ASCII characters (as you well know :)
But letâs assume you really do want `char` types to print âaâ - is that the common use-case expectation, or the less-common one?
Generating non-printable output doesnât make any sense, for what I would argue are the most common use cases.
-hadriel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk