------=_Part_2137_895527945.1456580821297
Content-Type: multipart/alternative;
 boundary="----=_Part_2138_193996161.1456580821297"

------=_Part_2138_193996161.1456580821297
Content-Type: text/plain; charset=UTF-8

These three characters are not part of the basic source character set, even
though they are graphic ASCII characters.
Any purposes for them?

--
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/94de1ee2-0821-418e-a7b1-87b61ea438eb%40isocpp.org.

------=_Part_2138_193996161.1456580821297
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>These three characters are not part of the basic sour=
ce character set, even though they are graphic ASCII characters.</div><div>=
Any purposes for them?</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/94de1ee2-0821-418e-a7b1-87b61ea438eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/94de1ee2-0821-418e-a7b1-87b61ea438eb=
%40isocpp.org</a>.<br />

------=_Part_2138_193996161.1456580821297--
------=_Part_2137_895527945.1456580821297--

.

------=_Part_1509_714139048.1456581616831
Content-Type: multipart/alternative;
 boundary="----=_Part_1510_364597578.1456581616831"

------=_Part_1510_364597578.1456581616831
Content-Type: text/plain; charset=UTF-8



On Saturday, February 27, 2016 at 2:47:01 PM UTC+1, NDos Dannyu wrote:
>
> These three characters are not part of the basic source character set,
> even though they are graphic ASCII characters.
> Any purposes for them?
>

because ASCII isn't only character set used by C++. In recent discussion
about removing trigraphs, IBM was opposite because they still use it in
they code base. This mean they don't use ASCII.

--
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/877fa6ae-bbdc-4990-87ce-d5036b5efb56%40isocpp.org.

------=_Part_1510_364597578.1456581616831
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, February 27, 2016 at 2:47:01 PM UTC+1=
, NDos Dannyu wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>These three characters are not part of the basic source chara=
cter set, even though they are graphic ASCII characters.</div><div>Any purp=
oses for them?</div></div></blockquote><div><br>because ASCII isn&#39;t onl=
y character set used by C++. In recent discussion about removing trigraphs,=
 IBM was opposite because they still use it in they code base. This mean th=
ey don&#39;t use ASCII.<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/877fa6ae-bbdc-4990-87ce-d5036b5efb56%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/877fa6ae-bbdc-4990-87ce-d5036b5efb56=
%40isocpp.org</a>.<br />

------=_Part_1510_364597578.1456581616831--
------=_Part_1509_714139048.1456581616831--

.

On s=C3=A1bado, 27 de fevereiro de 2016 05:47:01 PST NDos Dannyu wrote:
> These three characters are not part of the basic source character set, ev=
en
> though they are graphic ASCII characters.
> Any purposes for them?

They aren't part of the basic character set, which means, for all intents a=
nd=20
purposes, that they don't exist.

--=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/5576283.d4061V2NPq%40tjmaciei-mobl4.

.

------=_Part_3205_1731564933.1456707592494
Content-Type: multipart/alternative;
 boundary="----=_Part_3206_1817067516.1456707592494"

------=_Part_3206_1817067516.1456707592494
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2016=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8B=E5=8D=8810:00:16=EF=BC=8Cinkwizyt...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>
>
>
> On Saturday, February 27, 2016 at 2:47:01 PM UTC+1, NDos Dannyu wrote:
>>
>> These three characters are not part of the basic source character set,=
=20
>> even though they are graphic ASCII characters.
>> Any purposes for them?
>>
>
> because ASCII isn't only character set used by C++. In recent discussion=
=20
> about removing trigraphs, IBM was opposite because they still use it in=
=20
> they code base. This mean they don't use ASCII.
>

Anyway, mandated trigraphs have been removed...

--=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/75f96438-37ef-4656-a088-d379e48776ab%40isocpp.or=
g.

------=_Part_3206_1817067516.1456707592494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>=E5=9C=A8 2016=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=
=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8B=E5=8D=8810:00:16=EF=BC=8Cinkwizyt...@gmai=
l.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><br><br>On Saturday, February 27, 2016 at 2:47:01 PM UTC=
+1, NDos Dannyu wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>These three characters are not part of the basic source character =
set, even though they are graphic ASCII characters.</div><div>Any purposes =
for them?</div></div></blockquote><div><br>because ASCII isn&#39;t only cha=
racter set used by C++. In recent discussion about removing trigraphs, IBM =
was opposite because they still use it in they code base. This mean they do=
n&#39;t use ASCII.<br></div></div></blockquote><div><br>Anyway, mandated tr=
igraphs have been removed...<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/75f96438-37ef-4656-a088-d379e48776ab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75f96438-37ef-4656-a088-d379e48776ab=
%40isocpp.org</a>.<br />

------=_Part_3206_1817067516.1456707592494--
------=_Part_3205_1731564933.1456707592494--

.

On 2016-02-29 01:59, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B42=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8B=E5=8D=8810:00:16=EF=BC=8Cinkwizyt...@gmail.com=E5=86=99=E9=81=
=93=EF=BC=9A
>
>
>
>     On Saturday, February 27, 2016 at 2:47:01 PM UTC+1, NDos Dannyu wrote=
:
>
>         These three characters are not part of the basic source
>         character set, even though they are graphic ASCII characters.
>         Any purposes for them?
>
>
>     because ASCII isn't only character set used by C++. In recent
>     discussion about removing trigraphs, IBM was opposite because they
>     still use it in they code base. This mean they don't use ASCII.
>
>
> Anyway, mandated trigraphs have been removed...
>

