------=_Part_1487_207865428.1543430760571
Content-Type: multipart/alternative;
 boundary="----=_Part_1488_1459662714.1543430760571"

------=_Part_1488_1459662714.1543430760571
Content-Type: text/plain; charset="UTF-8"

I noticed, that in several places in the standard, e.g in [basic.types],
char, unsigned char, or std::byte are mentioned separately (basically as
types that types that can alias anything else from my understanding).
There's no signed char in the list, despite it's a separate type.
What may be a reason for that?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d78eb05f-164d-4cc1-81fa-1c6740ebab25%40isocpp.org.

------=_Part_1488_1459662714.1543430760571
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I noticed, that in several places in the standard, e.g in =
[basic.types], char, unsigned char, or std::byte are mentioned separately (=
basically as types that types that can alias anything else from my understa=
nding). There&#39;s no signed char in the list, despite it&#39;s a separate=
 type.=C2=A0<div>What may be a reason for that?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d78eb05f-164d-4cc1-81fa-1c6740ebab25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d78eb05f-164d-4cc1-81fa-1c6740ebab25=
%40isocpp.org</a>.<br />

------=_Part_1488_1459662714.1543430760571--

------=_Part_1487_207865428.1543430760571--

.

On Wednesday, 28 November 2018 10:46:00 PST riadwaw@gmail.com wrote:
> I noticed, that in several places in the standard, e.g in [basic.types],
> char, unsigned char, or std::byte are mentioned separately (basically as
> types that types that can alias anything else from my understanding).
> There's no signed char in the list, despite it's a separate type.
> What may be a reason for that?

Because it's signed. As a signed integer, there could be bit patterns that
don't form valid, unique values. For example, in one's complement, 0x00 and
0xFF are both zero

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/26165210.kvzUkpVNyP%40tjmaciei-mobl1.

.

------=_Part_2598_1254442701.1543464419488
Content-Type: multipart/alternative;
 boundary="----=_Part_2599_1019152330.1543464419488"

------=_Part_2599_1019152330.1543464419488
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8A=E5=8D=886:21:21=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Wednesday, 28 November 2018 10:46:00 PST ria...@gmail.com <javascript:=
>=20
> wrote:=20
> > I noticed, that in several places in the standard, e.g in [basic.types]=
,=20
> > char, unsigned char, or std::byte are mentioned separately (basically a=
s=20
> > types that types that can alias anything else from my understanding).=
=20
> > There's no signed char in the list, despite it's a separate type.=20
> > What may be a reason for that?=20
>
> Because it's signed. As a signed integer, there could be bit patterns tha=
t=20
> don't form valid, unique values. For example, in one's complement, 0x00=
=20
> and=20
> 0xFF are both zero=20
>
> This is the not the whole story. The exceptional case of strict aliasing=
=20
rule is applied char or unsigned char but not signed char in C++; however,=
=20
all of them are equal in C which also allows one's complement.

The special treatment is certainly an artifact. But it seems that the signe=
d=20
char type itself is not a first-class citizen, but just a byte-width signed=
=20
integer type occasionally built-in, so the difference is intended.

And moreover... why on earth having signed char in the core language today?=
=20
Personally I'd happy to vote it deprecated since we have std::int8_least_t=
=20
and std::int8_t (albeit it is somewhat based on signed char in current=20
wording).

--=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c6950f49-e71b-431c-86cd-47bb94c55a69%40isocpp.or=
g.

------=_Part_2599_1019152330.1543464419488
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=
=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=886:21:21=EF=BC=8CThiago Maci=
eira=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On Wednesday, 28 November 2018 10:46:00 PST <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"uuy8mooFAgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">ria...@gmail.com</a> wrote:
<br>&gt; I noticed, that in several places in the standard, e.g in [basic.t=
ypes],
<br>&gt; char, unsigned char, or std::byte are mentioned separately (basica=
lly as
<br>&gt; types that types that can alias anything else from my understandin=
g).
<br>&gt; There&#39;s no signed char in the list, despite it&#39;s a separat=
e type.
<br>&gt; What may be a reason for that?
<br>
<br>Because it&#39;s signed. As a signed integer, there could be bit patter=
ns that=20
<br>don&#39;t form valid, unique values. For example, in one&#39;s compleme=
nt, 0x00 and=20
<br>0xFF are both zero
<br>
<br></blockquote><div>This is the not the whole story. The exceptional case=
 of strict aliasing rule is applied <span style=3D"font-family: courier new=
