Date: Tue, 11 Feb 2025 16:49:58 -0800
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
>>
>>
>>
>>
>>
>>
>
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
>>
>>
>>
>>
>>
>>
>
Received on 2025-02-12 00:50:14