And that just moved them from a standardized feature to a language=20
extension. Because they are still used.


We don't want to restrict C++ to ASCII, byte addressed, two's=20
complement, 32-bit ints, and IEEE floating point.

Even if that combo is extremely popular.



      Bo Persson


--=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/nb1qff%24bnp%241%40ger.gmane.org.

.

On segunda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Persson wrote:
> byte addressed

Uh... isn't that required by the definition of byte?

--
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/34687914.uDKJajXjnn%40tjmaciei-mobl4.

.

------=_Part_867_1127591323.1456766880511
Content-Type: multipart/alternative;
 boundary="----=_Part_868_330646961.1456766880511"

------=_Part_868_330646961.1456766880511
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le lundi 29 f=C3=A9vrier 2016 17:46:25 UTC+1, Thiago Macieira a =C3=A9crit =
:
>
> On segunda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Persson wrote:=
=20
> > byte addressed=20
>
> Uh... isn't that required by the definition of byte?=20
>
>
>
There are (at least) three definitions for bytes:
- space taken by the representation of one character.  That's the one which=
=20
is the historical one, which allowed to pack 6 6-bit bytes into a 36-bit=20
word on computers where adresses referenced word (a popular choice at the=
=20
time), or to have byte manipulation instructions which carried how wide was=
=20
a byte. You could argue that UTF-8 is using an 8-bit byte and UTF-16 is=20
using an 16-bit bytes by that definition.
- adressable unit when it is smaller than a word (in my experience, it has=
=20
never been used for processors which are not word adressable), it's the=20
common use for processor which are not character set aware (historically=20
some were)
- 8 bits.

The shift of meaning is due to the increased popularity of byte-adressable=
=20
machines using a 8-bit byte (something which started with the IBM 360,=20
after the first definition has been made) as in most cases the three=20
definitions refer to the same thing.

C and C++ mandate that a byte has the size of a character but also that it=
=20
is the adressable unit.  That can be achieved in two ways: using wide=20
pointers when needed (that's a reason if not the reason for which=20
sizeof(void*) can be different from sizeof(int), that's what was used on=20
historical word-adressable machine; I think it is that kind of provision=20
that Bo Persson reference when saying that C++ is not restricted to byte=20
adressability), or forcing the use of a whole word per char (I think that's=
=20
the common choice for nowadays word-adressable processors; two reasons for=
=20
the changes: available memories are bigger and nowadays word-adressed=20
processor tend to be special purpose while the historical word-adressable=
=20
processor were general purpose).

Yours,

--=20
Jean-Marc

--=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/ef6699e8-3d8d-453f-91db-15cb0188b8d0%40isocpp.or=
g.

------=_Part_868_330646961.1456766880511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le lundi 29 f=C3=A9vrier 2016 17:46:25 UTC+1, Thiago Macie=
ira a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segu=
nda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Persson wrote:
<br>&gt; byte addressed
<br>
<br>Uh... isn&#39;t that required by the definition of byte?
<br>
<br><br></blockquote><div><br></div><div>There are (at least) three definit=
ions for bytes:</div><div>- space taken by the representation of one charac=
ter. =C2=A0That&#39;s the one which is the historical one, which allowed to=
 pack 6 6-bit bytes into a 36-bit word on computers where adresses referenc=
ed word (a popular choice at the time), or to have byte manipulation instru=
ctions which carried how wide was a byte. You could argue that UTF-8 is usi=
ng an 8-bit byte and UTF-16 is using an 16-bit bytes by that definition.</d=
iv><div>- adressable unit when it is smaller than a word (in my experience,=
 it has never been used for processors which are not word adressable), it&#=
39;s the common use for processor which are not character set aware (histor=
ically some were)</div><div>- 8 bits.</div><div><br></div><div>The shift of=
 meaning is due to the increased popularity of byte-adressable machines usi=
ng a 8-bit byte (something which started with the IBM 360, after the first =
definition has been made) as in most cases the three definitions refer to t=
he same thing.</div><div><br></div><div style=3D"text-align: left;">C and C=
++ mandate that a byte has the size of a character but also that it is the =
adressable unit. =C2=A0That can be achieved in two ways: using wide pointer=
s when needed (that&#39;s a reason if not the reason for which sizeof(void*=
) can be different from sizeof(int), that&#39;s what was used on historical=
 word-adressable machine; I think it is that kind of provision that Bo Pers=
son reference when saying that C++ is not restricted to byte adressability)=
, or forcing the use of a whole word per char (I think that&#39;s the commo=
n choice for nowadays word-adressable processors; two reasons for the chang=
es: available memories are bigger and nowadays word-adressed processor tend=
 to be special purpose while the historical word-adressable processor were =
general purpose).</div><div><br></div><div>Yours,</div><div><br></div><div>=
--=C2=A0</div><div>Jean-Marc</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/ef6699e8-3d8d-453f-91db-15cb0188b8d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef6699e8-3d8d-453f-91db-15cb0188b8d0=
%40isocpp.org</a>.<br />

