> (thx Chris Ryan for your analysis)
Technically,I dug into the MS implementation of operator<< int/uint and
internally it uses sprintf_s() (that does not support binary formatting but
does support %o, %X, & %x)
I had hoped it used an itoa() type implementation to be able to use any
base/radix 2-36, but no.

I am not sure what other platforms do for their operator<< int/uint output
mechanism.



On Tue, Feb 11, 2025 at 4:50 PM Javier Estrada via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Understanding that this is not the C forum, *** C23 supports binary
> literals*** ...just not a way to print them or represent them via any of
> the printf family of functions (or scanf, for that matter).
>
> Since at the end of the day, after you peel off the "stream onion" stream
> manipulators that format end up being a call to printf/scanf (thx Chris
> Ryan for your analysis), this would seem to me that it's also a gap in C
> itself. There is no conversion specifier (
> https://en.cppreference.com/w/c/io/fprintf) a la "%b", for example, which
> is not taken so far :-).
>
> Now, C would be a tougher onion to peel.
>
>
>
> On Tue, Feb 11, 2025 at 10:59 AM Tiago Freire <tmiguelf_at_[hidden]>
> wrote:
>
>>
>> > I/O streams will be there for a long, long time, and I think
>> retrofitting useful features is for the benefit of the language and its
>> users.
>>
>> I'm not so sure about the "will be there for a long time".
>> As it has been mentioned in this thread, new features such a format and
>> print, are increasingly introducing better ways to do things in this space.
>> Add some extra I/O (for file and terminal) that are capable of
>> interfacing with them, and eventually iostream become obsolete enough to
>> become deprecated. The burden of maintaining it at that point will become
>> greater than any benefit it provides.
>>
>>
>> It may not be by C++26, but hopefully eventually, things seem to be going
>> in that direction.
>>
>> I have personally already banned them from my code base, once you figure
>> out that are better ways to do things, believe me, you don't really need it.
>>
>> That's not to say that if I had voting power on this that I would vote
>> against it, my vote would have been neutral. 10 years ago this would have
>> been a great proposal, just don't think it's worth the time of the
>> committee today given the progress that has been made since then.
>>
>> New formatting facilities can already do this, it's time to move on.
>>
>>
>> ------------------------------
>> *From:* Javier Estrada <iphone.javier.estrada_at_[hidden]>
>> *Sent:* Tuesday, February 11, 2025 6:13:25 PM
>> *To:* Tiago Freire <tmiguelf_at_[hidden]>
>> *Cc:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
>> *Subject:* Re: [std-proposals] std::bin manipulator for integer binary
>> input/output
>>
>> Thx for the reply, Tiago.
>>
>> I/O streams will be there for a long, long time, and I think retrofitting
>> useful features is for the benefit of the language and its users.
>>
>> Seems to me that the cost of adding a manipulator is very small compared
>> to the feature proposed by Victor in the paper listed by Jonathan (
>> https://wg21.link/p1729).
>> ---
>> On an unrelated note, since this is the first time that I post a
>> proposal, how does the process work? Who calls the shots—e.g., if I decided
>> to write a proposal and submit it, whose approval would it have to go
>> through? The maintainers of this list?
>>
>> I would understand that this is a filter to gather input and usefulness
>> of the proposal, but does this list have "veto" power over proposals?
>>
>> Thx!
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 10, 2025 at 10:12 AM Tiago Freire <tmiguelf_at_[hidden]>
>> wrote:
>>
>>> I’m going to be upfront.
>>>
>>> I may a bit biased when it comes to iostream.
>>>
>>> I think it is irredeemably bad, there’s nothing good about it, I hate it
>>> to the core, and I rather see it replaced.
>>>
>>> And extending it, feels to very much like a wasted effort.
>>>
>>>
>>>
>>> I think is far more productive in the long run to have separate things
>>> that deal only with formatting (and extend that) and create an independent
>>> file or i/o interface that just does reads and writes without formatting.
>>>
>>>
>>>
>>>
>>>
>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On
>>> Behalf Of *Javier Estrada via Std-Proposals
>>> *Sent:* Monday, February 10, 2025 7:01 PM
>>> *To:* std-proposals_at_[hidden]
>>> *Cc:* Javier Estrada <iphone.javier.estrada_at_[hidden]>
>>> *Subject:* [std-proposals] std::bin manipulator for integer binary
>>> input/output
>>>
>>>
>>>
>>> There is a manipulator gap to read/write integer numbers in binary. As
>>> you well know, the standard manipulators are std::oct, std::dec,
>>> std::hex, which is essentially a format flag onto ios_base::basefield.
>>>
>>>
>>>
>>> Having a dedicated manipulator would close that gap and would eliminate
>>> the current "trick" of using std::bitset. The (abbreviated) example in
>>> cppreference .com reads:
>>>
>>>
>>>
>>> #include <bitset>
>>>
>>> #include <iostream>
>>>
>>>
>>>
>>> int main()
>>>
>>> {
>>>
>>> std::cout <http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in octal: " << std::oct << 42 << '*\n*'
>>>
>>> << "The number 42 in decimal: " << std::dec << 42 << '*\n*'
>>>
>>> << "The number 42 in hex: " << std::hex << 42 << '*\n*';
>>>
>>>
>>>
>>> // Note: there is no I/O manipulator that sets up a stream to print out
>>>
>>> // numbers in binary format (e.g. bin). If binary output is necessary
>>>
>>> // the std::bitset trick can be used:
>>>
>>> std::cout <http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in binary: " << std::bitset <http://en.cppreference.com/w/cpp/utility/bitset><8>{42} << '*\n*';
>>>
>>> }
>>>
>>>
>>>
>>> With a std::bin manipulator:
>>>
>>>
>>>
>>> #include <iostream>
>>>
>>> #include <sstream>
>>>
>>>
>>>
>>> int main()
>>>
>>> {
>>>
>>> // This yields 101010
>>> std::cout <http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in binary: " << std:: <http://en.cppreference.com/w/cpp/utility/bitset>bin << 42 << '*\n*';
>>>
>>> }
>>>
>>>
>>>
>>> It would also take advantage of other manipulators, like std::setw and std::setfill:
>>>
>>>
>>>
>>> #include <iostream>
>>>
>>> #include <sstream>
>>>
>>>
>>>
>>> int main()
>>>
>>> {
>>>
>>> // This yields *00*101010
>>>
>>> std::cout <http://en.cppreference.com/w/cpp/io/cout> << std::setw <http://en.cppreference.com/w/cpp/io/manip/setw>(8) << std::setfill('0');
>>>
>>> std::cout <http://en.cppreference.com/w/cpp/io/cout> << "The number 42 in binary: " << std:: <http://en.cppreference.com/w/cpp/utility/bitset>bin << 42 << '*\n*';
>>>
>>> }
>>>
>>>
>>>
>>> Reading binary numbers would also be addressed by the input streams.
>>>
>>>
>>>
>>> IF this proposal is considered, I see changes in:
>>>
>>> - A new bin flag in ios_base::basefield.
>>>
>>> - Support for the flag in ios_base::setf, ios_base::unsetf and ios_base::flags member functions.
>>>
>>> - Creation of the manipulator (similar to other manipulators) for the different char_traits
>>>
>>> - Support for binary parsing for input streams
>>>
>>> - Support for binary output for ostreams.
>>>
>>>
>>>
>>> std::ios_base in cppreference.com:
>>>
>>> https://en.cppreference.com/w/cpp/io/ios_base
>>>
>>>
>>>
>>> Integer I/O manipulators
>>>
>>> https://en.cppreference.com/w/cpp/io/manip/hex
>>>
>>>
>>>
>>> Regards,
>>>
>>> —Javier
>>>
>>>
>>>
>>>
>>>
>>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>