Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Defect Report: I/O streams lack support for binary number formatting
32 views
Skip to first unread message
stefan.h...@gmail.com
May 4, 2016, 9:01:01 AM5/4/16
to
C++14 introduced binary literals to the core language. However, the I/O streams library has no support for formatting integers as binary numbers, in the same way as they can be formatted as hex or oct numbers. This is inconsistent.
The resolution would include adding one new formatting flag to class std::ios_base in the basefield group. It could be named 'bin', unless there's a problem with this that I can't see.
Furthermore, there would be the need for a corresponding stream manipulator.
Unfortunately, I don't oversee where else in the standard there would have to be changes because of this. This would be a question for people with intimate knowledge of the stream library, I guess.
Taking the current draft N4582, the formatting flags are defined in 27.5.3, and the manipulators are defined in 27.5.1, but there will certainly have to be changes in a number of other places.
Cheers
Stefan Heinzmann
The resolution would include adding one new formatting flag to class std::ios_base in the basefield group. It could be named 'bin', unless there's a problem with this that I can't see.
Furthermore, there would be the need for a corresponding stream manipulator.
Unfortunately, I don't oversee where else in the standard there would have to be changes because of this. This would be a question for people with intimate knowledge of the stream library, I guess.
Taking the current draft N4582, the formatting flags are defined in 27.5.3, and the manipulators are defined in 27.5.1, but there will certainly have to be changes in a number of other places.
Cheers
Stefan Heinzmann
Robert Wessel
May 4, 2016, 9:22:29 AM5/4/16
to
On Wed, 4 May 2016 06:00:47 -0700 (PDT), stefan.h...@gmail.com
wrote:
Eh. There's really very little need to do binary formatted text I/O.
Binary literals server a number of programming related purposes, but
are not usually something you actually want to input or output.
Sure, we can find an occassional use case here and there, but not
something I really think needs any serious effort. There are also
places where adding binary to text I/O would add some
incompatibilities. What, for example, should strtol() or scanf() do
with something that looked like a binary literal in the input? If you
interpret it as such, you may well be changing existing behavior.
Probably best to leave it alone.
wrote:
Binary literals server a number of programming related purposes, but
are not usually something you actually want to input or output.
Sure, we can find an occassional use case here and there, but not
something I really think needs any serious effort. There are also
places where adding binary to text I/O would add some
incompatibilities. What, for example, should strtol() or scanf() do
with something that looked like a binary literal in the input? If you
interpret it as such, you may well be changing existing behavior.
Probably best to leave it alone.
stefan.h...@gmail.com
May 4, 2016, 9:51:52 AM5/4/16
to
> Eh. There's really very little need to do binary formatted text I/O.
> Binary literals server a number of programming related purposes, but
> are not usually something you actually want to input or output.
I'd say there's no less need than for octal output. If there was a good reason to support binary for literals, why doesn't the same reason apply for I/O? I frequently write low-level code which works directly with hardware, and binary would quite frequently be the best format for displaying the value of a register, for example. Or imagine writing a debugger.
> Binary literals server a number of programming related purposes, but
> are not usually something you actually want to input or output.
But even if you were right, wouldn't consistency alone be a good motivation already?
> Sure, we can find an occassional use case here and there, but not
> something I really think needs any serious effort. There are also
> places where adding binary to text I/O would add some
> incompatibilities. What, for example, should strtol() or scanf() do
> with something that looked like a binary literal in the input? If you
> interpret it as such, you may well be changing existing behavior.
> Probably best to leave it alone.
Anyway, strtol() and scanf() are C functions, not C++. I would opt for changing their behavior only once C starts supporting binary literals. That would be for the C standards group to consider.
Cheers
Stefan
Alf P. Steinbach
May 4, 2016, 12:19:01 PM5/4/16
to
On 04.05.2016 15:00, stefan.h...@gmail.com wrote:
> C++14 introduced binary literals to the core language. However, the
> I/O streams library has no support for formatting integers as binary
> numbers, in the same way as they can be formatted as hex or oct
> numbers. This is inconsistent.
You can always just use std::bitset for that purpose; it converts to a
> C++14 introduced binary literals to the core language. However, the
> I/O streams library has no support for formatting integers as binary
> numbers, in the same way as they can be formatted as hex or oct
> numbers. This is inconsistent.
string of 0 and 1 characters.
Anyway, the correct place to post a defect report used to be
comp.std.c++, but now it's a google group somewhere. The last defect
report I posted, which was a real issue (lack of wide stream support for
user defined conversion to wchar const*), received no reply and hasn't
yet been fixed. As I recall I then contacted the person doing the
screening work, whom I knew from Usenet earlier, and got the impression
that something would be done. But it hasn't. I concluded then that the
defect report process had stopped working in general, and later, when I
saw some of the stuff in C++14, I concluded that even the committee had
stopped working as a serious standardization body.
Still if you want to try it you can find the group(s) over at isocpp.org.
Cheers & hth.,
- Alf
stefan.h...@gmail.com
May 4, 2016, 1:39:31 PM5/4/16
to
> You can always just use std::bitset for that purpose; it converts to a
> string of 0 and 1 characters.
> Anyway, the correct place to post a defect report used to be
> comp.std.c++, but now it's a google group somewhere. The last defect
> report I posted, which was a real issue (lack of wide stream support for
> user defined conversion to wchar const*), received no reply and hasn't
> yet been fixed. As I recall I then contacted the person doing the
> screening work, whom I knew from Usenet earlier, and got the impression
> that something would be done. But it hasn't. I concluded then that the
> defect report process had stopped working in general, and later, when I
> saw some of the stuff in C++14, I concluded that even the committee had
> stopped working as a serious standardization body.
>
> Still if you want to try it you can find the group(s) over at isocpp.org.
Cheers
Stefan
Robert Wessel
May 4, 2016, 5:25:30 PM5/4/16
to
On Wed, 4 May 2016 06:51:38 -0700 (PDT), stefan.h...@gmail.com
wrote:
>> Eh. There's really very little need to do binary formatted text I/O.
>> Binary literals server a number of programming related purposes, but
>> are not usually something you actually want to input or output.
>
>I'd say there's no less need than for octal output. If there was a good reason to support binary for literals, why doesn't the same reason apply for I/O? I frequently write low-level code which works directly with hardware, and binary would quite frequently be the best format for displaying the value of a register, for example. Or imagine writing a debugger.
Adding octal (and hex) to some of the default input functions was a
mistake. Having them as options would have made sense, and would
probably have provided a path to adding binary text I/O as well. But
we are where we are. And yes, there are small use cases for binary
text I/O.
>But even if you were right, wouldn't consistency alone be a good motivation already?
Consistency is a good thing. Right up to the point where it gets in
the way of a good, useful, and easy to implement feature (like binary
literals), because it's difficult to figure out how to support it in
places we really don't care about anyway.
>> Sure, we can find an occassional use case here and there, but not
>> something I really think needs any serious effort. There are also
>> places where adding binary to text I/O would add some
>> incompatibilities. What, for example, should strtol() or scanf() do
>> with something that looked like a binary literal in the input? If you
>> interpret it as such, you may well be changing existing behavior.
>> Probably best to leave it alone.
>
>Yes, there's a risk of changing the behavior in some corner cases. I haven't spent any time to find out what those cases are and whether they would have to be considered serious. That's open for debate.
And the committee has always been far more reluctant to introduce
changes that can cause even minor breakage. Even more so if it
introduces silent *runtime* breakage. So my guess is that requiring
the change to strtol or scanf would have made binary literals
impossible to get through the committee. But if you can define a set
of changes (possible even excluding the legacy C functions), that
don't break anything (and the normal cin/cout stuff may be there), you
may have a shot. And I certainly wouldn't object, I just would
continue to mostly not care.
>Anyway, strtol() and scanf() are C functions, not C++. I would opt for changing their behavior only once C starts supporting binary literals. That would be for the C standards group to consider.
They're included in the C++ standard by reference.
wrote:
>> Eh. There's really very little need to do binary formatted text I/O.
>> Binary literals server a number of programming related purposes, but
>> are not usually something you actually want to input or output.
>
>I'd say there's no less need than for octal output. If there was a good reason to support binary for literals, why doesn't the same reason apply for I/O? I frequently write low-level code which works directly with hardware, and binary would quite frequently be the best format for displaying the value of a register, for example. Or imagine writing a debugger.
mistake. Having them as options would have made sense, and would
probably have provided a path to adding binary text I/O as well. But
we are where we are. And yes, there are small use cases for binary
text I/O.
>But even if you were right, wouldn't consistency alone be a good motivation already?
the way of a good, useful, and easy to implement feature (like binary
literals), because it's difficult to figure out how to support it in
places we really don't care about anyway.
>> Sure, we can find an occassional use case here and there, but not
>> something I really think needs any serious effort. There are also
>> places where adding binary to text I/O would add some
>> incompatibilities. What, for example, should strtol() or scanf() do
>> with something that looked like a binary literal in the input? If you
>> interpret it as such, you may well be changing existing behavior.
>> Probably best to leave it alone.
>
>Yes, there's a risk of changing the behavior in some corner cases. I haven't spent any time to find out what those cases are and whether they would have to be considered serious. That's open for debate.
changes that can cause even minor breakage. Even more so if it
introduces silent *runtime* breakage. So my guess is that requiring
the change to strtol or scanf would have made binary literals
impossible to get through the committee. But if you can define a set
of changes (possible even excluding the legacy C functions), that
don't break anything (and the normal cin/cout stuff may be there), you
may have a shot. And I certainly wouldn't object, I just would
continue to mostly not care.
>Anyway, strtol() and scanf() are C functions, not C++. I would opt for changing their behavior only once C starts supporting binary literals. That would be for the C standards group to consider.
Robert Wessel
May 4, 2016, 5:28:06 PM5/4/16
to
On Wed, 04 May 2016 16:25:24 -0500, Robert Wessel
<robert...@yahoo.com> wrote:
>And the committee has always been far more reluctant to introduce
>changes that can cause even minor breakage. Even more so if it
>introduces silent *runtime* breakage. So my guess is that requiring
>the change to strtol or scanf would have made binary literals
>impossible to get through the committee. But if you can define a set
>of changes (possible even excluding the legacy C functions), that
>don't break anything (and the normal cin/cout stuff may be there), you
>may have a shot. And I certainly wouldn't object, I just would
>continue to mostly not care.
Except to the extent that any time spent on pointless stuff like that
<robert...@yahoo.com> wrote:
>And the committee has always been far more reluctant to introduce
>changes that can cause even minor breakage. Even more so if it
>introduces silent *runtime* breakage. So my guess is that requiring
>the change to strtol or scanf would have made binary literals
>impossible to get through the committee. But if you can define a set
>of changes (possible even excluding the legacy C functions), that
>don't break anything (and the normal cin/cout stuff may be there), you
>may have a shot. And I certainly wouldn't object, I just would
>continue to mostly not care.
takes them away from considering stuff I actually would like.
Richard
May 4, 2016, 6:01:57 PM5/4/16
to
[Please do not mail me a copy of your followup]
Robert Wessel <robert...@yahoo.com> spake the secret code
<v8qkib12qujjunpbl...@4ax.com> thusly:
>Except to the extent that any time spent on pointless stuff like that
>takes them away from considering stuff I actually would like.
Particularly since this is something that you can solve on your own
with a user library and doesn't require a change in the standard in
order to get on with your life and solving your problem.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Robert Wessel <robert...@yahoo.com> spake the secret code
<v8qkib12qujjunpbl...@4ax.com> thusly:
>Except to the extent that any time spent on pointless stuff like that
>takes them away from considering stuff I actually would like.
with a user library and doesn't require a change in the standard in
order to get on with your life and solving your problem.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
0 new messages