------=_Part_868_330646961.1456766880511--
------=_Part_867_1127591323.1456766880511--

.

On segunda-feira, 29 de fevereiro de 2016 09:28:00 PST Jean-Marc Bourguet=
=20
wrote:
> Le lundi 29 f=C3=A9vrier 2016 17:46:25 UTC+1, Thiago Macieira a =C3=A9cri=
t :
> > On segunda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Persson wrote=
:
> > > byte addressed
> >=20
> > Uh... isn't that required by the definition of byte?
>=20
> There are (at least) three definitions for bytes:

We only care about the one that comes from the C and C++ standards. You can=
=20
find it in 1.7 [intro.memory]. It says:

"The fundamental storage unit in the C ++ memory model is the byte."
"The memory available to a C ++ program consists of one or more sequences o=
f=20
contiguous bytes. Every byte has a unique address."

That last sentence means *exactly* that memory must be byte-addressable. I=
=20
don't see how there can be any confusion.

--=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/85695419.D79dMvzuEz%40tjmaciei-mobl4.

.

On 2016-02-29 19:25, Thiago Macieira wrote:
> On segunda-feira, 29 de fevereiro de 2016 09:28:00 PST Jean-Marc Bourguet
> wrote:
>> Le lundi 29 f=C3=A9vrier 2016 17:46:25 UTC+1, Thiago Macieira a =C3=A9cr=
it :
>>> On segunda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Persson wrote=
:
>>>> byte addressed
>>>
>>> Uh... isn't that required by the definition of byte?
>>
>> There are (at least) three definitions for bytes:
>
> We only care about the one that comes from the C and C++ standards. You c=
an
> find it in 1.7 [intro.memory]. It says:
>
> "The fundamental storage unit in the C ++ memory model is the byte."
> "The memory available to a C ++ program consists of one or more sequences=
 of
> contiguous bytes. Every byte has a unique address."
>
> That last sentence means *exactly* that memory must be byte-addressable. =
I
> don't see how there can be any confusion.
>

Perhaps the confusion is that a pointer representation doesn't have to=20
be *only* a memory address. It can be a word address and a part-word index.

That way you can access each byte, even if there are several bytes=20
stored in one addressable unit.


Once upon a time, I used such hardware.

http://stackoverflow.com/questions/6971886/exotic-architectures-the-standar=
ds-committees-care-about/6972551#6972551


Bo Persson


--=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/nb23ek%24bib%241%40ger.gmane.org.

.

------=_Part_780_1114480931.1456771742760
Content-Type: multipart/alternative;
 boundary="----=_Part_781_775582422.1456771742760"

------=_Part_781_775582422.1456771742760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le lundi 29 f=C3=A9vrier 2016 19:25:29 UTC+1, Thiago Macieira a =C3=A9crit =
:
>
> On segunda-feira, 29 de fevereiro de 2016 09:28:00 PST Jean-Marc Bourguet=
=20
> wrote:=20
> > Le lundi 29 f=C3=A9vrier 2016 17:46:25 UTC+1, Thiago Macieira a =C3=A9c=
rit :=20
> > > On segunda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Persson=20
> wrote:=20
> > > > byte addressed=20
> > >=20
> > > Uh... isn't that required by the definition of byte?=20
> >=20
> > There are (at least) three definitions for bytes:=20
>
> We only care about the one that comes from the C and C++ standards. You=
=20
> can=20
> find it in 1.7 [intro.memory]. It says:=20
>
> "The fundamental storage unit in the C ++ memory model is the byte."=20
> "The memory available to a C ++ program consists of one or more sequences=
=20
> of=20
> contiguous bytes. Every byte has a unique address."=20
>
> That last sentence means *exactly* that memory must be byte-addressable. =
I=20
> don't see how there can be any confusion.=20
>

I wonder if you have missed the point of my last paragraph.  If you haven't=
=20
I fear that I'm missing the point of your answer.

Yours,

--=20
Jean-Marc


--=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/d39a11bd-afd2-4bf6-8a53-c783ded5c254%40isocpp.or=
g.

------=_Part_781_775582422.1456771742760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le lundi 29 f=C3=A9vrier 2016 19:25:29 UTC+1, Thiago Macie=
ira a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segu=
nda-feira, 29 de fevereiro de 2016 09:28:00 PST Jean-Marc Bourguet=20
<br>wrote:
<br>&gt; Le lundi 29 f=C3=A9vrier 2016 17:46:25 UTC+1, Thiago Macieira a =
=C3=A9crit :
<br>&gt; &gt; On segunda-feira, 29 de fevereiro de 2016 17:09:11 PST Bo Per=
sson wrote:
<br>&gt; &gt; &gt; byte addressed
<br>&gt; &gt;=20
<br>&gt; &gt; Uh... isn&#39;t that required by the definition of byte?
<br>&gt;=20
<br>&gt; There are (at least) three definitions for bytes:
<br>
<br>We only care about the one that comes from the C and C++ standards. You=
 can=20
