Date: Wed, 12 Feb 2025 05:50:32 +0000
Given that you would need to write new code, there's nothing that is stopping an implementer of std::bin from using format_to or charconv to do it (which is probably what you should be doing anyways).
Just because scanf/printf has been historically used to implement parts of it, it doesn't mean that it has to be used to implement everything.
Leave those details to the implementer, and focus on the value of the proposal.
If it's doable, it's not an impediment.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Chris Ryan via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, February 12, 2025 6:06:59 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Chris Ryan <chrisr98008_at_[hidden]>; Javier Estrada <iphone.javier.estrada_at_[hidden]>
Subject: Re: [std-proposals] std::bin manipulator for integer binary input/output
> (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]<mailto: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]<mailto: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]<mailto:iphone.javier.estrada_at_[hidden]>>
Sent: Tuesday, February 11, 2025 6:13:25 PM
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]g<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto: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]<mailto: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]<mailto: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]<mailto:std-proposals_at_[hidden]>
Cc: Javier Estrada <iphone.javier.estrada_at_[hidden]<mailto: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 00101010
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<http://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]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Just because scanf/printf has been historically used to implement parts of it, it doesn't mean that it has to be used to implement everything.
Leave those details to the implementer, and focus on the value of the proposal.
If it's doable, it's not an impediment.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Chris Ryan via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, February 12, 2025 6:06:59 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Chris Ryan <chrisr98008_at_[hidden]>; Javier Estrada <iphone.javier.estrada_at_[hidden]>
Subject: Re: [std-proposals] std::bin manipulator for integer binary input/output
> (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]<mailto: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]<mailto: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]<mailto:iphone.javier.estrada_at_[hidden]>>
Sent: Tuesday, February 11, 2025 6:13:25 PM
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]g<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto: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]<mailto: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]<mailto: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]<mailto:std-proposals_at_[hidden]>
Cc: Javier Estrada <iphone.javier.estrada_at_[hidden]<mailto: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 00101010
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<http://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]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-02-12 05:50:36