,monospace;">char</span> or <span style=3D"font-family: courier new,monospa=
ce;">unsigned char</span> but not signed char in C++; however, all of them =
are equal in C which also allows one&#39;s complement.<br><br>The special t=
reatment is certainly an artifact. But it seems that the <span style=3D"fon=
t-family: courier new,monospace;">signed char</span> type itself is not a f=
irst-class citizen, but just a byte-width signed integer type occasionally =
built-in, so the difference is intended.<br><br>And moreover... why on eart=
h having <span style=3D"font-family: courier new,monospace;">signed char</s=
pan> in the core language today? Personally I&#39;d happy to vote it deprec=
ated since we have std::int8_least_t and std::int8_t (albeit it is somewhat=
 based on signed char in current wording).<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6950f49-e71b-431c-86cd-47bb94c55a69%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6950f49-e71b-431c-86cd-47bb94c55a69=
%40isocpp.org</a>.<br />

------=_Part_2599_1019152330.1543464419488--

------=_Part_2598_1254442701.1543464419488--

.

On Wednesday, 28 November 2018 20:06:59 PST FrankHB1989 wrote:
> And moreover... why on earth having signed char in the core language today?

Sorry, but why not have a signed byte-sized integer?

In C, int8_t is not mandatory and int8_least_t could be actually be bigger
than a byte. C++ does not allow for machines with bytes less then 8 bits wide,
but I think C still does.

For that reason, removing or deprecating signed char is unlikely to ever
happen.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2329652.96Dh9RrA4F%40tjmaciei-mobl1.

.

------=_Part_2612_1274239401.1543476564166
Content-Type: multipart/alternative;
 boundary="----=_Part_2613_1336675024.1543476564166"

------=_Part_2613_1336675024.1543476564166
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=881:54:52=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Wednesday, 28 November 2018 20:06:59 PST FrankHB1989 wrote:=20
> > And moreover... why on earth having signed char in the core language=20
> today?=20
>
> Sorry, but why not have a signed byte-sized integer?=20
>
> We should have it, like int*N*_t, likely with the additional guarantee of=
=20
mandatory. It just need not be built-in in the core language, as it has no=
=20
special meaning interested by other language features. All usefulness of=20
such a type has been addressed by more effective high-level abstractions=20
like *integral type* and *object type*. Being size of one byte does not=20
make it outstanding and worth special rules.

On the contrary, the meaning of "byte" itself is far more significant.=20
(Although it is still not special as real odd ones (e.g. void) in many=20
senses.) Historically the notion "byte" is defined by the so called=20
"character types" which has raised serious confusion. A sane design should=
=20
better get rid of such dependency (and better differentiate it with *octet*=
).=20
The significance of byte comes from the need of addressing data on memory.=
=20
For this purpose, the basic unit can be the byte or the word in the type=20
system. Theoretically the latter may be even better for clarity and=20
simplicity (to ease the design like alignment), but for realistic=20
portability, we use the former. Well even this is the fact, now std::byte=
=20
is still in the library rather than the core language. (And if we had declt=
ype=20
40 years ago, we would probably define size_t in the library, as did=20
std::nullptr_t.)
=20

> In C, int8_t is not mandatory and int8_least_t could be actually be bigge=
r=20
> than a byte. C++ does not allow for machines with bytes less then 8 bits=
=20
> wide,=20
> but I think C still does.=20
>
This is the current wording living for historical reasons. Changing the=20
rules without effecting the conformance and available of existing=20
implementations is possible, even though no one bother to propose the=20
change - it is lack of motivation. But if the language *was *specialized=20
like that, it would be ... with less popular fundamental misconceptions=20
among its users, at least.

>
> For that reason, removing or deprecating signed char is unlikely to ever=
=20
> happen.=20
>
> Anyway, I agree with this conclusion.=20

> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8d7b167a-f2d0-47fa-a92b-ab79f4ff896b%40isocpp.or=
g.