<br>find it in 1.7 [intro.memory]. It says:
<br>
<br>&quot;The fundamental storage unit in the C ++ memory model is the byte=
..&quot;
<br>&quot;The memory available to a C ++ program consists of one or more se=
quences of=20
<br>contiguous bytes. Every byte has a unique address.&quot;
<br>
<br>That last sentence means *exactly* that memory must be byte-addressable=
.. I=20
<br>don&#39;t see how there can be any confusion.
<br></blockquote><div><br></div><div>I wonder if you have missed the point =
of my last paragraph. =C2=A0If you haven&#39;t I fear that I&#39;m missing =
the point of your answer.</div><div><br></div><div>Yours,</div><div><br></d=
iv><div>--=C2=A0</div><div>Jean-Marc</div><div><br></div><div><br></div></d=
iv>

<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/d39a11bd-afd2-4bf6-8a53-c783ded5c254%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d39a11bd-afd2-4bf6-8a53-c783ded5c254=
%40isocpp.org</a>.<br />

------=_Part_781_775582422.1456771742760--
------=_Part_780_1114480931.1456771742760--

.

On segunda-feira, 29 de fevereiro de 2016 19:42:20 PST Bo Persson wrote:
> Perhaps the confusion is that a pointer representation doesn't have to
> be *only* a memory address. It can be a word address and a part-word index.
>
> That way you can access each byte, even if there are several bytes
> stored in one addressable unit.
>
> Once upon a time, I used such hardware.

Or, put it another way, you're doing byte addressing :-)

Like you said, in such a hardware, a C++ pointer would be larger than the
pointer the HW actually needs. But with that technique, we can address each
individual byte in the word address. Conclusion: byte addressing.

We don't care how the pointers are represented or what the hardware architects
may have called "word" or "byte". We have our own definition of byte, which is
that it's the smallest storage unit that can be individually and uniquely
addressed. Since C++14, that unit needs to be at least 8 bits.

--
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/3806635.aPURXZCGiZ%40tjmaciei-mobl4.

.

On segunda-feira, 29 de fevereiro de 2016 10:49:02 PST Jean-Marc Bourguet
wrote:
> > "The fundamental storage unit in the C ++ memory model is the byte."
> > "The memory available to a C ++ program consists of one or more sequences
> > of
> > contiguous bytes. Every byte has a unique address."
> >
> > That last sentence means *exactly* that memory must be byte-addressable.
> > I don't see how there can be any confusion.
>
> I wonder if you have missed the point of my last paragraph.  If you haven't
> I fear that I'm missing the point of your answer.

I think we're just looking at it from different angles.

C and C++ require that memory be byte addressable, per the definitions I
quoted.

On architectures that can't do that, like you and Bo said, pointer addresses
in C and C++ may need to be wider than the actual hardware pointer. That meets
the requirement from the language.

But from all intents and purposes, the consequence is that all architectures
are byte-addressable.

--
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/2751678.5M8lMMefao%40tjmaciei-mobl4.

.

On 2/29/2016 10:09 AM, Bo Persson wrote:
> We don't want to restrict C++ to ASCII, byte addressed, two's
> complement, 32-bit ints, and IEEE floating point.

While we might not want all of those things, that doesn't mean that we
want *none* of those things either. Given that there are already issues
with writing C++ code in EBCDIC (hence trigraphs), adding more printable
ASCII characters to the basic source character set doesn't make things
worse.

