Topic: Introduction of a new keyword/fundamental type: byte
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Thu, 31 Dec 2015 07:30:42 -0800 (PST)
Raw View
------=_Part_6812_398742188.1451575842277
Content-Type: multipart/alternative;
boundary="----=_Part_6813_2094807798.1451575842287"
------=_Part_6813_2094807798.1451575842287
Content-Type: text/plain; charset=UTF-8
Hello (and happy new year for those who are in the pacific ocean).
I am wondering whether the introduction of a fundamental integer type
"byte" has already been discussed, and if so, what was the opinion of the
committee about it.
If such a fundamental thing is not in the standard, I guess it's for a good
reason.
byte, unsigned byte and signed byte would be equivalent to char, unsigned
char, and signed char except that :
- byte would be unsigned (contrarily to char which can be unsigned or
signed depending on the implementation)
- print functions and stream would treat them as integers (and not as
letters)
- uint_least8_t would be equal to unsigned byte, and int_least8_t would be
equal to signed byte
And it would allow to use "byte" instead of "unsigned char" in a lot of
places of the standard when the discussed topic has nothing to do with a
character.
But I guess that would be to too core/too major change to not introduce
fundamental breaking change.
I don't know, that's why I'm asking.
Thanks,
Vincent
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6813_2094807798.1451575842287
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello (and happy new year for those who are in the pacific=
ocean).<br><br>I am wondering whether the introduction of a fundamental in=
teger type "byte" has already been discussed, and if so, what was=
the opinion of the committee about it.<br>If such a fundamental thing is n=
ot in the standard, I guess it's for a good reason.<br><br><span style=
=3D"font-family: courier new,monospace;">byte</span>, <span style=3D"font-f=
amily: courier new,monospace;">unsigned byte</span> and <span style=3D"font=
-family: courier new,monospace;">signed byte</span> would be equivalent to =
<span style=3D"font-family: courier new,monospace;">char</span>, <span styl=
e=3D"font-family: courier new,monospace;">unsigned char</span>, and <span s=
tyle=3D"font-family: courier new,monospace;">signed char</span> except that=
:<br>- byte would be unsigned (contrarily to char which can be unsigned or=
signed depending on the implementation)<br>- print functions and stream wo=
uld treat them as integers (and not as letters)<br>- <code><span style=3D"f=
ont-family: courier new,monospace;">uint_least8_t</span><span style=3D"font=
-family: arial,sans-serif;"> would be equal to </span><span style=3D"font-f=
amily: courier new,monospace;">unsigned</span> byte<span style=3D"font-fami=
ly: arial,sans-serif;">, and </span></code><code>int_least8_t<span style=3D=
"font-family: arial,sans-serif;"> would be equal to </span>signed byte</cod=
e><br><br>And it would allow to use "<span style=3D"font-family: couri=
er new,monospace;">byte</span>" instead of "<span style=3D"font-f=
amily: courier new,monospace;">unsigned char</span>" in a lot of place=
s of the standard when the discussed topic has nothing to do with a charact=
er.<br>But I guess that would be to too core/too major change to not introd=
uce fundamental breaking change.<br>I don't know, that's why I'=
m asking.<br><br>Thanks,<br>Vincent<br><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_6813_2094807798.1451575842287--
------=_Part_6812_398742188.1451575842277--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 31 Dec 2015 12:34:58 -0300
Raw View
--001a1140f988bb4a4c0528336559
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 31/12/2015 12:30, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=B3:
>
> Hello (and happy new year for those who are in the pacific ocean).
>
> I am wondering whether the introduction of a fundamental integer type
"byte" has already been discussed, and if so, what was the opinion of the
committee about it.
> If such a fundamental thing is not in the standard, I guess it's for a
good reason.
>
> byte, unsigned byte and signed byte would be equivalent to char, unsigned
char, and signed char except that :
> - byte would be unsigned (contrarily to char which can be unsigned or
signed depending on the implementation)
> - print functions and stream would treat them as integers (and not as
letters)
> - uint_least8_t would be equal to unsigned byte, and int_least8_t would
be equal to signed byte
>
> And it would allow to use "byte" instead of "unsigned char" in a lot of
places of the standard when the discussed topic has nothing to do with a
character.
> But I guess that would be to too core/too major change to not introduce
fundamental breaking change.
> I don't know, that's why I'm asking.
What about sizeof(byte) considering CHAR_BIT?
>
> Thanks,
> Vincent
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a1140f988bb4a4c0528336559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 31/12/2015 12:30, "Vincent Reverdy" <<a href=3D"mailto:vinc=
e.rev@gmail.com">vince.rev@gmail.com</a>> escribi=C3=B3:<br>
><br>
> Hello (and happy new year for those who are in the pacific ocean).<br>
><br>
> I am wondering whether the introduction of a fundamental integer type =
"byte" has already been discussed, and if so, what was the opinio=
n of the committee about it.<br>
> If such a fundamental thing is not in the standard, I guess it's f=
or a good reason.<br>
><br>
> byte, unsigned byte and signed byte would be equivalent to char, unsig=
ned char, and signed char except that :<br>
> - byte would be unsigned (contrarily to char which can be unsigned or =
signed depending on the implementation)<br>
> - print functions and stream would treat them as integers (and not as =
letters)<br>
> - uint_least8_t would be equal to unsigned byte, and int_least8_t woul=
d be equal to signed byte<br>
><br>
> And it would allow to use "byte" instead of "unsigned c=
har" in a lot of places of the standard when the discussed topic has n=
othing to do with a character.<br>
> But I guess that would be to too core/too major change to not introduc=
e fundamental breaking change.<br>
> I don't know, that's why I'm asking.</p>
<p dir=3D"ltr">What about sizeof(byte) considering CHAR_BIT?</p>
<p dir=3D"ltr">><br>
> Thanks,<br>
> Vincent<br>
><br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1140f988bb4a4c0528336559--
.
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Thu, 31 Dec 2015 07:47:29 -0800 (PST)
Raw View
------=_Part_6825_766777702.1451576849228
Content-Type: multipart/alternative;
boundary="----=_Part_6826_1944198983.1451576849228"
------=_Part_6826_1944198983.1451576849228
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What do you mean?
Do you think that sizeof(byte) should be equal to CHAR_BIT instead of 1?
An evident problem would arise for typedefs using bytes as underlying types=
..
I personnally don't want uint_least8_t to be equal to CHAR_BIT.
But an operator bitcount() could be very useful.
Le jeudi 31 d=C3=A9cembre 2015 16:35:00 UTC+1, dgutson a =C3=A9crit :
>
>
> El 31/12/2015 12:30, "Vincent Reverdy" <vinc...@gmail.com <javascript:>>=
=20
> escribi=C3=B3:
> >
> > Hello (and happy new year for those who are in the pacific ocean).
> >
> > I am wondering whether the introduction of a fundamental integer type=
=20
> "byte" has already been discussed, and if so, what was the opinion of the=
=20
> committee about it.
> > If such a fundamental thing is not in the standard, I guess it's for a=
=20
> good reason.
> >
> > byte, unsigned byte and signed byte would be equivalent to char,=20
> unsigned char, and signed char except that :
> > - byte would be unsigned (contrarily to char which can be unsigned or=
=20
> signed depending on the implementation)
> > - print functions and stream would treat them as integers (and not as=
=20
> letters)
> > - uint_least8_t would be equal to unsigned byte, and int_least8_t would=
=20
> be equal to signed byte
> >
> > And it would allow to use "byte" instead of "unsigned char" in a lot of=
=20
> places of the standard when the discussed topic has nothing to do with a=
=20
> character.
> > But I guess that would be to too core/too major change to not introduce=
=20
> fundamental breaking change.
> > I don't know, that's why I'm asking.
>
> What about sizeof(byte) considering CHAR_BIT?
>
> >
> > Thanks,
> > Vincent
> >
> >
> > --=20
> >
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > Visit this group at=20
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
------=_Part_6826_1944198983.1451576849228
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What do you mean?<br>Do you think that sizeof(byte) should=
be equal to CHAR_BIT instead of 1?<br>An evident problem would arise for t=
ypedefs using bytes as underlying types.<br>I personnally don't want <c=
ode><span style=3D"font-family:courier new,monospace">uint_least8_t</span><=
span style=3D"font-family:arial,sans-serif"> </span></code>to be equal to C=
HAR_BIT.<br>But an operator <span style=3D"font-family: courier new,monospa=
ce;">bitcount()</span> could be very useful.<br><br>Le jeudi 31 d=C3=A9cemb=
re 2015 16:35:00 UTC+1, dgutson a =C3=A9crit=C2=A0:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><p dir=3D"ltr"><br>
El 31/12/2015 12:30, "Vincent Reverdy" <<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"8O4B8szaEQAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">vinc...@gmail.com</a>> e=
scribi=C3=B3:<br>
><br>
> Hello (and happy new year for those who are in the pacific ocean).<br>
><br>
> I am wondering whether the introduction of a fundamental integer type =
"byte" has already been discussed, and if so, what was the opinio=
n of the committee about it.<br>
> If such a fundamental thing is not in the standard, I guess it's f=
or a good reason.<br>
><br>
> byte, unsigned byte and signed byte would be equivalent to char, unsig=
ned char, and signed char except that :<br>
> - byte would be unsigned (contrarily to char which can be unsigned or =
signed depending on the implementation)<br>
> - print functions and stream would treat them as integers (and not as =
letters)<br>
> - uint_least8_t would be equal to unsigned byte, and int_least8_t woul=
d be equal to signed byte<br>
><br>
> And it would allow to use "byte" instead of "unsigned c=
har" in a lot of places of the standard when the discussed topic has n=
othing to do with a character.<br>
> But I guess that would be to too core/too major change to not introduc=
e fundamental breaking change.<br>
> I don't know, that's why I'm asking.</p>
<p dir=3D"ltr">What about sizeof(byte) considering CHAR_BIT?</p>
<p dir=3D"ltr">><br>
> Thanks,<br>
> Vincent<br>
><br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"8O4B8szaEQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">std-proposal...@<wbr>isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"8O4B8szaEQAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'https://groups.google.com/a/isocpp.org/group/std-proposals/&#=
39;;return true;" onclick=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/group/std-proposals/';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
</p>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_6826_1944198983.1451576849228--
------=_Part_6825_766777702.1451576849228--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 31 Dec 2015 14:11:47 -0300
Raw View
--001a1140a73a04b3f1052834c00a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 31/12/2015 12:47, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=B3:
>
> What do you mean?
> Do you think that sizeof(byte) should be equal to CHAR_BIT instead of 1?
One of the problems I see is that the size of byte might not be expressed
in terms of (integer) number of chars.
Another issue is that I fail to see the benefits of having "byte" other
than printing the numeric value, which can already be perfectly doable with
a type mapper:
template <class T>
struct printable_type_
{
typedef T Type;
};
template<>
struct printable_type_<char>
{
typedef int Type;
};
....and similar for signed/unsigned char (mapped to signed and unsigned int)=
..
Then
template<class T>
auto printable_value(T t)
{
return typename printable_type_<T>::Type(value);
}
So, when cout'ing, you can
cout << printable_value('a');
(I didn't compile it, just writing from a phone).
> An evident problem would arise for typedefs using bytes as underlying
types.
> I personnally don't want uint_least8_t to be equal to CHAR_BIT.
> But an operator bitcount() could be very useful.
>
> Le jeudi 31 d=C3=A9cembre 2015 16:35:00 UTC+1, dgutson a =C3=A9crit :
>>
>>
>> El 31/12/2015 12:30, "Vincent Reverdy" <vinc...@gmail.com> escribi=C3=B3=
:
>> >
>> > Hello (and happy new year for those who are in the pacific ocean).
>> >
>> > I am wondering whether the introduction of a fundamental integer type
"byte" has already been discussed, and if so, what was the opinion of the
committee about it.
>> > If such a fundamental thing is not in the standard, I guess it's for a
good reason.
>> >
>> > byte, unsigned byte and signed byte would be equivalent to char,
unsigned char, and signed char except that :
>> > - byte would be unsigned (contrarily to char which can be unsigned or
signed depending on the implementation)
>> > - print functions and stream would treat them as integers (and not as
letters)
>> > - uint_least8_t would be equal to unsigned byte, and int_least8_t
would be equal to signed byte
>> >
>> > And it would allow to use "byte" instead of "unsigned char" in a lot
of places of the standard when the discussed topic has nothing to do with a
character.
>> > But I guess that would be to too core/too major change to not
introduce fundamental breaking change.
>> > I don't know, that's why I'm asking.
>>
>> What about sizeof(byte) considering CHAR_BIT?
>>
>> >
>> > Thanks,
>> > Vincent
>> >
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
an email to std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>>
>> > Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a1140a73a04b3f1052834c00a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 31/12/2015 12:47, "Vincent Reverdy" <<a href=3D"mailto:vinc=
e.rev@gmail.com">vince.rev@gmail.com</a>> escribi=C3=B3:<br>
><br>
> What do you mean?<br>
> Do you think that sizeof(byte) should be equal to CHAR_BIT instead of =
1?</p>
<p dir=3D"ltr">One of the problems I see is that the size of byte might not=
be expressed in terms of (integer) number of chars.</p>
<p dir=3D"ltr">Another issue is that I fail to see the benefits of having &=
quot;byte" other than printing the numeric value, which can already be=
perfectly doable with a type mapper:</p>
<p dir=3D"ltr">template <class T><br>
struct printable_type_<br>
{<br>
=C2=A0=C2=A0=C2=A0 typedef T Type;<br>
};</p>
<p dir=3D"ltr">template<><br>
struct printable_type_<char><br>
{<br>
=C2=A0=C2=A0=C2=A0 typedef int Type;<br>
};</p>
<p dir=3D"ltr">...and similar for signed/unsigned char (mapped to signed an=
d unsigned int).</p>
<p dir=3D"ltr">Then<br>
template<class T><br>
auto printable_value(T t)<br>
{<br>
=C2=A0=C2=A0=C2=A0 return typename printable_type_<T>::Type(value);<b=
r>
}</p>
<p dir=3D"ltr">So, when cout'ing, you can<br>
=C2=A0=C2=A0=C2=A0 cout << printable_value('a');</p>
<p dir=3D"ltr">(I didn't compile it, just writing from a phone).</p>
<p dir=3D"ltr">> An evident problem would arise for typedefs using bytes=
as underlying types.<br>
> I personnally don't want uint_least8_t to be equal to CHAR_BIT.<br=
>
> But an operator bitcount() could be very useful.<br>
><br>
> Le jeudi 31 d=C3=A9cembre 2015 16:35:00 UTC+1, dgutson a =C3=A9crit=C2=
=A0:<br>
>><br>
>><br>
>> El 31/12/2015 12:30, "Vincent Reverdy" <<a href=3D"ma=
ilto:vinc...@gmail.com">vinc...@gmail.com</a>> escribi=C3=B3:<br>
>> ><br>
>> > Hello (and happy new year for those who are in the pacific oc=
ean).<br>
>> ><br>
>> > I am wondering whether the introduction of a fundamental inte=
ger type "byte" has already been discussed, and if so, what was t=
he opinion of the committee about it.<br>
>> > If such a fundamental thing is not in the standard, I guess i=
t's for a good reason.<br>
>> ><br>
>> > byte, unsigned byte and signed byte would be equivalent to ch=
ar, unsigned char, and signed char except that :<br>
>> > - byte would be unsigned (contrarily to char which can be uns=
igned or signed depending on the implementation)<br>
>> > - print functions and stream would treat them as integers (an=
d not as letters)<br>
>> > - uint_least8_t would be equal to unsigned byte, and int_leas=
t8_t would be equal to signed byte<br>
>> ><br>
>> > And it would allow to use "byte" instead of "u=
nsigned char" in a lot of places of the standard when the discussed to=
pic has nothing to do with a character.<br>
>> > But I guess that would be to too core/too major change to not=
introduce fundamental breaking change.<br>
>> > I don't know, that's why I'm asking.<br>
>><br>
>> What about sizeof(byte) considering CHAR_BIT?<br>
>><br>
>> ><br>
>> > Thanks,<br>
>> > Vincent<br>
>> ><br>
>> ><br>
>> > -- <br>
>> ><br>
>> > --- <br>
>> > You received this message because you are subscribed to the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.<br>
>> > To unsubscribe from this group and stop receiving emails from=
it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-pro=
posal...@isocpp.org</a>.<br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org">std-pr...@isocpp.org</a>.<br>
>><br>
>> > Visit this group at <a href=3D"https://groups.google.com/a/is=
ocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group=
/std-proposals/</a>.<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1140a73a04b3f1052834c00a--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Thu, 31 Dec 2015 18:25:23 +0100
Raw View
This is a multi-part message in MIME format.
--------------050205040502030407000101
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Am 31.12.2015 um 18:11 schrieb dgutson .:
>
>
> El 31/12/2015 12:47, "Vincent Reverdy" <vince.rev@gmail.com=20
> <mailto:vince.rev@gmail.com>> escribi=C3=B3:
> >
> > What do you mean?
> > Do you think that sizeof(byte) should be equal to CHAR_BIT instead of 1=
?
>
> One of the problems I see is that the size of byte might not be=20
> expressed in terms of (integer) number of chars.
>
> Another issue is that I fail to see the benefits of having "byte"=20
> other than printing the numeric value, which can already be perfectly=20
> doable with a type mapper:
>
If we had a time machine it'd be great to have one dedicated "byte" type=20
that is allowed to alias anything and have "char" be just that: a=20
sequence of characters and nothing else. Right now any kind of string=20
types that use "char*" internally can be a hindrance to optimization as=20
the compiler has to assume that one stupid "char*" pointer can alias=20
pretty much anything in the program. But oh well. People tend to talk a=20
lot about sailing ships here :-(
>
> template <class T>
> struct printable_type_
> {
> typedef T Type;
> };
>
> template<>
> struct printable_type_<char>
> {
> typedef int Type;
> };
>
> ...and similar for signed/unsigned char (mapped to signed and unsigned=20
> int).
>
> Then
> template<class T>
> auto printable_value(T t)
> {
> return typename printable_type_<T>::Type(value);
> }
>
> So, when cout'ing, you can
> cout << printable_value('a');
>
> (I didn't compile it, just writing from a phone).
>
> > An evident problem would arise for typedefs using bytes as=20
> underlying types.
> > I personnally don't want uint_least8_t to be equal to CHAR_BIT.
> > But an operator bitcount() could be very useful.
> >
> > Le jeudi 31 d=C3=A9cembre 2015 16:35:00 UTC+1, dgutson a =C3=A9crit :
> >>
> >>
> >> El 31/12/2015 12:30, "Vincent Reverdy" <vinc...@gmail.com=20
> <mailto:vinc...@gmail.com>> escribi=C3=B3:
> >> >
> >> > Hello (and happy new year for those who are in the pacific ocean).
> >> >
> >> > I am wondering whether the introduction of a fundamental integer=20
> type "byte" has already been discussed, and if so, what was the=20
> opinion of the committee about it.
> >> > If such a fundamental thing is not in the standard, I guess it's=20
> for a good reason.
> >> >
> >> > byte, unsigned byte and signed byte would be equivalent to char,=20
> unsigned char, and signed char except that :
> >> > - byte would be unsigned (contrarily to char which can be=20
> unsigned or signed depending on the implementation)
> >> > - print functions and stream would treat them as integers (and=20
> not as letters)
> >> > - uint_least8_t would be equal to unsigned byte, and int_least8_t=20
> would be equal to signed byte
> >> >
> >> > And it would allow to use "byte" instead of "unsigned char" in a=20
> lot of places of the standard when the discussed topic has nothing to=20
> do with a character.
> >> > But I guess that would be to too core/too major change to not=20
> introduce fundamental breaking change.
> >> > I don't know, that's why I'm asking.
> >>
> >> What about sizeof(byte) considering CHAR_BIT?
> >>
> >> >
> >> > Thanks,
> >> > Vincent
> >> >
> >> >
> >> > --
> >> >
> >> > ---
> >> > You received this message because you are subscribed to the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> >> > To unsubscribe from this group and stop receiving emails from it,=20
> send an email to std-proposal...@isocpp.org=20
> <mailto:std-proposal...@isocpp.org>.
> >> > To post to this group, send email to std-pr...@isocpp.org=20
> <mailto:std-pr...@isocpp.org>.
> >>
> >> > Visit this group at=20
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it,=20
> send an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> > To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> > Visit this group at=20
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------050205040502030407000101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 31.12.2015 um 18:11 schrieb dgutson .:<br>
<blockquote
cite=3D"mid:CAFdMc-3AmG1GVibjznam4NRkGyTRaEKf9QewbgGQK9H=3D3iJ93g@mail.gmai=
l.com"
type=3D"cite">
<p dir=3D"ltr"><br>
El 31/12/2015 12:47, "Vincent Reverdy" <<a
moz-do-not-send=3D"true" href=3D"mailto:vince.rev@gmail.com"><a c=
lass=3D"moz-txt-link-abbreviated" href=3D"mailto:vince.rev@gmail.com">vince=
..rev@gmail.com</a></a>>
escribi=C3=B3:<br>
><br>
> What do you mean?<br>
> Do you think that sizeof(byte) should be equal to CHAR_BIT
instead of 1?</p>
<p dir=3D"ltr">One of the problems I see is that the size of byte
might not be expressed in terms of (integer) number of chars.</p>
<p dir=3D"ltr">Another issue is that I fail to see the benefits of
having "byte" other than printing the numeric value, which can
already be perfectly doable with a type mapper:</p>
</blockquote>
If we had a time machine it'd be great to have one dedicated "byte"
type that is allowed to alias anything and have "char" be just that:
a sequence of characters and nothing else. Right now any kind of
string types that use "char*" internally can be a hindrance to
optimization as the compiler has to assume that one stupid "char*"
pointer can alias pretty much anything in the program. But oh well.
People tend to talk a lot about sailing ships here :-(<br>
<blockquote
cite=3D"mid:CAFdMc-3AmG1GVibjznam4NRkGyTRaEKf9QewbgGQK9H=3D3iJ93g@mail.gmai=
l.com"
type=3D"cite">
<p dir=3D"ltr">template <class T><br>
struct printable_type_<br>
{<br>
=C2=A0=C2=A0=C2=A0 typedef T Type;<br>
};</p>
<p dir=3D"ltr">template<><br>
struct printable_type_<char><br>
{<br>
=C2=A0=C2=A0=C2=A0 typedef int Type;<br>
};</p>
<p dir=3D"ltr">...and similar for signed/unsigned char (mapped to
signed and unsigned int).</p>
<p dir=3D"ltr">Then<br>
template<class T><br>
auto printable_value(T t)<br>
{<br>
=C2=A0=C2=A0=C2=A0 return typename printable_type_<T>::Type(v=
alue);<br>
}</p>
<p dir=3D"ltr">So, when cout'ing, you can<br>
=C2=A0=C2=A0=C2=A0 cout << printable_value('a');</p>
<p dir=3D"ltr">(I didn't compile it, just writing from a phone).</p>
<p dir=3D"ltr">> An evident problem would arise for typedefs
using bytes as underlying types.<br>
> I personnally don't want uint_least8_t to be equal to
CHAR_BIT.<br>
> But an operator bitcount() could be very useful.<br>
><br>
> Le jeudi 31 d=C3=A9cembre 2015 16:35:00 UTC+1, dgutson a =C3=
=A9crit=C2=A0:<br>
>><br>
>><br>
>> El 31/12/2015 12:30, "Vincent Reverdy" <<a
moz-do-not-send=3D"true" href=3D"mailto:vinc...@gmail.com"><a cla=
ss=3D"moz-txt-link-abbreviated" href=3D"mailto:vinc...@gmail.com">vinc...@g=
mail.com</a></a>>
escribi=C3=B3:<br>
>> ><br>
>> > Hello (and happy new year for those who are in the
pacific ocean).<br>
>> ><br>
>> > I am wondering whether the introduction of a
fundamental integer type "byte" has already been discussed, and
if so, what was the opinion of the committee about it.<br>
>> > If such a fundamental thing is not in the
standard, I guess it's for a good reason.<br>
>> ><br>
>> > byte, unsigned byte and signed byte would be
equivalent to char, unsigned char, and signed char except that :<br=
>
>> > - byte would be unsigned (contrarily to char which
can be unsigned or signed depending on the implementation)<br>
>> > - print functions and stream would treat them as
integers (and not as letters)<br>
>> > - uint_least8_t would be equal to unsigned byte,
and int_least8_t would be equal to signed byte<br>
>> ><br>
>> > And it would allow to use "byte" instead of
"unsigned char" in a lot of places of the standard when the
discussed topic has nothing to do with a character.<br>
>> > But I guess that would be to too core/too major
change to not introduce fundamental breaking change.<br>
>> > I don't know, that's why I'm asking.<br>
>><br>
>> What about sizeof(byte) considering CHAR_BIT?<br>
>><br>
>> ><br>
>> > Thanks,<br>
>> > Vincent<br>
>> ><br>
>> ><br>
>> > -- <br>
>> ><br>
>> > --- <br>
>> > You received this message because you are
subscribed to the Google Groups "ISO C++ Standard - Future
Proposals" group.<br>
>> > To unsubscribe from this group and stop receiving
emails from it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposal...@isocpp.org">std-proposal...@isocpp=
..org</a>.<br>
>> > To post to this group, send email to <a
moz-do-not-send=3D"true" href=3D"mailto:std-pr...@isocpp.org"><a =
class=3D"moz-txt-link-abbreviated" href=3D"mailto:std-pr...@isocpp.org">std=
-pr...@isocpp.org</a></a>.<br>
>><br>
>> > Visit this group at <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/group/std-proposal=
s/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails
from it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propos=
als+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a
moz-do-not-send=3D"true" href=3D"mailto:std-proposals@isocpp.org"=
><a class=3D"moz-txt-link-abbreviated" href=3D"mailto:std-proposals@isocpp.=
org">std-proposals@isocpp.org</a></a>.<br>
> Visit this group at <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/group/std-proposal=
s/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/group/std-proposals/=
">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------050205040502030407000101--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 31 Dec 2015 20:59:02 +0330
Raw View
--001a114a9350f78b8f052834fffb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
hi,
2015-12-31 19:04 GMT+03:30 dgutson . <danielgutson@gmail.com>:
>
> El 31/12/2015 12:30, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=
=B3:
> >
> > Hello (and happy new year for those who are in the pacific ocean).
> >
> > I am wondering whether the introduction of a fundamental integer type
> "byte" has already been discussed, and if so, what was the opinion of the
> committee about it.
> > If such a fundamental thing is not in the standard, I guess it's for a
> good reason.
> >
> > byte, unsigned byte and signed byte would be equivalent to char,
> unsigned char, and signed char except that :
> > - byte would be unsigned (contrarily to char which can be unsigned or
> signed depending on the implementation)
> > - print functions and stream would treat them as integers (and not as
> letters)
> > - uint_least8_t would be equal to unsigned byte, and int_least8_t would
> be equal to signed byte
> >
> > And it would allow to use "byte" instead of "unsigned char" in a lot of
> places of the standard when the discussed topic has nothing to do with a
> character.
> > But I guess that would be to too core/too major change to not introduce
> fundamental breaking change.
> > I don't know, that's why I'm asking.
>
> What about sizeof(byte) considering CHAR_BIT?
>
=E2=80=8Bstruct byte {
byte() {};
char x;
};
.....
byte i;
cout << "sizeof(i)=3D" << sizeof(i) << endl;
on msvc14.0 output is
sizeof(i)=3D1
looks a perfect library solution is possible if needed. I did not try gcc
but similar outcome is not a surprize (although a dumb compiler might
default to 4 as a minimum struct size).
regards,
FM.
=E2=80=8B
> >
> > Thanks,
> > Vincent
> >
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
how am I supposed to end the twisted road of your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a114a9350f78b8f052834fffb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><blockquote style=3D"margin:0px 0px 0px 40px;border:none;p=
adding:0px"><div class=3D"gmail_default" style=3D"font-family:'arial na=
rrow',sans-serif;font-size:large"><blockquote style=3D"margin:0px 0px 0=
px 40px;border:none;padding:0px"><div class=3D"gmail_default" style=3D"text=
-align:left;font-family:'arial narrow',sans-serif;font-size:large" =
dir=3D"ltr">hi,</div></blockquote></div></blockquote><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2015-12-31 19:04 GMT+0=
3:30 dgutson . <span dir=3D"ltr"><<a href=3D"mailto:danielgutson@gmail.c=
om" target=3D"_blank">danielgutson@gmail.com</a>></span>:</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span class=3D""><p dir=3D"ltr"><br>
El 31/12/2015 12:30, "Vincent Reverdy" <<a href=3D"mailto:vinc=
e.rev@gmail.com" target=3D"_blank">vince.rev@gmail.com</a>> escribi=C3=
=B3:<br>
><br>
> Hello (and happy new year for those who are in the pacific ocean).<br>
><br>
> I am wondering whether the introduction of a fundamental integer type =
"byte" has already been discussed, and if so, what was the opinio=
n of the committee about it.<br>
> If such a fundamental thing is not in the standard, I guess it's f=
or a good reason.<br>
><br>
> byte, unsigned byte and signed byte would be equivalent to char, unsig=
ned char, and signed char except that :<br>
> - byte would be unsigned (contrarily to char which can be unsigned or =
signed depending on the implementation)<br>
> - print functions and stream would treat them as integers (and not as =
letters)<br>
> - uint_least8_t would be equal to unsigned byte, and int_least8_t woul=
d be equal to signed byte<br>
><br>
> And it would allow to use "byte" instead of "unsigned c=
har" in a lot of places of the standard when the discussed topic has n=
othing to do with a character.<br>
> But I guess that would be to too core/too major change to not introduc=
e fundamental breaking change.<br>
> I don't know, that's why I'm asking.</p>
</span><p dir=3D"ltr">What about sizeof(byte) considering CHAR_BIT?</p></bl=
ockquote><div style=3D"text-align:left" dir=3D"ltr">=C2=A0</div><div style=
=3D"text-align:left;font-family:'arial narrow',sans-serif;font-size=
:large" class=3D"gmail_default" dir=3D"ltr">=E2=80=8Bstruct byte {=C2=A0</d=
iv><div style=3D"text-align:left;font-family:'arial narrow',sans-se=
rif;font-size:large" class=3D"gmail_default" dir=3D"ltr"><span class=3D"" s=
tyle=3D"white-space:pre"> </span>byte() {};</div><div style=3D"text-align:l=
eft;font-family:'arial narrow',sans-serif;font-size:large" class=3D=
"gmail_default" dir=3D"ltr"><span class=3D"" style=3D"white-space:pre"> </s=
pan>char x;</div><div style=3D"text-align:left;font-family:'arial narro=
w',sans-serif;font-size:large" class=3D"gmail_default" dir=3D"ltr">};</=
div><div style=3D"text-align:left;font-family:'arial narrow',sans-s=
erif;font-size:large" class=3D"gmail_default" dir=3D"ltr">....<br></div><di=
v style=3D"text-align:left;font-family:'arial narrow',sans-serif;fo=
nt-size:large" class=3D"gmail_default" dir=3D"ltr"><div class=3D"gmail_defa=
ult" dir=3D"ltr">byte i;</div><div class=3D"gmail_default" dir=3D"ltr">cout=
<< "sizeof(i)=3D" << sizeof(i) << endl;</div><=
div class=3D"gmail_default" dir=3D"ltr"><br></div><div class=3D"gmail_defau=
lt">on msvc14.0 output is</div><div class=3D"gmail_default"><br></div><div =
class=3D"gmail_default">sizeof(i)=3D1<br></div><div class=3D"gmail_default"=
><br></div><div class=3D"gmail_default">looks a perfect library solution is=
possible if needed. I did not try gcc but similar outcome is not a surpriz=
e (although a dumb compiler might default to 4 as a minimum struct size).</=
div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default"><br=
></div><div>regards,</div><div>FM.</div></div><div style=3D"text-align:left=
;font-family:'arial narrow',sans-serif;font-size:large" class=3D"gm=
ail_default" dir=3D"ltr"><br></div><div style=3D"text-align:left;font-famil=
y:'arial narrow',sans-serif;font-size:large" class=3D"gmail_default=
" dir=3D"ltr">=E2=80=8B</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div class=3D""><div class=3D=
"h5"><p dir=3D"ltr">><br>
> Thanks,<br>
> Vincent<br>
><br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" targ=
et=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.=
org/group/std-proposals/</a>.<br>
</p>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how a=
m I supposed to end the twisted road of=C2=A0 your hair in such a dark nigh=
t??<br>unless the candle of your face does shed some light upon my way!!!<b=
r></div></div></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114a9350f78b8f052834fffb--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 31 Dec 2015 21:17:23 +0330
Raw View
--001a113aab8aa2e5d0052835411f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
hi, me again
2015-12-31 20:41 GMT+03:30 dgutson . <danielgutson@gmail.com>:
> Another issue is that I fail to see the benefits of having "byte" other
> than printing the numeric value, which can already be perfectly doable wi=
th
> a type mapper:
>
=E2=80=8Bthe benefits are code clarity=E2=80=8B
=E2=80=8Band distinction between=E2=80=8B cases where a character is needed=
and where a
minimally short integer is intended. In other programming languages these
two types are distinct, but since in C style variadic functions such as io
functions(printf,scanf,...) the parameter types are identified via by the
format string, no need for elaborating things was felt. The problem showed
first when C++ iostreams were introduced. I can't estimate the severity of
this problem, but believe in the achievability and suitability of a library
solution that relies on type partitioning rather than stream manipulators
or convenience conversion functions.
regards,
FM.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a113aab8aa2e5d0052835411f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"text-align:left;font=
-family:'arial narrow',sans-serif;font-size:large" dir=3D"ltr">hi, =
me again</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr">2015-12-31 20:41 GMT+03:30 dgutson . <span dir=3D"ltr"><<a=
href=3D"mailto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmai=
l.com</a>></span>:</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
<p dir=3D"ltr">Another issue is that I fail to see the benefits of having &=
quot;byte" other than printing the numeric value, which can already be=
perfectly doable with a type mapper:</p></span></blockquote><div dir=3D"lt=
r"><div class=3D"gmail_default" style=3D"font-family:'arial narrow'=
,sans-serif;font-size:large;display:inline">=E2=80=8Bthe benefits are code =
clarity=E2=80=8B</div>=C2=A0<div class=3D"gmail_default" style=3D"font-fami=
ly:'arial narrow',sans-serif;font-size:large;display:inline">=E2=80=
=8Band distinction between=E2=80=8B cases where a character is needed and w=
here a minimally short integer is intended. In other programming languages =
these two types are distinct, but since in C style variadic functions such =
as io functions(printf,scanf,...) the parameter types are identified via by=
the format string, no need for elaborating things was felt. The problem sh=
owed first when C++ iostreams were introduced. I can't estimate the sev=
erity of this problem, but believe in the achievability and suitability of =
a library solution that relies on type partitioning rather than stream mani=
pulators or convenience conversion functions.</div></div><div dir=3D"ltr"><=
div class=3D"gmail_default" style=3D"font-family:'arial narrow',san=
s-serif;font-size:large;display:inline"><br></div></div><div dir=3D"ltr"><d=
iv class=3D"gmail_default" style=3D"font-family:'arial narrow',sans=
-serif;font-size:large;display:inline">regards,</div></div><div dir=3D"ltr"=
><div class=3D"gmail_default" style=3D"font-family:'arial narrow',s=
ans-serif;font-size:large;display:inline">FM.</div></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113aab8aa2e5d0052835411f--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 31 Dec 2015 14:58:37 -0300
Raw View
--001a11427b8478e973052835676c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 31/12/2015 14:29, "Farid Mehrabi" <farid.mehrabi@gmail.com> escribi=C3=
=B3:
>>>
>>> hi,
>
>
> 2015-12-31 19:04 GMT+03:30 dgutson . <danielgutson@gmail.com>:
>>
>>
>> El 31/12/2015 12:30, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=
=B3:
>> >
>> > Hello (and happy new year for those who are in the pacific ocean).
>> >
>> > I am wondering whether the introduction of a fundamental integer type
"byte" has already been discussed, and if so, what was the opinion of the
committee about it.
>> > If such a fundamental thing is not in the standard, I guess it's for a
good reason.
>> >
>> > byte, unsigned byte and signed byte would be equivalent to char,
unsigned char, and signed char except that :
>> > - byte would be unsigned (contrarily to char which can be unsigned or
signed depending on the implementation)
>> > - print functions and stream would treat them as integers (and not as
letters)
>> > - uint_least8_t would be equal to unsigned byte, and int_least8_t
would be equal to signed byte
>> >
>> > And it would allow to use "byte" instead of "unsigned char" in a lot
of places of the standard when the discussed topic has nothing to do with a
character.
>> > But I guess that would be to too core/too major change to not
introduce fundamental breaking change.
>> > I don't know, that's why I'm asking.
>>
>> What about sizeof(byte) considering CHAR_BIT?
>
>
> =E2=80=8Bstruct byte {
> byte() {};
> char x;
> };
> ....
> byte i;
> cout << "sizeof(i)=3D" << sizeof(i) << endl;
>
> on msvc14.0 output is
>
> sizeof(i)=3D1
Please reconsider my question (specially concerning CHAR_BIT where I
explain in more detail in my next mail).
Your answer answers a different question (one that I don't know) rather
than mine.
>
> looks a perfect library solution is possible if needed. I did not try gcc
but similar outcome is not a surprize (although a dumb compiler might
default to 4 as a minimum struct size).
>
>
> regards,
> FM.
>
> =E2=80=8B
>>
>> >
>> > Thanks,
>> > Vincent
>> >
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
an email to std-proposals+unsubscribe@isocpp.org.
>> > To post to this group, send email to std-proposals@isocpp.org.
>> > Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
>
> --
> how am I supposed to end the twisted road of your hair in such a dark
night??
> unless the candle of your face does shed some light upon my way!!!
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a11427b8478e973052835676c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 31/12/2015 14:29, "Farid Mehrabi" <<a href=3D"mailto:farid.=
mehrabi@gmail.com">farid.mehrabi@gmail.com</a>> escribi=C3=B3:<br>
>>><br>
>>> hi,<br>
><br>
><br>
> 2015-12-31 19:04 GMT+03:30 dgutson . <<a href=3D"mailto:danielgutso=
n@gmail.com">danielgutson@gmail.com</a>>:<br>
>><br>
>><br>
>> El 31/12/2015 12:30, "Vincent Reverdy" <<a href=3D"ma=
ilto:vince.rev@gmail.com">vince.rev@gmail.com</a>> escribi=C3=B3:<br>
>> ><br>
>> > Hello (and happy new year for those who are in the pacific oc=
ean).<br>
>> ><br>
>> > I am wondering whether the introduction of a fundamental inte=
ger type "byte" has already been discussed, and if so, what was t=
he opinion of the committee about it.<br>
>> > If such a fundamental thing is not in the standard, I guess i=
t's for a good reason.<br>
>> ><br>
>> > byte, unsigned byte and signed byte would be equivalent to ch=
ar, unsigned char, and signed char except that :<br>
>> > - byte would be unsigned (contrarily to char which can be uns=
igned or signed depending on the implementation)<br>
>> > - print functions and stream would treat them as integers (an=
d not as letters)<br>
>> > - uint_least8_t would be equal to unsigned byte, and int_leas=
t8_t would be equal to signed byte<br>
>> ><br>
>> > And it would allow to use "byte" instead of "u=
nsigned char" in a lot of places of the standard when the discussed to=
pic has nothing to do with a character.<br>
>> > But I guess that would be to too core/too major change to not=
introduce fundamental breaking change.<br>
>> > I don't know, that's why I'm asking.<br>
>><br>
>> What about sizeof(byte) considering CHAR_BIT?<br>
><br>
> =C2=A0<br>
> =E2=80=8Bstruct byte {=C2=A0<br>
> byte() {};<br>
> char x;<br>
> };<br>
> ....<br>
> byte i;<br>
> cout << "sizeof(i)=3D" << sizeof(i) << end=
l;<br>
><br>
> on msvc14.0 output is<br>
><br>
> sizeof(i)=3D1</p>
<p dir=3D"ltr">Please reconsider my question (specially concerning CHAR_BIT=
where I explain in more detail in my next mail).<br>
Your answer answers a different question (one that I don't know) rather=
than mine. <br></p>
<p dir=3D"ltr">><br>
> looks a perfect library solution is possible if needed. I did not try =
gcc but similar outcome is not a surprize (although a dumb compiler might d=
efault to 4 as a minimum struct size).<br>
><br>
><br>
> regards,<br>
> FM.<br>
><br>
> =E2=80=8B<br>
>><br>
>> ><br>
>> > Thanks,<br>
>> > Vincent<br>
>> ><br>
>> ><br>
>> > -- <br>
>> ><br>
>> > --- <br>
>> > You received this message because you are subscribed to the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.<br>
>> > To unsubscribe from this group and stop receiving emails from=
it, send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.=
org">std-proposals+unsubscribe@isocpp.org</a>.<br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
oposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> > Visit this group at <a href=3D"https://groups.google.com/a/is=
ocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group=
/std-proposals/</a>.<br>
>><br>
>> -- <br>
>><br>
>> --- <br>
>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br>
>> To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.=
org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br>
><br>
><br>
><br>
><br>
> -- <br>
> how am I supposed to end the twisted road of=C2=A0 your hair in such a=
dark night??<br>
> unless the candle of your face does shed some light upon my way!!!<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11427b8478e973052835676c--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Thu, 31 Dec 2015 09:59:46 -0800
Raw View
On 12/31/15 7:30 AM, Vincent Reverdy wrote:
> Hello (and happy new year for those who are in the pacific ocean).
>
> I am wondering whether the introduction of a fundamental integer type
> "byte" has already been discussed, and if so, what was the opinion of
> the committee about it.
I don't know the answer to that question.
But if you include <cstdint> you can use std::int8_t. Does that not
address your need?
Robert Ramey
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Thu, 31 Dec 2015 10:23:02 -0800 (PST)
Raw View
------=_Part_251_368587632.1451586182674
Content-Type: multipart/alternative;
boundary="----=_Part_252_1082380092.1451586182674"
------=_Part_252_1082380092.1451586182674
Content-Type: text/plain; charset=UTF-8
cstdint are typedefs of integral types. So:
uint8_t u = 42;
std::cout<<u<<std::endl; // Is likely to display a character, not an integer
A library solution would probably be possible, but my concern is more
related to the current standard where unsigned char are used in places
where byte would make much more sense.
Plus bytes should appear in the integer conversion and promotion part of
the standard.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_252_1082380092.1451586182674
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">cstdint are typedefs of integral types. So:<br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #000;" class=3D"styled-by-prettify">uint8_t u </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">42</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">cout</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">u</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">// Is likely to display a character, not an in=
teger</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div>A library solution would probably be possible, but=
my concern is more related to the current standard where <span style=3D"fo=
nt-family: courier new,monospace;">unsigned char</span> are used in places =
where <span style=3D"font-family: courier new,monospace;">byte</span> would=
make much more sense.<br>Plus <span style=3D"font-family: courier new,mono=
space;">bytes</span> should appear in the integer conversion and promotion =
part of the standard.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_252_1082380092.1451586182674--
------=_Part_251_368587632.1451586182674--
.
Author: Bo Persson <bop@gmb.dk>
Date: Thu, 31 Dec 2015 19:23:07 +0100
Raw View
On 2015-12-31 16:47, Vincent Reverdy wrote:
> What do you mean?
> Do you think that sizeof(byte) should be equal to CHAR_BIT instead of 1?
> An evident problem would arise for typedefs using bytes as underlying typ=
es.
> I personnally don't want |uint_least8_t|to be equal to CHAR_BIT.
> But an operator bitcount() could be very useful.
How useful is byte when CHAR_BIT is 9, or 16, or 24? And what size would=20
it be?
Bo Persson
>
> Le jeudi 31 d=C3=A9cembre 2015 16:35:00 UTC+1, dgutson a =C3=A9crit :
>
>
> El 31/12/2015 12:30, "Vincent Reverdy" <vinc...@gmail.com
> <javascript:>> escribi=C3=B3:
> >
> > Hello (and happy new year for those who are in the pacific ocean).
> >
> > I am wondering whether the introduction of a fundamental integer
> type "byte" has already been discussed, and if so, what was the
> opinion of the committee about it.
> > If such a fundamental thing is not in the standard, I guess it's
> for a good reason.
> >
> > byte, unsigned byte and signed byte would be equivalent to char,
> unsigned char, and signed char except that :
> > - byte would be unsigned (contrarily to char which can be
> unsigned or signed depending on the implementation)
> > - print functions and stream would treat them as integers (and
> not as letters)
> > - uint_least8_t would be equal to unsigned byte, and int_least8_t
> would be equal to signed byte
> >
> > And it would allow to use "byte" instead of "unsigned char" in a
> lot of places of the standard when the discussed topic has nothing
> to do with a character.
> > But I guess that would be to too core/too major change to not
> introduce fundamental breaking change.
> > I don't know, that's why I'm asking.
>
> What about sizeof(byte) considering CHAR_BIT?
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Thu, 31 Dec 2015 10:29:28 -0800
Raw View
On 12/31/15 10:23 AM, Vincent Reverdy wrote:
> cstdint are typedefs of integral types. So:
> |
> uint8_t u =42;
> std::cout<<u<<std::endl;// Is likely to display a character, not an integer
> |
It does as it's an alias. But that could be addressed if desired.
> A library solution would probably be possible,
more than that - it exists.
> but my concern is more
> related to the current standard where unsigned char are used in places
> where byte would make much more sense.
well you've got std::uint8_t for that.
> Plus bytes should appear in the integer conversion and promotion part of
> the standard.
unsigned/signed char are already addressed by the C++ type promotion
rules. I'm doubtful your "byte" would want to change these.
Robert Ramey
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 31 Dec 2015 21:42:54 +0300
Raw View
On 2015-12-31 20:11, dgutson . wrote:
>
> El 31/12/2015 12:47, "Vincent Reverdy" <vince.rev@gmail.com
> <mailto:vince.rev@gmail.com>> escribi=C3=B3:
> >
> > What do you mean?
> > Do you think that sizeof(byte) should be equal to CHAR_BIT instead of =
1?
>
> One of the problems I see is that the size of byte might not be
> expressed in terms of (integer) number of chars.
Byte is a minimal addressable unit of data - which is char in the=20
current language. I suspect you imply that byte is exactly 8 bits but=20
that is not true.
> Another issue is that I fail to see the benefits of having "byte" other
> than printing the numeric value, which can already be perfectly doable
> with a type mapper:
You can print chars in integer form in a much simpler way:
cout << static_cast< unsigned int >(c);
The point is that this is cumbersome, error-prone and should not be=20
required in the first place, just as it is not required when you output=20
ints.
I agree with the OP that a distinct type that has the size of 1 but is=20
interpreted as an integer is needed. The fact that there are three=20
distinct types (char, signed char and unsigned char) and all of them are=20
treated the same way by the standard library is an unfortunate mistake=20
IMHO, and it should be corrected.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 31 Dec 2015 12:54:57 -0600
Raw View
--001a114b157a4866f905283633e6
Content-Type: text/plain; charset=UTF-8
On 31 December 2015 at 12:42, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
>
> You can print chars in integer form in a much simpler way:
>
> cout << static_cast< unsigned int >(c);
>
> The point is that this is cumbersome, error-prone and should not be
> required in the first place, just as it is not required when you output
> ints.
>
I much prefer unary-plus for this case, as in:
cout << +c;
That gets rid of the cumbersome complaint.
> I agree with the OP that a distinct type that has the size of 1 but is
> interpreted as an integer is needed. The fact that there are three distinct
> types (char, signed char and unsigned char) and all of them are treated the
> same way by the standard library is an unfortunate mistake IMHO, and it
> should be corrected.
How do you plan on "correcting" it w/o breaking the world?
Adding yet another fundamental type brings in a whole plethora of headaches
(promotions, overload rules, aliasing rules, compatibility issues with code
that doesn't expect a new fundamental type, etc.).
IMO, this would be a huge EWG proposal. Even if you can get the committee
to show interest the first time you present it, be prepared to attend many
meetings to push it through.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114b157a4866f905283633e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 31 December 2015 at 12:42, Andrey Semashev <span dir=3D=
"ltr"><<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">an=
drey.semashev@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
><br></span>
You can print chars in integer form in a much simpler way:<br>
<br>
=C2=A0 cout << static_cast< unsigned int >(c);<br>
<br>
The point is that this is cumbersome, error-prone and should not be require=
d in the first place, just as it is not required when you output ints.<br><=
/blockquote><div><br></div><div>I much prefer unary-plus for this case, as =
in:</div><div><br></div><div>=C2=A0 =C2=A0 cout << +c;</div><div><br>=
</div><div>That gets rid of the cumbersome complaint.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">I agree with the OP that a distinct type th=
at has the size of 1 but is interpreted as an integer is needed. The fact t=
hat there are three distinct types (char, signed char and unsigned char) an=
d all of them are treated the same way by the standard library is an unfort=
unate mistake IMHO, and it should be corrected.</blockquote><div><br></div>=
<div>How do you plan on "correcting" it w/o breaking the world?</=
div><div><br></div><div>Adding yet another fundamental type brings in a who=
le plethora of headaches (promotions, overload rules, aliasing rules, compa=
tibility issues with code that doesn't expect a new fundamental type, e=
tc.).</div><div><br></div><div>IMO, this would be a huge EWG proposal.=C2=
=A0 Even if you can get the committee to show interest the first time you p=
resent it, be prepared to attend many meetings to push it through.</div><di=
v>--=C2=A0<br></div></div><div class=3D"gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114b157a4866f905283633e6--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 31 Dec 2015 16:09:47 -0300
Raw View
--001a1140f988fcae4b0528366550
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 31/12/2015 15:55, "Nevin Liber" <nevin@eviloverlord.com> escribi=C3=B3:
>
> On 31 December 2015 at 12:42, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
>>
>>
>> You can print chars in integer form in a much simpler way:
>>
>> cout << static_cast< unsigned int >(c);
>>
>> The point is that this is cumbersome, error-prone and should not be
required in the first place, just as it is not required when you output
ints.
>
>
> I much prefer unary-plus for this case, as in:
>
> cout << +c;
Or at least a manipulator
cout << numeric(c);
Or better:
cout << chars_as_numbers << c;
>
> That gets rid of the cumbersome complaint.
>
>>
>> I agree with the OP that a distinct type that has the size of 1 but is
interpreted as an integer is needed. The fact that there are three distinct
types (char, signed char and unsigned char) and all of them are treated the
same way by the standard library is an unfortunate mistake IMHO, and it
should be corrected.
>
>
> How do you plan on "correcting" it w/o breaking the world?
>
> Adding yet another fundamental type brings in a whole plethora of
headaches (promotions, overload rules, aliasing rules, compatibility issues
with code that doesn't expect a new fundamental type, etc.).
>
> IMO, this would be a huge EWG proposal. Even if you can get the
committee to show interest the first time you present it, be prepared to
attend many meetings to push it through.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a1140f988fcae4b0528366550
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 31/12/2015 15:55, "Nevin Liber" <<a href=3D"mailto:nevin@ev=
iloverlord.com">nevin@eviloverlord.com</a>> escribi=C3=B3:<br>
><br>
> On 31 December 2015 at 12:42, Andrey Semashev <<a href=3D"mailto:an=
drey.semashev@gmail.com">andrey.semashev@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> You can print chars in integer form in a much simpler way:<br>
>><br>
>> =C2=A0 cout << static_cast< unsigned int >(c);<br>
>><br>
>> The point is that this is cumbersome, error-prone and should not b=
e required in the first place, just as it is not required when you output i=
nts.<br>
><br>
><br>
> I much prefer unary-plus for this case, as in:<br>
><br>
> =C2=A0 =C2=A0 cout << +c;</p>
<p dir=3D"ltr">Or at least a manipulator</p>
<p dir=3D"ltr">cout << numeric(c);</p>
<p dir=3D"ltr">Or better:</p>
<p dir=3D"ltr">cout << chars_as_numbers << c;<br></p>
<p dir=3D"ltr">><br>
> That gets rid of the cumbersome complaint.<br>
> =C2=A0<br>
>><br>
>> I agree with the OP that a distinct type that has the size of 1 bu=
t is interpreted as an integer is needed. The fact that there are three dis=
tinct types (char, signed char and unsigned char) and all of them are treat=
ed the same way by the standard library is an unfortunate mistake IMHO, and=
it should be corrected.<br>
><br>
><br>
> How do you plan on "correcting" it w/o breaking the world?<b=
r>
><br>
> Adding yet another fundamental type brings in a whole plethora of head=
aches (promotions, overload rules, aliasing rules, compatibility issues wit=
h code that doesn't expect a new fundamental type, etc.).<br>
><br>
> IMO, this would be a huge EWG proposal.=C2=A0 Even if you can get the =
committee to show interest the first time you present it, be prepared to at=
tend many meetings to push it through.<br>
> --=C2=A0<br>
> =C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:n=
evin@eviloverlord.com">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404=
<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1140f988fcae4b0528366550--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 31 Dec 2015 14:04:36 -0500
Raw View
On 2015-12-31 13:54, Nevin Liber wrote:
> On 31 December 2015 at 12:42, Andrey Semashev wrote:
>> You can print chars in integer form in a much simpler way:
>>
>> cout << static_cast< unsigned int >(c);
>>
>> The point is that this is cumbersome, error-prone and should not be
>> required in the first place, just as it is not required when you output
>> ints.
>
> I much prefer unary-plus for this case, as in:
>
> cout << +c;
>
> That gets rid of the cumbersome complaint.
That's nice for *output*. Reading back numbers into a byte is much more
painful. (Speaking from recent personal experience...)
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Thu, 31 Dec 2015 11:13:26 -0800
Raw View
On 12/31/15 10:23 AM, Vincent Reverdy wrote:
> cstdint are typedefs of integral types. So:
Wouldn't the following create all you need right now?
using byte = std::uint8_t;
as for printing, why would assume that a "byte" should be printed as a
decimal integer. Why not a hax or octal. In any case, you'd be best
off by creating a couple of io manipulators named things like:
hex(?), octal(?), etc which can be used for all integer types. They
probably already exist anyway.
Robert Ramey
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 31 Dec 2015 22:36:35 +0300
Raw View
On 2015-12-31 21:54, Nevin Liber wrote:
>
> I much prefer unary-plus for this case, as in:
>
> cout << +c;
>
> That gets rid of the cumbersome complaint.
Nice. Still, the other complaints are enough to wish for improvement.
> How do you plan on "correcting" it w/o breaking the world?
>
> Adding yet another fundamental type brings in a whole plethora of
> headaches (promotions, overload rules, aliasing rules, compatibility
> issues with code that doesn't expect a new fundamental type, etc.).
>
> IMO, this would be a huge EWG proposal. Even if you can get the
> committee to show interest the first time you present it, be prepared to
> attend many meetings to push it through.
I didn't say it would be easy. ABI issues alone will make life harder
for this proposal. But that doesn't mean we shouldn't do anything about it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 31 Dec 2015 20:08:24 -0200
Raw View
On Thursday 31 December 2015 14:11:47 dgutson . wrote:
> El 31/12/2015 12:47, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=
=B3:
> > What do you mean?
> > Do you think that sizeof(byte) should be equal to CHAR_BIT instead of 1=
?
>=20
> One of the problems I see is that the size of byte might not be expressed
> in terms of (integer) number of chars.
By definition, the size of a byte is 1, containing CHAR_BIT bits.
> Another issue is that I fail to see the benefits of having "byte" other
> than printing the numeric value, which can already be perfectly doable wi=
th
> a type mapper:
Same here.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 31 Dec 2015 20:10:47 -0200
Raw View
On Thursday 31 December 2015 21:42:54 Andrey Semashev wrote:
> I agree with the OP that a distinct type that has the size of 1 but is
> interpreted as an integer is needed. The fact that there are three
> distinct types (char, signed char and unsigned char) and all of them are
> treated the same way by the standard library is an unfortunate mistake
> IMHO, and it should be corrected.
Isn't it easier to fix iostreams to treat signed and unsigned char as integers,
leaving char as character?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 1 Jan 2016 01:40:18 +0300
Raw View
On 2016-01-01 01:10, Thiago Macieira wrote:
> On Thursday 31 December 2015 21:42:54 Andrey Semashev wrote:
>> I agree with the OP that a distinct type that has the size of 1 but is
>> interpreted as an integer is needed. The fact that there are three
>> distinct types (char, signed char and unsigned char) and all of them are
>> treated the same way by the standard library is an unfortunate mistake
>> IMHO, and it should be corrected.
>
> Isn't it easier to fix iostreams to treat signed and unsigned char as integers,
> leaving char as character?
Yes, that's one way to do this (and frankly, this would be my preferred
way). However, this will likely break existing code, which probably
makes this solution unrealistic.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 31 Dec 2015 20:35:53 -0300
Raw View
--001a1140a73a9c2b8905283a1d30
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 31/12/2015 19:10, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3:
>
> On Thursday 31 December 2015 21:42:54 Andrey Semashev wrote:
> > I agree with the OP that a distinct type that has the size of 1 but is
> > interpreted as an integer is needed. The fact that there are three
> > distinct types (char, signed char and unsigned char) and all of them ar=
e
> > treated the same way by the standard library is an unfortunate mistake
> > IMHO, and it should be corrected.
>
> Isn't it easier to fix iostreams to treat signed and unsigned char as
integers,
> leaving char as character?
No it isn't: you might want to "fix" the standard (for your definition of
fix) but will you pay the bill to fix all the broken existing code?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a1140a73a9c2b8905283a1d30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 31/12/2015 19:10, "Thiago Macieira" <<a href=3D"mailto:thia=
go@macieira.org">thiago@macieira.org</a>> escribi=C3=B3:<br>
><br>
> On Thursday 31 December 2015 21:42:54 Andrey Semashev wrote:<br>
> > I agree with the OP that a distinct type that has the size of 1 b=
ut is<br>
> > interpreted as an integer is needed. The fact that there are thre=
e<br>
> > distinct types (char, signed char and unsigned char) and all of t=
hem are<br>
> > treated the same way by the standard library is an unfortunate mi=
stake<br>
> > IMHO, and it should be corrected.<br>
><br>
> Isn't it easier to fix iostreams to treat signed and unsigned char=
as integers,<br>
> leaving char as character?</p>
<p dir=3D"ltr">No it isn't: you might want to "fix" the stand=
ard (for your definition of fix) but will you pay the bill to fix all the b=
roken existing code?</p>
<p dir=3D"ltr">><br>
> --<br>
> Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
> =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
> =C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
> =C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF=
4 5358<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1140a73a9c2b8905283a1d30--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Thu, 31 Dec 2015 20:36:31 -0300
Raw View
--047d7bdc1254e822ec05283a1f36
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 31/12/2015 19:08, "Thiago Macieira" <thiago@macieira.org> escribi=C3=B3:
>
> On Thursday 31 December 2015 14:11:47 dgutson . wrote:
> > El 31/12/2015 12:47, "Vincent Reverdy" <vince.rev@gmail.com> escribi=C3=
=B3:
> > > What do you mean?
> > > Do you think that sizeof(byte) should be equal to CHAR_BIT instead of
1?
> >
> > One of the problems I see is that the size of byte might not be
expressed
> > in terms of (integer) number of chars.
>
> By definition, the size of a byte is 1, containing CHAR_BIT bits.
Could you please point me to such definition in the std?
>
> > Another issue is that I fail to see the benefits of having "byte" other
> > than printing the numeric value, which can already be perfectly doable
with
> > a type mapper:
>
> Same here.
What same?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
https://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--047d7bdc1254e822ec05283a1f36
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 31/12/2015 19:08, "Thiago Macieira" <<a href=3D"mailto:thia=
go@macieira.org">thiago@macieira.org</a>> escribi=C3=B3:<br>
><br>
> On Thursday 31 December 2015 14:11:47 dgutson . wrote:<br>
> > El 31/12/2015 12:47, "Vincent Reverdy" <<a href=3D"m=
ailto:vince.rev@gmail.com">vince.rev@gmail.com</a>> escribi=C3=B3:<br>
> > > What do you mean?<br>
> > > Do you think that sizeof(byte) should be equal to CHAR_BIT i=
nstead of 1?<br>
> ><br>
> > One of the problems I see is that the size of byte might not be e=
xpressed<br>
> > in terms of (integer) number of chars.<br>
><br>
> By definition, the size of a byte is 1, containing CHAR_BIT bits.</p>
<p dir=3D"ltr">Could you please point me to such definition in the std?</p>
<p dir=3D"ltr">><br>
> > Another issue is that I fail to see the benefits of having "=
byte" other<br>
> > than printing the numeric value, which can already be perfectly d=
oable with<br>
> > a type mapper:<br>
><br>
> Same here.</p>
<p dir=3D"ltr">What same?</p>
<p dir=3D"ltr">><br>
> --<br>
> Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
> =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
> =C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
> =C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF=
4 5358<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7bdc1254e822ec05283a1f36--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 01 Jan 2016 02:03:23 -0200
Raw View
On Thursday 31 December 2015 20:36:31 dgutson . wrote:
> > By definition, the size of a byte is 1, containing CHAR_BIT bits.
>
> Could you please point me to such definition in the std?
1.7 [intro.memory] p1 says "The fundamental storage unit in the C ++ memory
model is the byte. A byte is at least large enough to contain any member of
the basic execution character set [...] The memory available to a C ++ program
consists of one or more sequences of contiguous bytes. Every byte has a unique
address."
5.3.3 [expr.sizeof] p1 says "The sizeof operator yields the number of bytes in
the object representation of its operand. [...] sizeof(char), sizeof(signed
char) and sizeof(unsigned char) are 1."
Therefore, 1 char = 1 byte, by definition, and said byte has CHAR_BIT bits,
which is 8 or more.
Similar wording exists in the C standard. C11 says in "6.5.3.4 The sizeof and
_Alignof operators",
2 The sizeof operator yields the size (in bytes) of its operand.
4 When sizeof is applied to an operand that has type char, unsigned char, or
signed char, (or a qualified version thereof) the result is 1.
And specifically in "3.6 byte", it defines byte as "addressable unit of data
storage large enough to hold any member of the basic character set".
The only difference between C++14 and C11 is C++14's requirement that byte be
at least 8 bits. C++11 wasn't explicit, but implied that because of u8 string
literals.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 1 Jan 2016 13:29:46 +0300
Raw View
On 2016-01-01 01:40, Andrey Semashev wrote:
> On 2016-01-01 01:10, Thiago Macieira wrote:
>> On Thursday 31 December 2015 21:42:54 Andrey Semashev wrote:
>>> I agree with the OP that a distinct type that has the size of 1 but is
>>> interpreted as an integer is needed. The fact that there are three
>>> distinct types (char, signed char and unsigned char) and all of them are
>>> treated the same way by the standard library is an unfortunate mistake
>>> IMHO, and it should be corrected.
>>
>> Isn't it easier to fix iostreams to treat signed and unsigned char as
>> integers,
>> leaving char as character?
>
> Yes, that's one way to do this (and frankly, this would be my preferred
> way). However, this will likely break existing code, which probably
> makes this solution unrealistic.
Actually, there might be a way to make it a non-breaking change. We
could introduce a new fmtflag, which, if set, whould make streams to
format/parse signed and unsigned chars as integers and pointers to
signed/unsigned chars format/parse as void* pointers. It wouldn't fix
the problem by default but at least there would be a way to make streams
behave the way we want.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Fri, 1 Jan 2016 11:59:41 +0100
Raw View
On 2015-12-31 19:45, Andrey Semashev wrote:
> On 2015-12-31 21:23, Bo Persson wrote:
>> On 2015-12-31 16:47, Vincent Reverdy wrote:
>>> What do you mean?
>>> Do you think that sizeof(byte) should be equal to CHAR_BIT instead of 1?
>>> An evident problem would arise for typedefs using bytes as underlying
>>> types.
>>> I personnally don't want |uint_least8_t|to be equal to CHAR_BIT.
>>> But an operator bitcount() could be very useful.
>>
>>
>> How useful is byte when CHAR_BIT is 9, or 16, or 24? And what size would
>> it be?
>
> I think you're confusing byte with octet.
>
Yes, I am, and I believe most people will assume that.
Therefore I think it would be extremely confusing to introduce a type
'byte' that is an octet on most systems, but not guaranteed to be that
on all.
Bo Persson
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Fri, 1 Jan 2016 16:47:21 +0100
Raw View
On 2016-01-01 12:38, Andrey Semashev wrote:
> On 2016-01-01 13:59, Bo Persson wrote:
>> On 2015-12-31 19:45, Andrey Semashev wrote:
>>> On 2015-12-31 21:23, Bo Persson wrote:
>>>> On 2015-12-31 16:47, Vincent Reverdy wrote:
>>>>> What do you mean?
>>>>> Do you think that sizeof(byte) should be equal to CHAR_BIT instead
>>>>> of 1?
>>>>> An evident problem would arise for typedefs using bytes as underlying
>>>>> types.
>>>>> I personnally don't want |uint_least8_t|to be equal to CHAR_BIT.
>>>>> But an operator bitcount() could be very useful.
>>>>
>>>>
>>>> How useful is byte when CHAR_BIT is 9, or 16, or 24? And what size
>>>> would
>>>> it be?
>>>
>>> I think you're confusing byte with octet.
>>
>> Yes, I am, and I believe most people will assume that.
>>
>> Therefore I think it would be extremely confusing to introduce a type
>> 'byte' that is an octet on most systems, but not guaranteed to be that
>> on all.
>
> Most people assume bool and char are 8-bit, short is 16-bit and int is
> 32-bit, while all of it are false assumptions. People's misconceptions
> should not guide the language evolution.
>
I still don't see that adding more possible misconceptions is a great
idea either.
Perhaps if you call it something else than byte. Like raw_memory, or
something?
Bo Persson
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.