------=_Part_2613_1336675024.1543476564166
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=
=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=881:54:52=EF=BC=8CThiago Maci=
eira=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On Wednesday, 28 November 2018 20:06:59 PST FrankHB1989 wrote:
<br>&gt; And moreover... why on earth having signed char in the core langua=
ge today?
<br>
<br>Sorry, but why not have a signed byte-sized integer?
<br>
<br></blockquote><div>We should have it, like <span style=3D"font-family: c=
ourier new,monospace;">int<i>N</i>_t</span>, likely with the additional gua=
rantee of mandatory. It just need not be built-in in the core language, as =
it has no special meaning interested by other language features. All useful=
ness of such a type has been addressed by more effective high-level abstrac=
tions like <i>integral type</i> and <i>object type</i>. Being size of one b=
yte does not make it outstanding and worth special rules.<br><br>On the con=
trary, the meaning of &quot;byte&quot; itself is far more significant. (Alt=
hough it is still not special as real odd ones (e.g. <span style=3D"font-fa=
mily: courier new,monospace;">void</span>) in many senses.) Historically th=
e notion &quot;byte&quot; is defined by the so called &quot;character types=
&quot; which has raised serious confusion. A sane design should better get =
rid of such dependency (and better differentiate it with <i>octet</i>). The=
 significance of byte comes from the need of addressing data on memory. For=
 this purpose, the basic unit can be the byte or the word in the type syste=
m. Theoretically the latter may be even better for clarity and simplicity (=
to ease the design like alignment), but for realistic portability, we use t=
he former. Well even this is the fact, now <span style=3D"font-family: cour=
ier new,monospace;">std::byte</span> is still in the library rather than th=
e core language. (And if we had <span style=3D"font-family: courier new,mon=
ospace;">decltype </span>40 years ago, we would probably define <span style=
=3D"font-family: courier new,monospace;">size_t</span> in the library, as d=
id <span style=3D"font-family: courier new,monospace;">std::nullptr_t</span=
>.)<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">In C, i=
nt8_t is not mandatory and int8_least_t could be actually be bigger=20
<br>than a byte. C++ does not allow for machines with bytes less then 8 bit=
s wide,=20
<br>but I think C still does.
<br></blockquote><div>This is the current wording living for historical rea=
sons. Changing the rules without effecting the conformance and available of=
 existing implementations is possible, even though no one bother to propose=
 the change - it is lack of motivation. But if the language <i>was </i>spec=
ialized like that, it would be ... with less popular fundamental misconcept=
ions among its users, at least.</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">
<br>For that reason, removing or deprecating signed char is unlikely to eve=
r=20
<br>happen.
<br>
<br></blockquote><div>Anyway, I agree with this conclusion. <br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8d7b167a-f2d0-47fa-a92b-ab79f4ff896b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d7b167a-f2d0-47fa-a92b-ab79f4ff896b=
%40isocpp.org</a>.<br />

------=_Part_2613_1336675024.1543476564166--

------=_Part_2612_1274239401.1543476564166--

.

------=_Part_2613_1644542387.1543476892869
Content-Type: multipart/alternative;
 boundary="----=_Part_2614_996652315.1543476892870"

------=_Part_2614_996652315.1543476892870
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=883:29:24=EF=BC=8CFrankHB1989=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> =E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B =
UTC+8=E4=B8=8B=E5=8D=881:54:52=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>> On Wednesday, 28 November 2018 20:06:59 PST FrankHB1989 wrote:=20
>> > And moreover... why on earth having signed char in the core language=
=20
>> today?=20
>>
>> Sorry, but why not have a signed byte-sized integer?=20
>>
>> ... we would probably define size_t in the library ...
>

Oops, some words occasionally deleted ...

It should be "we would probably define more types other than *size_t* in=20
the library".
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4e4d667e-f938-4c59-a26d-d62fe017130e%40isocpp.or=
g.

------=_Part_2614_996652315.1543476892870
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=
=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=883:29:24=EF=BC=8CFrankHB1989=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B411=E6=9C=8829=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=881:54:52=EF=BC=8CThiago Macieir=
a=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wedn=
esday, 28 November 2018 20:06:59 PST FrankHB1989 wrote:
<br>&gt; And moreover... why on earth having signed char in the core langua=
ge today?
<br>
<br>Sorry, but why not have a signed byte-sized integer?
<br>
<br></blockquote><div>... we would probably define <span style=3D"font-fami=
ly:courier new,monospace">size_t</span> in the library ...<br></div></div><=
/blockquote><div><br>Oops, some words occasionally deleted ...<br><br>It sh=
ould be &quot;we would probably define more types other than <i>size_t</i> =
in the library&quot;.<br>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e4d667e-f938-4c59-a26d-d62fe017130e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e4d667e-f938-4c59-a26d-d62fe017130e=
%40isocpp.org</a>.<br />

------=_Part_2614_996652315.1543476892870--

------=_Part_2613_1644542387.1543476892869--

.

------=_Part_3244_1042231689.1543572428559
Content-Type: multipart/alternative;
 boundary="----=_Part_3245_1934670037.1543572428560"

------=_Part_3245_1934670037.1543572428560
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20
Il giorno mercoled=C3=AC 28 novembre 2018 23:21:21 UTC+1, Thiago Macieira h=
a=20
scritto:
>
>
> Because it's signed. As a signed integer, there could be bit patterns tha=
t=20
> don't form valid, unique values. For example, in one's complement, 0x00=
=20
> and=20
> 0xFF are both zero=20
>

Not in C++20, where signed integers are required to be represented in two's=
=20
complement. See http://wg21.link/p1236

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9176b652-4e9e-4eae-a855-eb203456e46d%40isocpp.or=
g.

------=_Part_3245_1934670037.1543572428560
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">=C2=A0<iframe style=3D"padding: 0px; position: absolute; t=
op: 0px; left: 0px; width: 1204px; height: 188px; visibility: hidden;" fram=
eborder=3D"0"></iframe><br>Il giorno mercoled=C3=AC 28 novembre 2018 23:21:=
21 UTC+1, Thiago Macieira ha scritto:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><br>Because it&#39;s signed. As a signed integer, there could be bit=
 patterns that=20
<br>don&#39;t form valid, unique values. For example, in one&#39;s compleme=
nt, 0x00 and=20
<br>0xFF are both zero
<br></blockquote><div><br></div><div>Not in C++20, where signed integers ar=
e required to be represented in two&#39;s complement. See http://wg21.link/=
p1236<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9176b652-4e9e-4eae-a855-eb203456e46d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9176b652-4e9e-4eae-a855-eb203456e46d=
%40isocpp.org</a>.<br />

------=_Part_3245_1934670037.1543572428560--

------=_Part_3244_1042231689.1543572428559--

.

On Friday, 30 November 2018 02:07:08 PST Alberto Barbati wrote:
> Il giorno mercoled=C3=AC 28 novembre 2018 23:21:21 UTC+1, Thiago Macieira=
 ha
>=20
> scritto:
> > Because it's signed. As a signed integer, there could be bit patterns t=
hat
> > don't form valid, unique values. For example, in one's complement, 0x00
> > and
> > 0xFF are both zero
>=20
> Not in C++20, where signed integers are required to be represented in two=
's
> complement. See http://wg21.link/p1236

Sorry, but until C++20 is FDIS, it's not a guarantee. Is that paper accepte=
d=20
into the draft standard already? Do we know that no national body will obje=
ct=20
to this and force it out?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2574027.pfoMxFfRco%40tjmaciei-mobl1.

.

------=_Part_3354_1674525950.1543597306271
Content-Type: multipart/alternative;
 boundary="----=_Part_3355_445230120.1543597306271"

------=_Part_3355_445230120.1543597306271
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Il giorno venerd=C3=AC 30 novembre 2018 17:58:02 UTC+1, Thiago Macieira ha=
=20
scritto:
>
> On Friday, 30 November 2018 02:07:08 PST Alberto Barbati wrote:=20
> > Il giorno mercoled=C3=AC 28 novembre 2018 23:21:21 UTC+1, Thiago Maciei=
ra ha=20
> >=20
> > scritto:=20
> > > Because it's signed. As a signed integer, there could be bit patterns=
=20
> that=20
> > > don't form valid, unique values. For example, in one's complement,=20
> 0x00=20
> > > and=20
> > > 0xFF are both zero=20
> >=20
> > Not in C++20, where signed integers are required to be represented in=
=20
> two's=20
> > complement. See http://wg21.link/p1236=20
>
> Sorry, but until C++20 is FDIS, it's not a guarantee.


That is correct.
=20

> Is that paper accepted into the draft standard already?


Yes, it was accepted in San Diego.

Do we know that no national body will object to this and force it out?=20
>
>
No, we don't. I can't estimate the chance of that happening, but historical=
=20
records suggests that it's very low.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fdc8653c-4a86-43ab-8605-ffc8d82bcc36%40isocpp.or=
g.

------=_Part_3355_445230120.1543597306271
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Il giorno venerd=C3=AC 30 novembre 2018 17:58:02 UTC+1=
, Thiago Macieira ha scritto:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n Friday, 30 November 2018 02:07:08 PST Alberto Barbati wrote:
<br>&gt; Il giorno mercoled=C3=AC 28 novembre 2018 23:21:21 UTC+1, Thiago M=
acieira ha
<br>&gt;=20
<br>&gt; scritto:
<br>&gt; &gt; Because it&#39;s signed. As a signed integer, there could be =
bit patterns that
<br>&gt; &gt; don&#39;t form valid, unique values. For example, in one&#39;=
s complement, 0x00
<br>&gt; &gt; and
<br>&gt; &gt; 0xFF are both zero
<br>&gt;=20
<br>&gt; Not in C++20, where signed integers are required to be represented=
 in two&#39;s
<br>&gt; complement. See <a href=3D"http://wg21.link/p1236" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fwg21.link%2Fp1236\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNFaB4B_a0ctyg8XSPfi7g_bsW9i8g&#39;;return true;" onclick=3D"this.href=3D=
&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp1236\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaB4B_a0ctyg8XSPfi7g_bsW9i8g&#39;;return tr=
ue;">http://wg21.link/p1236</a>
<br>
<br>Sorry, but until C++20 is FDIS, it&#39;s not a guarantee.</blockquote><=
div><br></div><div>That is correct.<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">Is that paper accepted=20
into the draft standard already?</blockquote><div><br></div><div>Yes, it wa=
s accepted in San Diego.</div><div> <br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">Do we know that no national body will object=20
to this and force it out?
<br>
<br></blockquote><div><br></div><div>No, we don&#39;t. I can&#39;t estimate=
 the chance of that happening, but historical records suggests that it&#39;=
s very low.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fdc8653c-4a86-43ab-8605-ffc8d82bcc36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fdc8653c-4a86-43ab-8605-ffc8d82bcc36=
%40isocpp.org</a>.<br />

------=_Part_3355_445230120.1543597306271--

------=_Part_3354_1674525950.1543597306271--

.

On 11/30/2018 05:57 PM, Thiago Macieira wrote:
> On Friday, 30 November 2018 02:07:08 PST Alberto Barbati wrote:
>> Il giorno mercoled=C3=AC 28 novembre 2018 23:21:21 UTC+1, Thiago Macieir=
a ha
>>
>> scritto:
>>> Because it's signed. As a signed integer, there could be bit patterns t=
hat
>>> don't form valid, unique values. For example, in one's complement, 0x00
>>> and
>>> 0xFF are both zero
>>
>> Not in C++20, where signed integers are required to be represented in tw=
o's
>> complement. See http://wg21.link/p1236
>=20
> Sorry, but until C++20 is FDIS, it's not a guarantee. Is that paper accep=
ted=20
> into the draft standard already?

Yes.  The next revision of the Working Draft should be out in a couple
of days.

>  Do we know that no national body will object=20
> to this and force it out?

We don't, but I'd consider the "force it out" outcome rather unlikely.

Jens

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5C02BCC0.5040601%40gmx.net.

.

On Saturday, 1 December 2018 08:54:24 PST Jens Maurer wrote:
> > Do we know that no national body will object
> > to this and force it out?
>
> We don't, but I'd consider the "force it out" outcome rather unlikely.

Thank you. I'll defer to your and Alberto's experience on this.

I asked because changing those very old compatibility requirements tend to
bring out people who think they might need it in the future or has some old
machine that still uses it. Just think of trigraphs.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6129311.QAyJDJhFah%40tjmaciei-mobl1.

.