(Ok, it makes them a small bit worse because IBM and friends would have
to agree upon some new trigraphs to use. But if the committee is willing
to remove trigraphs entirely, I doubt this would stop the addition of
new $, @, or ` to C++.)

I'd be more concerned by the fact that @ is already used by Objective
C/C++, so there'd likely be some conflicts in the grammar there,
especially if people were trying to get @ added in order to make things
that look like Python decorators.

- Jim


--
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/nb26hd%24pq%241%40ger.gmane.org.

.

------=_Part_20_719031815.1456789614095
Content-Type: multipart/alternative;
 boundary="----=_Part_21_401719026.1456789614096"

------=_Part_21_401719026.1456789614096
Content-Type: text/plain; charset=UTF-8

On Monday, February 29, 2016 at 11:35:22 AM UTC-8, Jim Porter wrote:
>
> On 2/29/2016 10:09 AM, Bo Persson wrote:
> > We don't want to restrict C++ to ASCII, byte addressed, two's
> > complement, 32-bit ints, and IEEE floating point.
>
> While we might not want all of those things, that doesn't mean that we
> want *none* of those things either. Given that there are already issues
> with writing C++ code in EBCDIC (hence trigraphs), adding more printable
> ASCII characters to the basic source character set doesn't make things
> worse.
>
> (Ok, it makes them a small bit worse because IBM and friends would have
> to agree upon some new trigraphs to use. But if the committee is willing
> to remove trigraphs entirely, I doubt this would stop the addition of
> new $, @, or ` to C++.)
>
> I'd be more concerned by the fact that @ is already used by Objective
> C/C++, so there'd likely be some conflicts in the grammar there,
> especially if people were trying to get @ added in order to make things
> that look like Python decorators.
>
>
Looking at an EBCDIC chart, @ and $ are there.  ` is also there if you use
later(?) versions of EBCDIC.  So why would IBM complain?

(Also, I don't see why trigraphs were needed for EBCDIC anyway.  The entire
basic source character set is in EBCDIC, if these charts are accurate.)

Melissa

--
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/95e5e6f7-e3fb-4804-bd7d-7dc445383935%40isocpp.org.

------=_Part_21_401719026.1456789614096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, February 29, 2016 at 11:35:22 AM UTC-8, Jim Por=
ter wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2/29/2016 10:09 A=
M, Bo Persson wrote:
<br>&gt; We don&#39;t want to restrict C++ to ASCII, byte addressed, two&#3=
9;s
<br>&gt; complement, 32-bit ints, and IEEE floating point.
<br>
<br>While we might not want all of those things, that doesn&#39;t mean that=
 we=20
<br>want *none* of those things either. Given that there are already issues=
=20
<br>with writing C++ code in EBCDIC (hence trigraphs), adding more printabl=
e=20
<br>ASCII characters to the basic source character set doesn&#39;t make thi=
ngs=20
<br>worse.
<br>
<br>(Ok, it makes them a small bit worse because IBM and friends would have=
=20
<br>to agree upon some new trigraphs to use. But if the committee is willin=
g=20
<br>to remove trigraphs entirely, I doubt this would stop the addition of=
=20
<br>new $, @, or ` to C++.)
<br>
<br>I&#39;d be more concerned by the fact that @ is already used by Objecti=
ve=20
<br>C/C++, so there&#39;d likely be some conflicts in the grammar there,=20
<br>especially if people were trying to get @ added in order to make things=
=20
<br>that look like Python decorators.
<br>
<br></blockquote><div><br>Looking at an EBCDIC chart, <span style=3D"font-f=
amily: courier new,monospace;">@</span> and <span style=3D"font-family: cou=
rier new,monospace;">$</span> are there.=C2=A0 <span style=3D"font-family: =
courier new,monospace;">`</span> is also there if you use later(?) versions=
 of EBCDIC.=C2=A0 So why would IBM complain?<br><br>(Also, I don&#39;t see =
why trigraphs were needed for EBCDIC anyway.=C2=A0 The entire basic source =
character set is in EBCDIC, if these charts are accurate.)<br><br>Melissa<b=
r></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/95e5e6f7-e3fb-4804-bd7d-7dc445383935%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95e5e6f7-e3fb-4804-bd7d-7dc445383935=
%40isocpp.org</a>.<br />

------=_Part_21_401719026.1456789614096--
------=_Part_20_719031815.1456789614095--

.

On 2/29/2016 5:46 PM, Myriachan wrote:
  Looking at an EBCDIC chart, @ and $ are there. ` is also there if you
> use later(?) versions of EBCDIC.  So why would IBM complain?
>
> (Also, I don't see why trigraphs were needed for EBCDIC anyway.  The
> entire basic source character set is in EBCDIC, if these charts are
> accurate.)

There are a bunch of incompatible versions of EBCDIC; about the only
characters they all have in common are letters and numbers, plus a very
small set of punctuation. For instance, in EBCDIC 285 (for Ireland and
the UK), $ is 0x4A, whereas it's 0x5B in EBCDIC 037 (used in the US and
Canada, among others).

- Jim

--
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/nb2n1f%24k34%241%40ger.gmane.org.

.

------=_Part_3570_91249559.1457180877169
Content-Type: multipart/alternative;
 boundary="----=_Part_3571_1973601657.1457180877169"

------=_Part_3571_1973601657.1457180877169
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



2016=EB=85=84 3=EC=9B=94 1=EC=9D=BC =ED=99=94=EC=9A=94=EC=9D=BC =EC=98=A4=
=EC=A0=84 4=EC=8B=9C 35=EB=B6=84 22=EC=B4=88 UTC+9, Jim Porter =EB=8B=98=EC=
=9D=98 =EB=A7=90:
>
>
> I'd be more concerned by the fact that @ is already used by Objective=20
> C/C++, so there'd likely be some conflicts in the grammar there,=20
> especially if people were trying to get @ added in order to make things=
=20
> that look like Python decorators.=20
>
> - Jim=20
>
Yeah, I also concern about @, which is also used in Assembly Language in=20
some systems.
But what about $ and ` ?
Should I concern about ` because it is used in Haskell, or about $ because=
=20
it is used in Microsoft Excel? I think not...

--=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/e02b65cf-f7f2-490f-afa3-52c3131c78de%40isocpp.or=
g.

------=_Part_3571_1973601657.1457180877169
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>2016=EB=85=84 3=EC=9B=94 1=EC=9D=BC =ED=99=94=EC=
=9A=94=EC=9D=BC =EC=98=A4=EC=A0=84 4=EC=8B=9C 35=EB=B6=84 22=EC=B4=88 UTC+9=
, Jim Porter =EB=8B=98=EC=9D=98 =EB=A7=90:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><br>I&#39;d be more concerned by the fact that @ is already use=
d by Objective=20
<br>C/C++, so there&#39;d likely be some conflicts in the grammar there,=20
<br>especially if people were trying to get @ added in order to make things=
=20
<br>that look like Python decorators.
<br>
<br>- Jim
<br></blockquote><div>Yeah, I also concern about @, which is also used in A=
ssembly Language in some systems.</div><div>But what about $ and ` ?</div><=
div>Should I concern about `=C2=A0because it is used in Haskell, or about $=
 because it is used in Microsoft Excel? I think not...</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/e02b65cf-f7f2-490f-afa3-52c3131c78de%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e02b65cf-f7f2-490f-afa3-52c3131c78de=
%40isocpp.org</a>.<br />

------=_Part_3571_1973601657.1457180877169--
------=_Part_3570_91249559.1457180877169--

.

--Apple-Mail=_D8F60D55-A324-40CD-A90B-17EBD7D8D150
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

One of the reasons I had heard in the past is that as these are /not/ part
of the basic character set, implementations are free to use them in their
name mangling schemes.  If we were to make them available for use in
identifiers, we risk breaking the ABI of some platforms.  You will note tha=
t
even using extended identifiers, these characters live in a region of
Unicode that is specifically excluded from use as a C++ identifier.

It may be possible to make them available for use in future extensions
to the C++ syntax and grammar, but I suspect they are forever lost to
user-space for class, variable, and function names.

AlisdairM


> On Feb 27, 2016, at 8:47 AM, NDos Dannyu <ndospark320@naver.com> wrote:
>=20
> These three characters are not part of the basic source character set, ev=
en though they are graphic ASCII characters.
> Any purposes for them?
>=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=
 email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/94de1ee2-0821-418e-a7b1-87b61ea438eb%40isocpp.=
org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94de1ee2-=
0821-418e-a7b1-87b61ea438eb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>.

--=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/7B9B7D90-2756-4474-B5B3-8A62A6B3EB61%40me.com.

--Apple-Mail=_D8F60D55-A324-40CD-A90B-17EBD7D8D150
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;" class=3D"">One of the reas=
ons I had heard in the past is that as these are /not/ part<div class=3D"">=
of the basic character set, implementations are free to use them in their</=
div><div class=3D"">name mangling schemes. &nbsp;If we were to make them av=
ailable for use in</div><div class=3D"">identifiers, we risk breaking the A=
BI of some platforms. &nbsp;You will note that</div><div class=3D"">even us=
ing extended identifiers, these characters live in a region of</div><div cl=
ass=3D"">Unicode that is specifically excluded from use as a C++ identifier=
..</div><div class=3D""><br class=3D""></div><div class=3D"">It may be possi=
ble to make them available for use in future extensions</div><div class=3D"=
">to the C++ syntax and grammar, but I suspect they are forever lost to</di=
v><div class=3D"">user-space for class, variable, and function names.</div>=
<div class=3D""><br class=3D""></div><div class=3D"">AlisdairM</div><div cl=
ass=3D""><br class=3D""></div><div class=3D""><br class=3D""><div><blockquo=
te type=3D"cite" class=3D""><div class=3D"">On Feb 27, 2016, at 8:47 AM, ND=
os Dannyu &lt;<a href=3D"mailto:ndospark320@naver.com" class=3D"">ndospark3=
20@naver.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><d=
iv class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">These three chara=
cters are not part of the basic source character set, even though they are =
graphic ASCII characters.</div><div class=3D"">Any purposes for them?</div>=
</div><div class=3D""><br class=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94de1ee2-0821-418e-a7b1-87b61ea438eb%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"">https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/94de1ee2-0821-418e-a7=
b1-87b61ea438eb%40isocpp.org</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>

<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/7B9B7D90-2756-4474-B5B3-8A62A6B3EB61%=
40me.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/7B9B7D90-2756-4474-B5B3-8A62A6B3EB61%40m=
e.com</a>.<br />

--Apple-Mail=_D8F60D55-A324-40CD-A90B-17EBD7D8D150--

.

--001a113f87602ee4d1052d4c87e8
Content-Type: text/plain; charset=UTF-8

On 5 March 2016 at 07:33, Alisdair Meredith <alisdairm@me.com> wrote:

> It may be possible to make them available for use in future extensions
> to the C++ syntax and grammar, but I suspect they are forever lost to
> user-space for class, variable, and function names.
>

And even if they were available in user-space, I suspect we could make much
better use of them for language extensions and improvements.
--
 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPEHM-EqajapR%3D%3D6v5CiqTTsNy74%2B7TbYRDifX_8oo%3Dhw%40mail.gmail.com.

--001a113f87602ee4d1052d4c87e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 5 March 2016 at 07:33, Alisd=
air Meredith <span dir=3D"ltr">&lt;<a href=3D"mailto:alisdairm@me.com" targ=
et=3D"_blank">alisdairm@me.com</a>&gt;</span> wrote:<br><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div>It may be possible to make them=
 available for use in future extensions</div><div>to the C++ syntax and gra=
mmar, but I suspect they are forever lost to</div><div>user-space for class=
, variable, and function names.</div></blockquote></div><br>And even if the=
y were available in user-space, I suspect we could make much better use of =
them for language extensions and improvements.<br>-- <br><div class=3D"gmai=
l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div=
></div></div></div></div>
</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/CAGg_6%2BPEHM-EqajapR%3D%3D6v5CiqTTsN=
y74%2B7TbYRDifX_8oo%3Dhw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%=
2BPEHM-EqajapR%3D%3D6v5CiqTTsNy74%2B7TbYRDifX_8oo%3Dhw%40mail.gmail.com</a>=
..<br />

--001a113f87602ee4d1052d4c87e8--

.

--001a1141c87e857057052d4c8ae2
Content-Type: text/plain; charset=UTF-8

On Sat, Mar 5, 2016 at 1:33 PM, Alisdair Meredith <alisdairm@me.com> wrote:

> One of the reasons I had heard in the past is that as these are /not/ part
> of the basic character set, implementations are free to use them in their
> name mangling schemes.  If we were to make them available for use in
> identifiers, we risk breaking the ABI of some platforms.  You will note
> that
> even using extended identifiers, these characters live in a region of
> Unicode that is specifically excluded from use as a C++ identifier.
>
> It may be possible to make them available for use in future extensions
> to the C++ syntax and grammar, but I suspect they are forever lost to
> user-space for class, variable, and function names.
>

I concur.  I think adding them to the basic character set is fine, but they
could not be used in identifiers.  They would serve as
operator-or-punctuation tokens that are effectively "stripped" after
parsing and the AST is formed.

I've been considering writing a proposal to add these three characters to
the basic source character set as a standalone action.  After such a
change, it would have no immediate effect, but if passed would remove FUD
from using these characters in future proposed core language proposals, and
create some much needed syntactic space in the language.



>
> AlisdairM
>
>
> On Feb 27, 2016, at 8:47 AM, NDos Dannyu <ndospark320@naver.com> wrote:
>
> These three characters are not part of the basic source character set,
> even though they are graphic ASCII characters.
> Any purposes for them?
>
> --
> 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/94de1ee2-0821-418e-a7b1-87b61ea438eb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94de1ee2-0821-418e-a7b1-87b61ea438eb%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/7B9B7D90-2756-4474-B5B3-8A62A6B3EB61%40me.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7B9B7D90-2756-4474-B5B3-8A62A6B3EB61%40me.com?utm_medium=email&utm_source=footer>
> .
>

--
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/CAB%2B4KHKw8K%2B6oFsbUnM4Wb%2BtUur6iE6Mus3xVyd2bWoyjOCP1w%40mail.gmail.com.

--001a1141c87e857057052d4c8ae2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 5, 2016 at 1:33 PM, Alisdair Meredith <span dir=3D"ltr">&lt;<a href=
=3D"mailto:alisdairm@me.com" target=3D"_blank">alisdairm@me.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-=
word">One of the reasons I had heard in the past is that as these are /not/=
 part<div>of the basic character set, implementations are free to use them =
in their</div><div>name mangling schemes.=C2=A0 If we were to make them ava=
ilable for use in</div><div>identifiers, we risk breaking the ABI of some p=
latforms.=C2=A0 You will note that</div><div>even using extended identifier=
s, these characters live in a region of</div><div>Unicode that is specifica=
lly excluded from use as a C++ identifier.</div><div><br></div><div>It may =
be possible to make them available for use in future extensions</div><div>t=
o the C++ syntax and grammar, but I suspect they are forever lost to</div><=
div>user-space for class, variable, and function names.</div></div></blockq=
uote><div><br></div><div>I concur.=C2=A0 I think adding them to the basic c=
haracter set is fine, but they could not be used in identifiers.=C2=A0 They=
 would serve as operator-or-punctuation tokens that are effectively &quot;s=
tripped&quot; after parsing and the AST is formed.</div><div><br></div><div=
>I&#39;ve been considering writing a proposal to add these three characters=
 to the basic source character set as a standalone action.=C2=A0 After such=
 a change, it would have no immediate effect, but if passed would remove FU=
D from using these characters in future proposed core language proposals, a=
nd create some much needed syntactic space in the language.</div><div><br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><div><br></div><div>AlisdairM</div><div><div class=3D"h5"><di=
v><br></div><div><br><div><blockquote type=3D"cite"><div>On Feb 27, 2016, a=
t 8:47 AM, NDos Dannyu &lt;<a href=3D"mailto:ndospark320@naver.com" target=
=3D"_blank">ndospark320@naver.com</a>&gt; wrote:</div><br><div><div dir=3D"=
ltr"><div>These three characters are not part of the basic source character=
 set, even though they are graphic ASCII characters.</div><div>Any purposes=
 for them?</div></div><div><br></div>

-- <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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/94de1ee2-0821-418e-a7b1-87b61ea438eb%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94de1ee2-0821-=
418e-a7b1-87b61ea438eb%40isocpp.org</a>.<br>
</div></blockquote></div><br></div></div></div></div><div><div class=3D"h5"=
>

<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" 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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7B9B7D90-2756-4474-B5B3-8A62A6B3EB61%=
40me.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">http=
s://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7B9B7D90-2756-4474=
-B5B3-8A62A6B3EB61%40me.com</a>.<br>
</blockquote></div><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/CAB%2B4KHKw8K%2B6oFsbUnM4Wb%2BtUur6iE=
6Mus3xVyd2bWoyjOCP1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKw=
8K%2B6oFsbUnM4Wb%2BtUur6iE6Mus3xVyd2bWoyjOCP1w%40mail.gmail.com</a>.<br />

--001a1141c87e857057052d4c8ae2--

.

On 2/27/16, NDos Dannyu <ndospark320@naver.com> wrote:
> These three characters are not part of the basic source character set,
> even though they are graphic ASCII characters.
> Any purposes for them?

Some operating systems use '$' in identifiers.  Compilers sometimes have
an option to allow '$' in identifiers.

The '@' and '`'  characters are used for extension languages.  That is
you have a language that uses them much like the preprocessor uses '#'
to find out where in the program text it should pay attention to them.

The use of these characters in C++ would have negative consequences.

--
Lawrence Crowl

--
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/CAA%2BUVZQZJMR_DNw0EPCdqH4K6V%3D%3Dn4qVFABkTwaVjE87mvYtDQ%40mail.gmail.com.

.

--001a11426748785f80052d50ae4b
Content-Type: text/plain; charset=UTF-8

On Sat, Mar 5, 2016 at 5:55 PM, Lawrence Crowl <Lawrence@crowl.org> wrote:

> On 2/27/16, NDos Dannyu <ndospark320@naver.com> wrote:
> > These three characters are not part of the basic source character set,
> > even though they are graphic ASCII characters.
> > Any purposes for them?
>
> Some operating systems use '$' in identifiers.  Compilers sometimes have
> an option to allow '$' in identifiers.
>
> The '@' and '`'  characters are used for extension languages.


I don't follow this. To which extension languages are you referring?

  That is
> you have a language that uses them much like the preprocessor uses '#'
> to find out where in the program text it should pay attention to them.
>
> The use of these characters in C++ would have negative consequences.
>
> --
> Lawrence Crowl
>
> --
> 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/CAA%2BUVZQZJMR_DNw0EPCdqH4K6V%3D%3Dn4qVFABkTwaVjE87mvYtDQ%40mail.gmail.com
> .
>

--
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/CAB%2B4KHLKACg6bScQS8XTq-gAB4GnKTvZuv-jcaEpta6pUK4UQg%40mail.gmail.com.

--001a11426748785f80052d50ae4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 5, 2016 at 5:55 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=3D=
"mailto:Lawrence@crowl.org" target=3D"_blank">Lawrence@crowl.org</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2/27/16, =
NDos Dannyu &lt;<a href=3D"mailto:ndospark320@naver.com">ndospark320@naver.=
com</a>&gt; wrote:<br>
&gt; These three characters are not part of the basic source character set,=
<br>
&gt; even though they are graphic ASCII characters.<br>
&gt; Any purposes for them?<br>
<br>
</span>Some operating systems use &#39;$&#39; in identifiers.=C2=A0 Compile=
rs sometimes have<br>
an option to allow &#39;$&#39; in identifiers.<br>
<br>
The &#39;@&#39; and &#39;`&#39;=C2=A0 characters are used for extension lan=
guages.</blockquote><div><br></div><div>I don&#39;t follow this. To which e=
xtension languages are you referring?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">=C2=A0 That is<br>
you have a language that uses them much like the preprocessor uses &#39;#&#=
39;<br>
to find out where in the program text it should pay attention to them.<br>
<br>
The use of these characters in C++ would have negative consequences.<br>
<br>
--<br>
Lawrence Crowl<br>
<span class=3D""><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAA%2BUVZQZJMR_DNw0EPCdqH4K6V%=
3D%3Dn4qVFABkTwaVjE87mvYtDQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA%2B=
UVZQZJMR_DNw0EPCdqH4K6V%3D%3Dn4qVFABkTwaVjE87mvYtDQ%40mail.gmail.com</a>.<b=
r>
</blockquote></div><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/CAB%2B4KHLKACg6bScQS8XTq-gAB4GnKTvZuv=
-jcaEpta6pUK4UQg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLKACg6=
bScQS8XTq-gAB4GnKTvZuv-jcaEpta6pUK4UQg%40mail.gmail.com</a>.<br />

--001a11426748785f80052d50ae4b--

.

On 3/5/16, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Sat, Mar 5, 2016 at 5:55 PM, Lawrence Crowl <Lawrence@crowl.org> wrote:
>> On 2/27/16, NDos Dannyu <ndospark320@naver.com> wrote:
>>> These three characters are not part of the basic source character set,
>>> even though they are graphic ASCII characters.
>>> Any purposes for them?
>>
>> Some operating systems use '$' in identifiers.  Compilers sometimes have
>> an option to allow '$' in identifiers.
>>
>> The '@' and '`'  characters are used for extension languages.
>
> I don't follow this. To which extension languages are you referring?

There is Objective C++ using '@'.  I have written private extensions
using '`'.  In one case, I ended up having to use both '@' and '`' because
of multiple processing stages.

>> That is
>> you have a language that uses them much like the preprocessor uses '#'
>> to find out where in the program text it should pay attention to them.
>>
>> The use of these characters in C++ would have negative consequences.

--
Lawrence Crowl

--
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/CAA%2BUVZTHFY1UE9HVX__mKX1nbNny%2Bxbww83%3Dg0-qpwyHZ0OZNA%40mail.gmail.com.

.