------=_Part_317_901405162.1471871874758
Content-Type: multipart/alternative;
 boundary="----=_Part_318_611901465.1471871874763"

------=_Part_318_611901465.1471871874763
Content-Type: text/plain; charset=UTF-8

Is a good ideal make the numeric types have the same size in all platforms.
Now we have the uglies int32_t, uint16_t...., then why the pretty short,
int,..., doesn't have a fixed size?
My proposal:

|   Type     | Fixed bytes | typedef for |
|=========================================
|   short    |     16      |   int16_t   |
|    int     |     32      |   int32_t   |
|  unsigned  | 32 (n >= 0) |  uint32_t   |
|    long    |     64      |   int64_t   |
|  long long |   is needled right now?   |
|----------------------------------------|
|   float    |     32      |=============|
|  double    |     64      |=============|
|long double |    128      |=============|
|========================================|

--
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/e10aed06-1df7-495b-93a2-10315cede76c%40isocpp.org.

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

<div dir=3D"ltr">Is a good ideal make the numeric types have the same size =
in all platforms. Now we have the uglies int32_t, uint16_t...., then why th=
e pretty short, int,..., doesn&#39;t have a fixed size?<div>My proposal:<br=
><div><pre style=3D"color: rgb(0, 0, 0); word-wrap: break-word; white-space=
: pre-wrap;">|   Type     | Fixed bytes | typedef for |
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|   short    |     16      |   int16_t   |=20
|    int     |     32      |   int32_t   |
|  unsigned  | 32 (n &gt;=3D 0) |  uint32_t   |
|    long    |     64      |   int64_t   |
|  long long |   is needled right now?   |
|----------------------------------------|
|   float    |     32      |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
|  double    |     64      |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
|long double |    128      |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|  =09
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|</pre></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/e10aed06-1df7-495b-93a2-10315cede76c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e10aed06-1df7-495b-93a2-10315cede76c=
%40isocpp.org</a>.<br />

------=_Part_318_611901465.1471871874763--

------=_Part_317_901405162.1471871874758--

.

--047d7bf0dbf08aa3d5053aa8eaeb
Content-Type: text/plain; charset=UTF-8

I must ask if you ever actually think or such before posting proposals,
like whether there's a fundamental reason these things haven't been done
already.

In this case it's because the basic types are meant to map efficiently to
the most appropriate types on the native platform. Just because you, me,
and many other people use x64 does not mean that everyone else with
different CPUs having different types and strengths must be bent to our
whim.

And those who need them, have the exact-width typedefs, Don't like their
"uglies" names? Then make your own typedefs that wrap around them.

The fundamental types will not be constrained to fixed widths just to fit
your aesthetic preferences, nor will the naming in the stdlib.

Please think before proposing.

--
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/CACGiwhGMecEx6gOSyOYUXP8S051QCOQ3Om2jg_Ahj_w7b%2BNL1g%40mail.gmail.com.

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

<div dir=3D"ltr"><div>I must ask if you ever actually think or such before =
posting proposals, like whether there&#39;s a fundamental reason these thin=
gs haven&#39;t been done already.<br><br>In this case it&#39;s because the =
basic types are meant to map efficiently to the most appropriate types on t=
he native platform. Just because you, me, and many other people use x64 doe=
s not mean that everyone else with different CPUs having different types an=
d strengths must be bent to our whim.<br><br></div><div>And those who need =
them, have the exact-width typedefs, Don&#39;t like their &quot;uglies&quot=
; names? Then make your own typedefs that wrap around them.<br><br></div><d=
iv>The fundamental types will not be constrained to fixed widths just to fi=
t your aesthetic preferences, nor will the naming in the stdlib.<br><br></d=
iv><div>Please think before proposing.<br><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/CACGiwhGMecEx6gOSyOYUXP8S051QCOQ3Om2j=
g_Ahj_w7b%2BNL1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGMecEx6g=
OSyOYUXP8S051QCOQ3Om2jg_Ahj_w7b%2BNL1g%40mail.gmail.com</a>.<br />

--047d7bf0dbf08aa3d5053aa8eaeb--

.

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

How in the world would we support long double as 128 bit? I don't know of
literally any platform with 128 bit floating points.
Is this meant to for the POWER9? Because SPARC dropped quad precision I
think.

To answer your question, no, it isn't a good ideal.

On Mon, Aug 22, 2016 at 9:20 AM, D. B. <db0451@gmail.com> wrote:

> I must ask if you ever actually think or such before posting proposals,
> like whether there's a fundamental reason these things haven't been done
> already.
>
> In this case it's because the basic types are meant to map efficiently to
> the most appropriate types on the native platform. Just because you, me,
> and many other people use x64 does not mean that everyone else with
> different CPUs having different types and strengths must be bent to our
> whim.
>
> And those who need them, have the exact-width typedefs, Don't like their
> "uglies" names? Then make your own typedefs that wrap around them.
>
> The fundamental types will not be constrained to fixed widths just to fit
> your aesthetic preferences, nor will the naming in the stdlib.
>
> Please think before proposing.
>
> --
> 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/CACGiwhGMecEx6gOSyOYUXP8S051QC
> OQ3Om2jg_Ahj_w7b%2BNL1g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGMecEx6gOSyOYUXP8S051QCOQ3Om2jg_Ahj_w7b%2BNL1g%40mail.gmail.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/CAMD6iD-rQcPeVaUgZQxKGDycisEWPP-Sn3%2BCt6Y_%3DnOPQOUKYA%40mail.gmail.com.

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

<div dir=3D"ltr">How in the world would we support long double as 128 bit? =
I don&#39;t know of literally any platform with 128 bit floating points.<di=
v>Is this meant to for the POWER9? Because SPARC dropped quad precision I t=
hink.</div><div><br></div><div>To answer your question, no, it isn&#39;t a =
good ideal.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Mon, Aug 22, 2016 at 9:20 AM, D. B. <span dir=3D"ltr">&lt;<a href=
=3D"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.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 dir=3D"ltr"><div>I must a=
sk if you ever actually think or such before posting proposals, like whethe=
r there&#39;s a fundamental reason these things haven&#39;t been done alrea=
dy.<br><br>In this case it&#39;s because the basic types are meant to map e=
fficiently to the most appropriate types on the native platform. Just becau=
se you, me, and many other people use x64 does not mean that everyone else =
with different CPUs having different types and strengths must be bent to ou=
r whim.<br><br></div><div>And those who need them, have the exact-width typ=
edefs, Don&#39;t like their &quot;uglies&quot; names? Then make your own ty=
pedefs that wrap around them.<br><br></div><div>The fundamental types will =
not be constrained to fixed widths just to fit your aesthetic preferences, =
nor will the naming in the stdlib.<br><br></div><div>Please think before pr=
oposing.<br><br></div></div><span class=3D"">

<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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGMecEx6gOSyOYUXP8S051QCOQ3Om2j=
g_Ahj_w7b%2BNL1g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CACGiwhGMecEx6gOSyOYUXP8S051QC<wbr>OQ3Om2jg_Ahj_w7b%2=
BNL1g%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></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/CAMD6iD-rQcPeVaUgZQxKGDycisEWPP-Sn3%2=
BCt6Y_%3DnOPQOUKYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD-rQcPe=
VaUgZQxKGDycisEWPP-Sn3%2BCt6Y_%3DnOPQOUKYA%40mail.gmail.com</a>.<br />

--001a114285ca23311f053aa91e8a--

.

On 22 August 2016 at 16:35, Ren Industries <renindustries@gmail.com> wrote:
> How in the world would we support long double as 128 bit? I don't know of
> literally any platform with 128 bit floating points.
> Is this meant to for the POWER9? Because SPARC dropped quad precision I
> think.
>
> To answer your question, no, it isn't a good ideal.


Let's see the author of the original post implement the idea and run
the changed semantics on existing codebases.
The results are most likely going to be interesting.

--
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/CAFk2RUbcUKuKNpj67GUGgoCjodWrmN4J8FAPGMWcXK%2Bfy-sYrA%40mail.gmail.com.

.

On 2016-08-22 15:17, HarD Gamer wrote:
> Is a good ideal make the numeric types have the same size in all
> platforms. Now we have the uglies int32_t, uint16_t...., then why the
> pretty short, int,..., doesn't have a fixed size?
> My proposal:
>
> |   Type     | Fixed bytes | typedef for |
> |=========================================
> |   short    |     16      |   int16_t   |
> |    int     |     32      |   int32_t   |
> |  unsigned  | 32 (n >= 0) |  uint32_t   |
> |    long    |     64      |   int64_t   |
> |  long long |   is needled right now?   |
> |----------------------------------------|
> |   float    |     32      |=============|
> |  double    |     64      |=============|
> |long double |    128      |=============|
> |========================================|
>

If you only want to write code for systems where the sizes are
"correct", you can verify this by adding some checks. For example:

static_assert(std::is_same_v<int, std::int32_t>,
               "Oops strange computer!");

and then just use int instead of the ugly name.


Just one problem with trying to fix the sizes is that the Windows API
uses 32-bit long in both 32-bit and 64-bit mode. Not much the C++
standard can change now.


You might also want to consider this:

http://stackoverflow.com/questions/6971886/exotic-architectures-the-standards-committees-care-about



     Bo Persson


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/npf2e3%24ekf%241%40blaine.gmane.org.

.

On segunda-feira, 22 de agosto de 2016 06:17:54 PDT HarD Gamer wrote:
> Is a good ideal make the numeric types have the same size in all platforms.

No. There's a good reason why they have different sizes.

And changing the sizes is a huge ABI break.

--
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/3216223.zSQSpiSOYt%40tjmaciei-mobl1.

.

--047d7b86e4f84d1200053aaadc45
Content-Type: text/plain; charset=UTF-8

It's quite perplexing how some people underestimate the breadth of uses and
platforms on which the language runs - or simply ignore that they are not
its only users - to such a degree that they think it can just abandon
fundamental concepts to suit their aesthetic whims. Or do they just think
all other users' cases and platforms are silly and the language should be
dumbed down to more intuitively reflect the en vogue platform of the day?
When the issues amount to trivialities that - if one is bothered enough -
can be solved using typedefs and other mechanisms, it's all the more
bizarre that some people think their preferences are (A) important and (B)
so important as to justify breaking the language for everyone else.

But that's just how I see it.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHJEfGH_4Tv171aFmEjB0%3DpDJxE3OB6umJaYH8qjsMiCA%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div>It&#39;s quite perplexing how some people undere=
stimate the breadth of uses and platforms on which the language runs -  or =
simply ignore that they are not its only users - to such a degree that they=
 think it can just abandon fundamental concepts to suit their aesthetic whi=
ms. Or do they just think all other users&#39; cases and platforms are sill=
y and the language should be dumbed down to more intuitively reflect the en=
 vogue platform of the day? When the issues amount to trivialities that - i=
f one is bothered enough - can be solved using typedefs and other mechanism=
s, it&#39;s all the more bizarre that some people think their preferences a=
re (A) important and (B) so important as to justify breaking the language f=
or everyone else.<br></div><br></div>But that&#39;s just how I see it.<br><=
br></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/CACGiwhHJEfGH_4Tv171aFmEjB0%3DpDJxE3O=
B6umJaYH8qjsMiCA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHJEfGH_4=
Tv171aFmEjB0%3DpDJxE3OB6umJaYH8qjsMiCA%40mail.gmail.com</a>.<br />

--047d7b86e4f84d1200053aaadc45--

.

------=_Part_819_1863815329.1471903609188
Content-Type: multipart/alternative;
 boundary="----=_Part_820_727632109.1471903609188"

------=_Part_820_727632109.1471903609188
Content-Type: text/plain; charset=UTF-8

My proposal is to fix the size (the table is only a example).
It's only because the standard library never use the uglies  types in
functions, classes and etc.
My proposal is to cross-platform programmer that need, for example

uniform_int_distribution<int> dist(10, numeric_limits<int>::max()); //
assume int 32-bit

use_new_number(dist(eng)));

returning a 32-bit integer. What if in another platform int is 16-bit? What
if is needled use a std function that requires a int? The value will be
truncated in that 32-bit platform.


--
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/0d61be1e-2020-4f09-baa6-64dca463cb68%40isocpp.org.

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

<div dir=3D"ltr">My proposal is to fix the size (the table is only a exampl=
e).<div>It&#39;s only because the standard library never use the uglies =C2=
=A0types in functions, classes and etc.</div><div>My proposal is to cross-p=
latform programmer that need, for example</div><div><br></div><div>uniform_=
int_distribution&lt;int&gt; dist(10, numeric_limits&lt;int&gt;::max()); // =
assume int 32-bit</div><div><br></div><div>use_new_number(dist(eng)));</div=
><div>=C2=A0</div><div>returning a 32-bit integer. What if in another platf=
orm int is 16-bit? What if is needled use a std function that requires a in=
t? The value will be truncated in that 32-bit platform.</div><div><br></div=
><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/0d61be1e-2020-4f09-baa6-64dca463cb68%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0d61be1e-2020-4f09-baa6-64dca463cb68=
%40isocpp.org</a>.<br />

------=_Part_820_727632109.1471903609188--

------=_Part_819_1863815329.1471903609188--

.

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

Yes, *what if another platform is 16 bit? *How in the world are we to
change that platform so it supports 32 bit ints?
All the currently working code would break, and for a lot of legacy systems
the actual code might be gone.

Even if everyone had the source code to every program, many programs may
*depend* on int being 16 bits.
The code might not make sense using 32 bit integers. For example, some
DSP's are still 16 bit; emulating 32 bits on 16 bit processors will more
than half the speed of the code. And much code on these sorts of units is
time critical; they might not have that many cycles to spare.

Finally, the fundamental meaning of "int" would change; int would no longer
be the natural size for the platform. So why the hell are we calling it int
anymore? It's a 32 bit integer, not a platform neutral integer. Either we
need to name it more strictly (such as int32_t or something) or we need to
give a new name to "platform neutral" integer or "most natural" integer or
"fastest" integer. Maybe intnatural? natural? fixed?

Do any of those really strike you as a good idea? No?
That's why this is a non-starter.

On Mon, Aug 22, 2016 at 6:06 PM, HarD Gamer <rodrigojose690@gmail.com>
wrote:

> My proposal is to fix the size (the table is only a example).
> It's only because the standard library never use the uglies  types in
> functions, classes and etc.
> My proposal is to cross-platform programmer that need, for example
>
> uniform_int_distribution<int> dist(10, numeric_limits<int>::max()); //
> assume int 32-bit
>
> use_new_number(dist(eng)));
>
> returning a 32-bit integer. What if in another platform int is 16-bit?
> What if is needled use a std function that requires a int? The value will
> be truncated in that 32-bit platform.
>
>
> --
> 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/0d61be1e-2020-4f09-
> baa6-64dca463cb68%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0d61be1e-2020-4f09-baa6-64dca463cb68%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/CAMD6iD9TuK5jV9BFHoAa%2BmNCR608bEP%2BrmbV67Mw3PbO1EvDsA%40mail.gmail.com.

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

<div dir=3D"ltr">Yes, <i>what if another platform is 16 bit? </i>How in the=
 world are we to change that platform so it supports 32 bit ints?<div>All t=
he currently working code would break, and for a lot of legacy systems the =
actual code might be gone.</div><div><br></div><div>Even if everyone had th=
e source code to every program, many programs may <i>depend</i>=C2=A0on int=
 being 16 bits.</div><div>The code might not make sense using 32 bit intege=
rs. For example, some DSP&#39;s are still 16 bit; emulating 32 bits on 16 b=
it processors will more than half the speed of the code. And much code on t=
hese sorts of units is time critical; they might not have that many cycles =
to spare.</div><div><br></div><div>Finally, the fundamental meaning of &quo=
t;int&quot; would change; int would no longer be the natural size for the p=
latform. So why the hell are we calling it int anymore? It&#39;s a 32 bit i=
nteger, not a platform neutral integer. Either we need to name it more stri=
ctly (such as int32_t or something) or we need to give a new name to &quot;=
platform neutral&quot; integer or &quot;most natural&quot; integer or &quot=
;fastest&quot; integer. Maybe intnatural? natural? fixed?</div><div><br></d=
iv><div>Do any of those really strike you as a good idea? No?</div><div>Tha=
t&#39;s why this is a non-starter.</div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Mon, Aug 22, 2016 at 6:06 PM, HarD Gamer <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:rodrigojose690@gmail.com" target=3D"_=
blank">rodrigojose690@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">My proposal is to fix the size (the table is=
 only a example).<div>It&#39;s only because the standard library never use =
the uglies =C2=A0types in functions, classes and etc.</div><div>My proposal=
 is to cross-platform programmer that need, for example</div><div><br></div=
><div>uniform_int_distribution&lt;int&gt; dist(10, numeric_limits&lt;int&gt=
;::max()); // assume int 32-bit</div><div><br></div><div>use_new_number(dis=
t(eng)));</div><div>=C2=A0</div><div>returning a 32-bit integer. What if in=
 another platform int is 16-bit? What if is needled use a std function that=
 requires a int? The value will be truncated in that 32-bit platform.</div>=
<div><br></div><div><br></div></div><span class=3D"">

<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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0d61be1e-2020-4f09-baa6-64dca463cb68%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/0d61=
be1e-2020-4f09-<wbr>baa6-64dca463cb68%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CAMD6iD9TuK5jV9BFHoAa%2BmNCR608bEP%2B=
rmbV67Mw3PbO1EvDsA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9TuK5j=
V9BFHoAa%2BmNCR608bEP%2BrmbV67Mw3PbO1EvDsA%40mail.gmail.com</a>.<br />

--001a11c028c4b540a7053ab4504f--

.

------=_Part_823_1322058276.1471923147949
Content-Type: multipart/alternative;
 boundary="----=_Part_824_498033313.1471923147950"

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



=E5=9C=A8 2016=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=889:20:49=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A
>
> I must ask if you ever actually think or such before posting proposals,=
=20
> like whether there's a fundamental reason these things haven't been done=
=20
> already.
>
> In this case it's because the basic types are meant to map efficiently to=
=20
> the most appropriate types on the native platform.
>
This is not quite true now.

The problem is how to keep "most appropriate". There is no guarantee,=20
literally and normatively. This leaves them useless for application=20
programmers in general. The worse things is they misleads programmers with=
=20
wrong assumptions.

In fact there might be multiple interpretations about "native", and the=20
programs need nothing of such assumptions. For example Win32 vs. Cygwin,=20
both can be not "native" enough comparing to underlying NT. Whether same=20
widths of integers used or not on such implementations has nothing to do=20
with conformance. (Even different implementations on such platforms will=20
probably choose types closer to those specified by the ISA spec, this is a=
=20
detailed strategy of implementation rather than a general guarantee.) The=
=20
sense of "appropriate" totally up to the particular implementation being=20
used.

If an appropriate ABI is needed, it should always define exact integer=20
types elsewhere, rather then depending on the language specifications.

Thus, except the type 'int' (which is needed by `main` and operator=20
overloading), keeping them is merely for compatibility.

=20

> Just because you, me, and many other people use x64 does not mean that=20
> everyone else with different CPUs having different types and strengths mu=
st=20
> be bent to our whim.
>
> And those who need them, have the exact-width typedefs, Don't like their=
=20
> "uglies" names? Then make your own typedefs that wrap around them.
>
> The fundamental types will not be constrained to fixed widths just to fit=
=20
> your aesthetic preferences, nor will the naming in the stdlib.
>
> Please think before proposing.
>
>

--=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/61bffb8a-6e83-40dd-81ab-9e7616b2ebce%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=889:20:49=EF=BC=8CD. B.=E5=86=99=
=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>I must ask if you ever actually think or such before posting prop=
osals, like whether there&#39;s a fundamental reason these things haven&#39=
;t been done already.<br><br>In this case it&#39;s because the basic types =
are meant to map efficiently to the most appropriate types on the native pl=
atform.</div></div></blockquote><div>This is not quite true now.<br><br>The=
 problem is how to keep &quot;most appropriate&quot;. There is no guarantee=
, literally and normatively. This leaves them useless for application progr=
ammers in general. The worse things is they misleads programmers with wrong=
 assumptions.<br><br>In fact there might be multiple interpretations about =
&quot;native&quot;, and the programs need nothing of such assumptions. For =
example Win32 vs. Cygwin, both can be not &quot;native&quot; enough compari=
ng to underlying NT. Whether same widths of integers used or not on such im=
plementations has nothing to do with conformance. (Even different implement=
ations on such platforms will probably choose types closer to those specifi=
ed by the ISA spec, this is a detailed strategy  of implementation rather t=
han a general guarantee.) The sense of &quot;appropriate&quot; totally up t=
o the particular implementation being used.<br><br>If an appropriate ABI is=
 needed, it should always define exact integer types elsewhere, rather then=
 depending on the language specifications.<br><br>Thus, except the type &#3=
9;int&#39; (which is needed by `main` and operator overloading), keeping th=
em is merely for compatibility.<br><br>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div>Just because you, me, and many o=
ther people use x64 does not mean that everyone else with different CPUs ha=
ving different types and strengths must be bent to our whim.<br><br></div><=
div>And those who need them, have the exact-width typedefs, Don&#39;t like =
their &quot;uglies&quot; names? Then make your own typedefs that wrap aroun=
d them.<br><br></div><div>The fundamental types will not be constrained to =
fixed widths just to fit your aesthetic preferences, nor will the naming in=
 the stdlib.<br><br></div><div>Please think before proposing.<br><br></div>=
</div>
</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/61bffb8a-6e83-40dd-81ab-9e7616b2ebce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61bffb8a-6e83-40dd-81ab-9e7616b2ebce=
%40isocpp.org</a>.<br />

------=_Part_824_498033313.1471923147950--

------=_Part_823_1322058276.1471923147949--

.

------=_Part_635_1597735196.1471923634255
Content-Type: multipart/alternative;
 boundary="----=_Part_636_1885188310.1471923634255"

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



=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=8810:56:48=EF=BC=8CRen Industries=E5=86=99=E9=81=93=EF=BC=
=9A
>
> Yes, *what if another platform is 16 bit? *How in the world are we to=20
> change that platform so it supports 32 bit ints?
> All the currently working code would break, and for a lot of legacy=20
> systems the actual code might be gone.
>
> Even if everyone had the source code to every program, many programs may=
=20
> *depend* on int being 16 bits.
> The code might not make sense using 32 bit integers. For example, some=20
> DSP's are still 16 bit; emulating 32 bits on 16 bit processors will more=
=20
> than half the speed of the code. And much code on these sorts of units is=
=20
> time critical; they might not have that many cycles to spare.
> =20
>
Finally, the fundamental meaning of "int" would change; int would no longer=
=20
> be the natural size for the platform. So why the hell are we calling it i=
nt=20
> anymore? It's a 32 bit integer, not a platform neutral integer. Either we=
=20
> need to name it more strictly (such as int32_t or something) or we need t=
o=20
> give a new name to "platform neutral" integer or "most natural" integer o=
r=20
> "fastest" integer. Maybe intnatural? natural? fixed?
>
> There is no guarantee about "natural size".=20

There have been the names for "fastest" ones: intN_fast_t/uintN_fast_t.=20

It is reasonable that things like intN_t cannot be mandated for every=20
platforms by practical reasons. But why not int_leastN_t/int_fastN_t? The=
=20
fact of keeping too many integer types without guarantees in the language=
=20
specification is the true ugliness. Their co-existence also frustrates the=
=20
normative type system (e.g. unsigned long vs. unsigned when they are the=20
same thing in the ABI). I prefer most of them will be eventually=20
conditionally-supported.

BTW, I also don't think we have good reasons to provide more wrapper types=
=20
by the language specification. They can be unusable placeholders too=20
easily, causing compatibility and maintenance nightmare. Why should=20
programmers suffer from a `wchar_t` with 8-bit (yeah, damned Bionic)?

=20

> Do any of those really strike you as a good idea? No?
> That's why this is a non-starter.
>
> On Mon, Aug 22, 2016 at 6:06 PM, HarD Gamer <rodrigo...@gmail.com=20
> <javascript:>> wrote:
>
>> My proposal is to fix the size (the table is only a example).
>> It's only because the standard library never use the uglies  types in=20
>> functions, classes and etc.
>> My proposal is to cross-platform programmer that need, for example
>>
>> uniform_int_distribution<int> dist(10, numeric_limits<int>::max()); //=
=20
>> assume int 32-bit
>>
>> use_new_number(dist(eng)));
>> =20
>> returning a 32-bit integer. What if in another platform int is 16-bit?=
=20
>> What if is needled use a std function that requires a int? The value wil=
l=20
>> be truncated in that 32-bit platform.
>>
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0d61be1e-20=
20-4f09-baa6-64dca463cb68%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0d61be1e-2=
020-4f09-baa6-64dca463cb68%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>

--=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/bfee02a3-301e-4a9e-92ef-51ab8647e94d%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=8810:56:48=EF=BC=8CRen Industrie=
s=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;"><d=
iv dir=3D"ltr">Yes, <i>what if another platform is 16 bit? </i>How in the w=
orld are we to change that platform so it supports 32 bit ints?<div>All the=
 currently working code would break, and for a lot of legacy systems the ac=
tual code might be gone.</div><div><br></div><div>Even if everyone had the =
source code to every program, many programs may <i>depend</i>=C2=A0on int b=
eing 16 bits.</div><div>The code might not make sense using 32 bit integers=
.. For example, some DSP&#39;s are still 16 bit; emulating 32 bits on 16 bit=
 processors will more than half the speed of the code. And much code on the=
se sorts of units is time critical; they might not have that many cycles to=
 spare.</div><div>=C2=A0</div></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Finally, the fundamenta=
l meaning of &quot;int&quot; would change; int would no longer be the natur=
al size for the platform. So why the hell are we calling it int anymore? It=
&#39;s a 32 bit integer, not a platform neutral integer. Either we need to =
name it more strictly (such as int32_t or something) or we need to give a n=
ew name to &quot;platform neutral&quot; integer or &quot;most natural&quot;=
 integer or &quot;fastest&quot; integer. Maybe intnatural? natural? fixed?<=
/div><div><br></div></div></blockquote><div>There is no guarantee about &qu=
ot;natural size&quot;. <br></div><div><br>There have been the names for &qu=
ot;fastest&quot; ones: intN_fast_t/uintN_fast_t. <br></div><div><br>It is r=
easonable that things like intN_t cannot be mandated for every platforms by=
 practical reasons. But why not int_leastN_t/int_fastN_t? The fact of keepi=
ng too many integer types without guarantees in the language specification =
is the true ugliness. Their co-existence also frustrates the normative type=
 system (e.g. unsigned long vs. unsigned when they are the same thing in th=
e ABI). I prefer most of them will be eventually conditionally-supported.<b=
r><br>BTW, I also don&#39;t think we have good reasons to provide more wrap=
per types by the language specification. They can be unusable placeholders =
too easily, causing compatibility and maintenance nightmare. Why should pro=
grammers suffer from a `wchar_t` with 8-bit (yeah, damned Bionic)?<br><br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>Do any of those really strike you as a good idea? No?</div><=
div>That&#39;s why this is a non-starter.</div></div><div><br><div class=3D=
"gmail_quote">On Mon, Aug 22, 2016 at 6:06 PM, HarD Gamer <span dir=3D"ltr"=
>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"o4M=
OasFHDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39=
;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">=
rodrigo...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">My proposal is to fix the size (the table is only a exam=
ple).<div>It&#39;s only because the standard library never use the uglies =
=C2=A0types in functions, classes and etc.</div><div>My proposal is to cros=
s-platform programmer that need, for example</div><div><br></div><div>unifo=
rm_int_distribution&lt;int&gt; dist(10, numeric_limits&lt;int&gt;::max()); =
// assume int 32-bit</div><div><br></div><div>use_new_number(dist(eng)));</=
div><div>=C2=A0</div><div>returning a 32-bit integer. What if in another pl=
atform int is 16-bit? What if is needled use a std function that requires a=
 int? The value will be truncated in that 32-bit platform.</div><div><br></=
div><div><br></div></div><span>

<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
o4MOasFHDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"o4MOasFHDQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0d61be1e-2020-4f09-baa6-64dca463cb68%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/0d61be1e-2020-4f09-baa6-64dca463cb68%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/0d61be1e-2020-4f09-baa6-64dca463cb68%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/0d61be1e-2020-4f09-<wbr>baa6-=
64dca463cb68%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</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/bfee02a3-301e-4a9e-92ef-51ab8647e94d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bfee02a3-301e-4a9e-92ef-51ab8647e94d=
%40isocpp.org</a>.<br />

------=_Part_636_1885188310.1471923634255--

------=_Part_635_1597735196.1471923634255--

.

------=_Part_4814_1123196411.1471925914645
Content-Type: multipart/alternative;
 boundary="----=_Part_4815_1407464808.1471925914645"

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

On Monday, August 22, 2016 at 11:40:34 PM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8A=E5=8D=8810:56:48=EF=BC=8CRen Industries=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>> Yes, *what if another platform is 16 bit? *How in the world are we to=20
>> change that platform so it supports 32 bit ints?
>> All the currently working code would break, and for a lot of legacy=20
>> systems the actual code might be gone.
>>
>> Even if everyone had the source code to every program, many programs may=
=20
>> *depend* on int being 16 bits.
>> The code might not make sense using 32 bit integers. For example, some=
=20
>> DSP's are still 16 bit; emulating 32 bits on 16 bit processors will more=
=20
>> than half the speed of the code. And much code on these sorts of units i=
s=20
>> time critical; they might not have that many cycles to spare.
>> =20
>>
> Finally, the fundamental meaning of "int" would change; int would no=20
>> longer be the natural size for the platform. So why the hell are we call=
ing=20
>> it int anymore? It's a 32 bit integer, not a platform neutral integer.=
=20
>> Either we need to name it more strictly (such as int32_t or something) o=
r=20
>> we need to give a new name to "platform neutral" integer or "most natura=
l"=20
>> integer or "fastest" integer. Maybe intnatural? natural? fixed?
>>
>> There is no guarantee about "natural size".
>

Yes, there is no guarantee about what that means. But compiler writers=20
would encounter problems if they start arbitrarily violating the=20
expectations of users of that platform. As such, `int` will generally be=20
the "natural size" for the processor in question.

There have been the names for "fastest" ones: intN_fast_t/uintN_fast_t.=20
>
> It is reasonable that things like intN_t cannot be mandated for every=20
> platforms by practical reasons. But why not int_leastN_t/int_fastN_t?
>

They *are mandated* for all platforms. The only optional ones are those=20
that use a specific bitdepth and the `intptr_t`s.

Every valid C++11 implementation must provide those types. Even=20
freestanding implementations, which are permitted to only provide a subset=
=20
of the full standard library, are *required*, to provide these types.
=20

> The fact of keeping too many integer types without guarantees in the=20
> language specification is the true ugliness. Their co-existence also=20
> frustrates the normative type system (e.g. unsigned long vs. unsigned whe=
n=20
> they are the same thing in the ABI). I prefer most of them will be=20
> eventually conditionally-supported.
>
> BTW, I also don't think we have good reasons to provide more wrapper type=
s=20
> by the language specification. They can be unusable placeholders too=20
> easily, causing compatibility and maintenance nightmare. Why should=20
> programmers suffer from a `wchar_t` with 8-bit (yeah, damned Bionic)?
>
>

--=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/72b7e733-cb85-4f47-a09b-10611f04211b%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, August 22, 2016 at 11:40:34 PM UTC-4, FrankHB19=
89 wrote:<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">=E5=
=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=
=E4=B8=8A=E5=8D=8810:56:48=EF=BC=8CRen Industries=E5=86=99=E9=81=93=EF=BC=
=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yes, <i>what if=
 another platform is 16 bit? </i>How in the world are we to change that pla=
tform so it supports 32 bit ints?<div>All the currently working code would =
break, and for a lot of legacy systems the actual code might be gone.</div>=
<div><br></div><div>Even if everyone had the source code to every program, =
many programs may <i>depend</i>=C2=A0on int being 16 bits.</div><div>The co=
de might not make sense using 32 bit integers. For example, some DSP&#39;s =
are still 16 bit; emulating 32 bits on 16 bit processors will more than hal=
f the speed of the code. And much code on these sorts of units is time crit=
ical; they might not have that many cycles to spare.</div><div>=C2=A0</div>=
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div></div><div>Finally, the fundamental meaning of &quot;int&quot; would =
change; int would no longer be the natural size for the platform. So why th=
e hell are we calling it int anymore? It&#39;s a 32 bit integer, not a plat=
form neutral integer. Either we need to name it more strictly (such as int3=
2_t or something) or we need to give a new name to &quot;platform neutral&q=
uot; integer or &quot;most natural&quot; integer or &quot;fastest&quot; int=
eger. Maybe intnatural? natural? fixed?</div><div><br></div></div></blockqu=
ote><div>There is no guarantee about &quot;natural size&quot;.<br></div></d=
iv></blockquote><div><br>Yes, there is no guarantee about what that means. =
But compiler writers would encounter problems if they start arbitrarily vio=
lating the expectations of users of that platform. As such, `int` will gene=
rally be the &quot;natural size&quot; for the processor in question.<br><br=
></div><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"><div><=
/div><div>There have been the names for &quot;fastest&quot; ones: intN_fast=
_t/uintN_fast_t. <br></div><div><br>It is reasonable that things like intN_=
t cannot be mandated for every platforms by practical reasons. But why not =
int_leastN_t/int_fastN_t?</div></div></blockquote><div><br>They <i>are mand=
ated</i> for all platforms. The only optional ones are those that use a spe=
cific bitdepth and the `intptr_t`s.<br><br>Every valid C++11 implementation=
 must provide those types. Even freestanding implementations, which are per=
mitted to only provide a subset of the full standard library, are <i>requir=
ed</i>, to provide these types.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>The fact of keeping too many integer=
 types without guarantees in the language specification is the true uglines=
s. Their co-existence also frustrates the normative type system (e.g. unsig=
ned long vs. unsigned when they are the same thing in the ABI). I prefer mo=
st of them will be eventually conditionally-supported.<br><br>BTW, I also d=
on&#39;t think we have good reasons to provide more wrapper types by the la=
nguage specification. They can be unusable placeholders too easily, causing=
 compatibility and maintenance nightmare. Why should programmers suffer fro=
m a `wchar_t` with 8-bit (yeah, damned Bionic)?</div><br></div></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/72b7e733-cb85-4f47-a09b-10611f04211b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72b7e733-cb85-4f47-a09b-10611f04211b=
%40isocpp.org</a>.<br />

------=_Part_4815_1407464808.1471925914645--

------=_Part_4814_1123196411.1471925914645--

.

------=_Part_72_1154282005.1471926973060
Content-Type: multipart/alternative;
 boundary="----=_Part_73_1650552891.1471926973061"

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



=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8812:18:35=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Monday, August 22, 2016 at 11:40:34 PM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8A=E5=8D=8810:56:48=EF=BC=8CRen Industries=E5=86=99=E9=81=93=EF=
=BC=9A
>>>
>>> Yes, *what if another platform is 16 bit? *How in the world are we to=
=20
>>> change that platform so it supports 32 bit ints?
>>> All the currently working code would break, and for a lot of legacy=20
>>> systems the actual code might be gone.
>>>
>>> Even if everyone had the source code to every program, many programs ma=
y=20
>>> *depend* on int being 16 bits.
>>> The code might not make sense using 32 bit integers. For example, some=
=20
>>> DSP's are still 16 bit; emulating 32 bits on 16 bit processors will mor=
e=20
>>> than half the speed of the code. And much code on these sorts of units =
is=20
>>> time critical; they might not have that many cycles to spare.
>>> =20
>>>
>> Finally, the fundamental meaning of "int" would change; int would no=20
>>> longer be the natural size for the platform. So why the hell are we cal=
ling=20
>>> it int anymore? It's a 32 bit integer, not a platform neutral integer.=
=20
>>> Either we need to name it more strictly (such as int32_t or something) =
or=20
>>> we need to give a new name to "platform neutral" integer or "most natur=
al"=20
>>> integer or "fastest" integer. Maybe intnatural? natural? fixed?
>>>
>>> There is no guarantee about "natural size".
>>
>
> Yes, there is no guarantee about what that means. But compiler writers=20
> would encounter problems if they start arbitrarily violating the=20
> expectations of users of that platform. As such, `int` will generally be=
=20
> the "natural size" for the processor in question.
>
> This still depends on what degree of "natural" means. If I want to make i=
t=20
correct for the whole language (esp. when dealing with exotic platforms...=
=20
actually I do assert on CHAR_BIT, etc), I can rely on no such assumptions.

To me `int` only means:

   - return type of global `main`
   - necessary type for overloading of postfix `++`/`--`
   - prvalue type decayed from from `errno` (`errno` itself can be volatile=
=20
   qualified)
   - binary interop required by underlying ABI
   - some other things required or introduced by platform-specific API
  =20
I don't use `int` elsewhere, because it does nothing I want. Even the cases=
=20
above has still problematic in essential, but practically I can avoid type=
=20
safety issues of them (yeah, printf format is always a pain to other=20
wrapper types, too).

The last 2 bullets are also fit for other fundamental integer types. They=
=20
are the only "natural" cases (rather than merely historical reasons) can=20
make sense. I think the standard can do few about them, either. So the type=
=20
`int` is not so essentially special besides it just had been hard-coded in=
=20
some language rules long times ago.
=20

> There have been the names for "fastest" ones: intN_fast_t/uintN_fast_t.=
=20
>>
>> It is reasonable that things like intN_t cannot be mandated for every=20
>> platforms by practical reasons. But why not int_leastN_t/int_fastN_t?
>>
>
> They *are mandated* for all platforms. The only optional ones are those=
=20
> that use a specific bitdepth and the `intptr_t`s.
>
> =20
>
Every valid C++11 implementation must provide those types. Even=20
> freestanding implementations, which are permitted to only provide a subse=
t=20
> of the full standard library, are *required*, to provide these types.
>
OK, I should have said, they are not mandated *by the core language*, or,=
=20
not guaranteed both built-in and portable.

=20
>
>> The fact of keeping too many integer types without guarantees in the=20
>> language specification is the true ugliness. Their co-existence also=20
>> frustrates the normative type system (e.g. unsigned long vs. unsigned wh=
en=20
>> they are the same thing in the ABI). I prefer most of them will be=20
>> eventually conditionally-supported.
>>
>> BTW, I also don't think we have good reasons to provide more wrapper=20
>> types by the language specification. They can be unusable placeholders t=
oo=20
>> easily, causing compatibility and maintenance nightmare. Why should=20
>> programmers suffer from a `wchar_t` with 8-bit (yeah, damned Bionic)?
>>
>>

--=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/18a39611-8088-4e04-be0a-bb1b7c485683%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8812:18:35=EF=BC=8CNicol Bolas=
=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">On Monday, August 22, 2016 at 11:40:34 PM UTC-4, FrankHB1989 =
wrote:<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">=E5=9C=A8 20=
16=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=
=E5=8D=8810:56:48=EF=BC=8CRen Industries=E5=86=99=E9=81=93=EF=BC=9A<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yes, <i>what if another pl=
atform is 16 bit? </i>How in the world are we to change that platform so it=
 supports 32 bit ints?<div>All the currently working code would break, and =
for a lot of legacy systems the actual code might be gone.</div><div><br></=
div><div>Even if everyone had the source code to every program, many progra=
ms may <i>depend</i>=C2=A0on int being 16 bits.</div><div>The code might no=
t make sense using 32 bit integers. For example, some DSP&#39;s are still 1=
6 bit; emulating 32 bits on 16 bit processors will more than half the speed=
 of the code. And much code on these sorts of units is time critical; they =
might not have that many cycles to spare.</div><div>=C2=A0</div></div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div=
><div>Finally, the fundamental meaning of &quot;int&quot; would change; int=
 would no longer be the natural size for the platform. So why the hell are =
we calling it int anymore? It&#39;s a 32 bit integer, not a platform neutra=
l integer. Either we need to name it more strictly (such as int32_t or some=
thing) or we need to give a new name to &quot;platform neutral&quot; intege=
r or &quot;most natural&quot; integer or &quot;fastest&quot; integer. Maybe=
 intnatural? natural? fixed?</div><div><br></div></div></blockquote><div>Th=
ere is no guarantee about &quot;natural size&quot;.<br></div></div></blockq=
uote><div><br>Yes, there is no guarantee about what that means. But compile=
r writers would encounter problems if they start arbitrarily violating the =
expectations of users of that platform. As such, `int` will generally be th=
e &quot;natural size&quot; for the processor in question.<br><br></div></di=
v></blockquote><div>This still depends on what degree of &quot;natural&quot=
; means. If I want to make it correct for the whole language (esp. when dea=
ling with exotic platforms... actually I do assert on CHAR_BIT, etc), I can=
 rely on no such assumptions.<br><br>To me `int` only means:<br><ul><li>ret=
urn type of global `main`</li><li>necessary type for overloading of postfix=
 `++`/`--`<br></li><li>prvalue type decayed from from `errno` (`errno` itse=
lf can be volatile qualified)</li><li>binary interop required by underlying=
 ABI<br></li><li>some other things required or introduced by platform-speci=
fic API<br></li></ul>I don&#39;t use `int` elsewhere, because it does nothi=
ng I want. Even the cases above has still problematic in essential, but pra=
ctically I can avoid type safety issues of them (yeah, printf format is alw=
ays a pain to other wrapper types, too).<br><br>The last 2 bullets are also=
 fit for other fundamental integer types. They are the only &quot;natural&q=
uot; cases (rather than merely historical reasons) can make sense. I think =
the standard can do few about them, either. So the type `int` is not so ess=
entially special besides it just had been hard-coded in some language rules=
 long times ago.<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;"><div dir=3D"ltr"><div></div><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"><div></div><div>There have been the names for &quot;faste=
st&quot; ones: intN_fast_t/uintN_fast_t. <br></div><div><br>It is reasonabl=
e that things like intN_t cannot be mandated for every platforms by practic=
al reasons. But why not int_leastN_t/int_fastN_t?</div></div></blockquote><=
div><br>They <i>are mandated</i> for all platforms. The only optional ones =
are those that use a specific bitdepth and the `intptr_t`s.<br><br>=C2=A0<b=
r></div></div></blockquote><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"><div>Every valid C++11 implementation must provide those type=
s. Even freestanding implementations, which are permitted to only provide a=
 subset of the full standard library, are <i>required</i>, to provide these=
 types.<br></div></div></blockquote><div>OK, I should have said, they are n=
ot mandated <i>by the core language</i>, or, not guaranteed both built-in a=
nd portable.<br><br></div><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"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>The fact of keeping too many integer types without guarant=
ees in the language specification is the true ugliness. Their co-existence =
also frustrates the normative type system (e.g. unsigned long vs. unsigned =
when they are the same thing in the ABI). I prefer most of them will be eve=
ntually conditionally-supported.<br><br>BTW, I also don&#39;t think we have=
 good reasons to provide more wrapper types by the language specification. =
They can be unusable placeholders too easily, causing compatibility and mai=
ntenance nightmare. Why should programmers suffer from a `wchar_t` with 8-b=
it (yeah, damned Bionic)?</div><br></div></blockquote></div></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/18a39611-8088-4e04-be0a-bb1b7c485683%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18a39611-8088-4e04-be0a-bb1b7c485683=
%40isocpp.org</a>.<br />

------=_Part_73_1650552891.1471926973061--

------=_Part_72_1154282005.1471926973060--

.

On segunda-feira, 22 de agosto de 2016 21:36:12 PDT FrankHB1989 wrote:
> OK, I should have said, they are not mandated *by the core language*, or,
> not guaranteed both built-in and portable.

They are mandated in a header that complements the core language. Just like
<intializer_list>, <type_traits> and <limits>, those types cannot be
implemented by anyone except the compiler vendor.

Therefore, for all intents and purposes, the minimum-width and fast integer
types are guaranteed to be portable.

The exact-width ones aren't guaranteed to be portable because their concept
isn't portable. Some machines don't have 8-, 16-, 32- and 64-bit types (they
could be multiples of 9 bits). Also note how int32_t is required to use two's
complement representation, which again excludes some machines.

--
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/1706311.trY4MaExHO%40tjmaciei-mobl1.

.

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

On Tue, Aug 23, 2016 at 5:49 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> Also note how int32_t is required to use two's
> complement representation, which again excludes some machines.


Good point but applies to all the exact-width signed types in <cstdint>,
not just the 32-bit one.

--
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/CACGiwhEk2-zakumxPaJb0WkD5MmP1JS8s2KXNkYBJjyGK8guEA%40mail.gmail.com.

--001a1146a0dce0236d053ab65f8f
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 T=
ue, Aug 23, 2016 at 5:49 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also note how int32_t is=
 required to use two&#39;s<br>
complement representation, which again excludes some machines.</blockquote>=
<div><br></div><div>Good point but applies to all the exact-width signed ty=
pes in &lt;cstdint&gt;, not just the 32-bit one. <br></div></div></div></di=
v>

<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/CACGiwhEk2-zakumxPaJb0WkD5MmP1JS8s2KX=
NkYBJjyGK8guEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEk2-zakumx=
PaJb0WkD5MmP1JS8s2KXNkYBJjyGK8guEA%40mail.gmail.com</a>.<br />

--001a1146a0dce0236d053ab65f8f--

.

------=_Part_1765_82022597.1471951880486
Content-Type: multipart/alternative;
 boundary="----=_Part_1766_1879929115.1471951880486"

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



=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8812:49:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On segunda-feira, 22 de agosto de 2016 21:36:12 PDT FrankHB1989 wrote:=20
> > OK, I should have said, they are not mandated *by the core language*,=
=20
> or,=20
> > not guaranteed both built-in and portable.=20
>
> They are mandated in a header that complements the core language. Just=20
> like=20
> <intializer_list>, <type_traits> and <limits>, those types cannot be=20
> implemented by anyone except the compiler vendor.=20
>
> Therefore, for all intents and purposes, the minimum-width and fast=20
> integer=20
> types are guaranteed to be portable.=20
>
> The exact-width ones aren't guaranteed to be portable because their=20
> concept=20
> isn't portable. Some machines don't have 8-, 16-, 32- and 64-bit types=20
> (they=20
> could be multiples of 9 bits). Also note how int32_t is required to use=
=20
> two's=20
> complement representation, which again excludes some machines.=20
>
> Good point about 2's complements. However, all of these are what I have=
=20
already known. I still wonder why these (at least partially) width-aware=20
types are not in the core language while traditional fundamental integer=20
types are still in it. In a systemic view of design, this is an=20
inappropriate inversion of abstraction layers -- all implementations in=20
reality build these fundamental types on some integer types with known=20
width provided by underlying specification, or just with the width=20
specified artificially. Since we always will have some exact width integers=
=20
in the stacks of implementation, why not lift the uncertainty to the higher=
=20
level? Though I don't think declaring `short` or `long` by users very=20
useful, but it gives us an opportunity to have the core language cleaner,=
=20
with less confusion, meeting better to the principle of zero-cost=20
abstraction mentally, and being a little easier to implement.
Or perhaps better keeping them all out of the core language?


--=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/36958399-1282-4cef-a12b-0439e176aeda%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8812:49:54=EF=BC=8CThiago Maciei=
ra=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n segunda-feira, 22 de agosto de 2016 21:36:12 PDT FrankHB1989 wrote:
<br>&gt; OK, I should have said, they are not mandated *by the core languag=
e*, or,=20
<br>&gt; not guaranteed both built-in and portable.
<br>
<br>They are mandated in a header that complements the core language. Just =
like=20
<br>&lt;intializer_list&gt;, &lt;type_traits&gt; and &lt;limits&gt;, those =
types cannot be=20
<br>implemented by anyone except the compiler vendor.
<br>
<br>Therefore, for all intents and purposes, the minimum-width and fast int=
eger=20
<br>types are guaranteed to be portable.
<br>
<br>The exact-width ones aren&#39;t guaranteed to be portable because their=
 concept=20
<br>isn&#39;t portable. Some machines don&#39;t have 8-, 16-, 32- and 64-bi=
t types (they=20
<br>could be multiples of 9 bits). Also note how int32_t is required to use=
 two&#39;s=20
<br>complement representation, which again excludes some machines.
<br>
<br></blockquote><div>Good point about 2&#39;s complements. However, all of=
 these are what I have already known. I still wonder why these (at least pa=
rtially) width-aware types are not in the core language while traditional f=
undamental integer types are still in it. In a <span class=3D"op_dict3_font=
24 op_dict3_marginRight">systemic view of design, this is an inappropriate =
inversion of abstraction layers -- all implementations in reality build the=
se fundamental types on some integer types with known width provided by und=
erlying specification, or just with the width specified artificially. Since=
 we always will have some exact width integers in the stacks of implementat=
ion, why not lift the uncertainty to the higher level? Though I don&#39;t t=
hink declaring `short` or `long` by users very useful, but it gives us an o=
pportunity to have the core language cleaner, with less confusion, meeting =
better to the principle of zero-cost abstraction mentally, and being a litt=
le easier to implement.<br>Or perhaps better keeping them all out of the co=
re language?<br><br><br></span></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 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></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/36958399-1282-4cef-a12b-0439e176aeda%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36958399-1282-4cef-a12b-0439e176aeda=
%40isocpp.org</a>.<br />

------=_Part_1766_1879929115.1471951880486--

------=_Part_1765_82022597.1471951880486--

.

------=_Part_389_1793943491.1471959189020
Content-Type: multipart/alternative;
 boundary="----=_Part_390_1598992881.1471959189020"

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

On Tuesday, August 23, 2016 at 7:31:20 AM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8B=E5=8D=8812:49:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>>
>> On segunda-feira, 22 de agosto de 2016 21:36:12 PDT FrankHB1989 wrote:=
=20
>> > OK, I should have said, they are not mandated *by the core language*,=
=20
>> or,=20
>> > not guaranteed both built-in and portable.=20
>>
>> They are mandated in a header that complements the core language. Just=
=20
>> like=20
>> <intializer_list>, <type_traits> and <limits>, those types cannot be=20
>> implemented by anyone except the compiler vendor.=20
>>
>> Therefore, for all intents and purposes, the minimum-width and fast=20
>> integer=20
>> types are guaranteed to be portable.=20
>>
>> The exact-width ones aren't guaranteed to be portable because their=20
>> concept=20
>> isn't portable. Some machines don't have 8-, 16-, 32- and 64-bit types=
=20
>> (they=20
>> could be multiples of 9 bits). Also note how int32_t is required to use=
=20
>> two's=20
>> complement representation, which again excludes some machines.=20
>>
>> Good point about 2's complements. However, all of these are what I have=
=20
> already known. I still wonder why these (at least partially) width-aware=
=20
> types are not in the core language while traditional fundamental integer=
=20
> types are still in it.
>

.... why does it matter if it's a reserved keyword or not? It's *there*;=20
it's available on every platform that provides C++11 or better. You can use=
=20
it to solve the problem you have with types not having a relatively fixed=
=20
size.

The placement of something in the standard library or core language is not=
=20
based on some evaluation of the *merit* of the feature.

--=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/616f8567-2214-4424-a1e3-85ce70e5c99b%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, August 23, 2016 at 7:31:20 AM UTC-4, FrankHB19=
89 wrote:<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">=E5=
=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=
=E4=B8=8B=E5=8D=8812:49:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=BC=
=9A<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">On segunda-feira, 22 de agosto d=
e 2016 21:36:12 PDT FrankHB1989 wrote:
<br>&gt; OK, I should have said, they are not mandated *by the core languag=
e*, or,=20
<br>&gt; not guaranteed both built-in and portable.
<br>
<br>They are mandated in a header that complements the core language. Just =
like=20
<br>&lt;intializer_list&gt;, &lt;type_traits&gt; and &lt;limits&gt;, those =
types cannot be=20
<br>implemented by anyone except the compiler vendor.
<br>
<br>Therefore, for all intents and purposes, the minimum-width and fast int=
eger=20
<br>types are guaranteed to be portable.
<br>
<br>The exact-width ones aren&#39;t guaranteed to be portable because their=
 concept=20
<br>isn&#39;t portable. Some machines don&#39;t have 8-, 16-, 32- and 64-bi=
t types (they=20
<br>could be multiples of 9 bits). Also note how int32_t is required to use=
 two&#39;s=20
<br>complement representation, which again excludes some machines.
<br>
<br></blockquote><div>Good point about 2&#39;s complements. However, all of=
 these are what I have already known. I still wonder why these (at least pa=
rtially) width-aware types are not in the core language while traditional f=
undamental integer types are still in it.</div></div></blockquote><div><br>=
.... why does it matter if it&#39;s a reserved keyword or not? It&#39;s <i>t=
here</i>; it&#39;s available on every platform that provides C++11 or bette=
r. You can use it to solve the problem you have with types not having a rel=
atively fixed size.<br><br>The placement of something in the standard libra=
ry or core language is not based on some evaluation of the <i>merit</i> of =
the feature.<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/616f8567-2214-4424-a1e3-85ce70e5c99b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/616f8567-2214-4424-a1e3-85ce70e5c99b=
%40isocpp.org</a>.<br />

------=_Part_390_1598992881.1471959189020--

------=_Part_389_1793943491.1471959189020--

.

On ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote:
> Good point about 2's complements. However, all of these are what I have=
=20
> already known. I still wonder why these (at least partially) width-aware=
=20
> types are not in the core language while traditional fundamental integer=
=20
> types are still in it. In a systemic view of design, this is an=20
> inappropriate inversion of abstraction layers -- all implementations in=
=20
> reality build these fundamental types on some integer types with known=20
> width provided by underlying specification, or just with the width=20
> specified artificially. Since we always will have some exact width intege=
rs=20
> in the stacks of implementation, why not lift the uncertainty to the high=
er
> level? Though I don't think declaring `short` or `long` by users very
> useful, but it gives us an opportunity to have the core language cleaner,
> with less confusion, meeting better to the principle of zero-cost
> abstraction mentally, and being a little easier to implement.
> Or perhaps better keeping them all out of the core language?

Like Nicol said, I don't see what the issue is about having to #include=20
something before you can use the types. I find that having the exact-width=
=20
types *not* be reserved keywords is a better option, because it won't break=
=20
code that has myNS::int32_t, nor code that was ABI-dependent but fully vali=
d=20
that defined (and defines) int32_t in the global namespace.

Moreover, as we've said time and again, the exact-width integer types aren'=
t=20
required to exist in all implementations. Your statement saying "we will=20
always have some exact width integers" is incorrect. So what's the point of=
=20
having a reserved word that can't be used?

You may not think that using short or long is very useful, but others may=
=20
disagree with you. I personally agree partially and disagree on other parts=
..=20
More to the point, changing the fundamental integer types now is a simple n=
on-
starter. Leave them alone.

--=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/7777451.RoO7Qxo2g3%40tjmaciei-mobl1.

.

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

=E2=80=8Bgoing O.T ,but seems essential.plzzzzz do not blame anybody(O.P) f=
or=E2=80=8B
needing more time to become like you. A technical answer with enough
details means eveything.

thanks everyone,
FM.


2016-08-23 19:15 GMT+04:30 Thiago Macieira <thiago@macieira.org>:

> On ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote:
> > Good point about 2's complements. However, all of these are what I have
> > already known. I still wonder why these (at least partially) width-awar=
e
> > types are not in the core language while traditional fundamental intege=
r
> > types are still in it. In a systemic view of design, this is an
> > inappropriate inversion of abstraction layers -- all implementations in
> > reality build these fundamental types on some integer types with known
> > width provided by underlying specification, or just with the width
> > specified artificially. Since we always will have some exact width
> integers
> > in the stacks of implementation, why not lift the uncertainty to the
> higher
> > level? Though I don't think declaring `short` or `long` by users very
> > useful, but it gives us an opportunity to have the core language cleane=
r,
> > with less confusion, meeting better to the principle of zero-cost
> > abstraction mentally, and being a little easier to implement.
> > Or perhaps better keeping them all out of the core language?
>
> Like Nicol said, I don't see what the issue is about having to #include
> something before you can use the types. I find that having the exact-widt=
h
> types *not* be reserved keywords is a better option, because it won't bre=
ak
> code that has myNS::int32_t, nor code that was ABI-dependent but fully
> valid
> that defined (and defines) int32_t in the global namespace.
>
> Moreover, as we've said time and again, the exact-width integer types
> aren't
> required to exist in all implementations. Your statement saying "we will
> always have some exact width integers" is incorrect. So what's the point =
of
> having a reserved word that can't be used?
>
> You may not think that using short or long is very useful, but others may
> disagree with you. I personally agree partially and disagree on other
> parts.
> More to the point, changing the fundamental integer types now is a simple
> non-
> starter. Leave them alone.
>
> --
> 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/7777451.RoO7Qxo2g3%40tjmaciei-mobl1.
>



--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=20
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/CALDL7dHRprxGLtDtVGXYQwVK%2BiHd9DUmf-rOSjm7bOEbj=
YqvrA%40mail.gmail.com.

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

<div dir=3D"rtl"><div style=3D"direction:ltr"><div class=3D"gmail_default" =
style=3D"font-family:&quot;arial narrow&quot;,sans-serif;font-size:large">=
=E2=80=8Bgoing O.T ,but seems essential.plzzzzz do not blame anybody(O.P) f=
or=E2=80=8B needing more time to become like you. A technical answer with e=
nough details means eveything.</div><div class=3D"gmail_default" style=3D"f=
ont-family:&quot;arial narrow&quot;,sans-serif;font-size:large"><br></div><=
div class=3D"gmail_default" style=3D"text-align:right;font-family:&quot;ari=
al narrow&quot;,sans-serif;font-size:large">thanks everyone,</div><div clas=
s=3D"gmail_default" style=3D"text-align:right;font-family:&quot;arial narro=
w&quot;,sans-serif;font-size:large">FM.</div><br></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2016-08-23 19:=
15 GMT+04:30 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago=
@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span>:</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><span class=3D"">On ter=C3=A7a-feira, 23 de a=
gosto de 2016 04:31:20 PDT FrankHB1989 wrote:<br>
&gt; Good point about 2&#39;s complements. However, all of these are what I=
 have<br>
&gt; already known. I still wonder why these (at least partially) width-awa=
re<br>
&gt; types are not in the core language while traditional fundamental integ=
er<br>
&gt; types are still in it. In a systemic view of design, this is an<br>
&gt; inappropriate inversion of abstraction layers -- all implementations i=
n<br>
&gt; reality build these fundamental types on some integer types with known=
<br>
&gt; width provided by underlying specification, or just with the width<br>
&gt; specified artificially. Since we always will have some exact width int=
egers<br>
&gt; in the stacks of implementation, why not lift the uncertainty to the h=
igher<br>
&gt; level? Though I don&#39;t think declaring `short` or `long` by users v=
ery<br>
&gt; useful, but it gives us an opportunity to have the core language clean=
er,<br>
&gt; with less confusion, meeting better to the principle of zero-cost<br>
&gt; abstraction mentally, and being a little easier to implement.<br>
&gt; Or perhaps better keeping them all out of the core language?<br>
<br>
</span>Like Nicol said, I don&#39;t see what the issue is about having to #=
include<br>
something before you can use the types. I find that having the exact-width<=
br>
types *not* be reserved keywords is a better option, because it won&#39;t b=
reak<br>
code that has myNS::int32_t, nor code that was ABI-dependent but fully vali=
d<br>
that defined (and defines) int32_t in the global namespace.<br>
<br>
Moreover, as we&#39;ve said time and again, the exact-width integer types a=
ren&#39;t<br>
required to exist in all implementations. Your statement saying &quot;we wi=
ll<br>
always have some exact width integers&quot; is incorrect. So what&#39;s the=
 point of<br>
having a reserved word that can&#39;t be used?<br>
<br>
You may not think that using short or long is very useful, but others may<b=
r>
disagree with you. I personally agree partially and disagree on other parts=
..<br>
More to the point, changing the fundamental integer types now is a simple n=
on-<br>
starter. Leave them alone.<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<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@<wbr>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/7777451.RoO7Qxo2g3%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/7777451.RoO7Qxo2g3%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"rtl"><d=
iv><div dir=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your=
 hair in such a dark night??<br>unless the candle of your face does shed so=
me light upon my way!!!<br></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/CALDL7dHRprxGLtDtVGXYQwVK%2BiHd9DUmf-=
rOSjm7bOEbjYqvrA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dHRprxGLt=
DtVGXYQwVK%2BiHd9DUmf-rOSjm7bOEbjYqvrA%40mail.gmail.com</a>.<br />

--001a113f3d02713b67053ae959ff--

.

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

On Thu, Aug 25, 2016 at 2:12 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

> =E2=80=8Bgoing O.T ,but seems essential.plzzzzz do not blame anybody(O.P)=
 for=E2=80=8B
> needing more time to become like you. A technical answer with enough
> details means eveything.
>
> thanks everyone,
> FM.
>
>
+1

--=20
Be seeing you,
Tony

--=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/CAOHCbiv0XD4OJosCPuCrdee4sciAwNyOjnzPAPeXH7-T24p=
GdA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Aug 25, 2016 at 2:12 PM, Farid Mehrabi <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"rtl"><div style=3D"direction:ltr"><div style=3D"font-family:&quot;arial na=
rrow&quot;,sans-serif;font-size:large">=E2=80=8Bgoing O.T ,but seems essent=
ial.plzzzzz do not blame anybody(O.P) for=E2=80=8B needing more time to bec=
ome like you. A technical answer with enough details means eveything.</div>=
<div style=3D"font-family:&quot;arial narrow&quot;,sans-serif;font-size:lar=
ge"><br></div><div style=3D"text-align:right;font-family:&quot;arial narrow=
&quot;,sans-serif;font-size:large">thanks everyone,</div><div style=3D"text=
-align:right;font-family:&quot;arial narrow&quot;,sans-serif;font-size:larg=
e">FM.</div><br></div></div></blockquote><div><br>+1<span class=3D""></span=
><br clear=3D"all"></div></div><br>-- <br><div class=3D"gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></=
div>Tony<br></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/CAOHCbiv0XD4OJosCPuCrdee4sciAwNyOjnzP=
APeXH7-T24pGdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv0XD4OJosC=
PuCrdee4sciAwNyOjnzPAPeXH7-T24pGdA%40mail.gmail.com</a>.<br />

--001a114b14e078c033053aec09b1--

.

------=_Part_1782_591487521.1472557722340
Content-Type: multipart/alternative;
 boundary="----=_Part_1783_582962063.1472557722340"

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

=20
=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=889:33:09=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, August 23, 2016 at 7:31:20 AM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8B=E5=8D=8812:49:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=
=EF=BC=9A
>>>
>>> On segunda-feira, 22 de agosto de 2016 21:36:12 PDT FrankHB1989 wrote:=
=20
>>> > OK, I should have said, they are not mandated *by the core language*,=
=20
>>> or,=20
>>> > not guaranteed both built-in and portable.=20
>>>
>>> They are mandated in a header that complements the core language. Just=
=20
>>> like=20
>>> <intializer_list>, <type_traits> and <limits>, those types cannot be=20
>>> implemented by anyone except the compiler vendor.=20
>>>
>>> Therefore, for all intents and purposes, the minimum-width and fast=20
>>> integer=20
>>> types are guaranteed to be portable.=20
>>>
>>> The exact-width ones aren't guaranteed to be portable because their=20
>>> concept=20
>>> isn't portable. Some machines don't have 8-, 16-, 32- and 64-bit types=
=20
>>> (they=20
>>> could be multiples of 9 bits). Also note how int32_t is required to use=
=20
>>> two's=20
>>> complement representation, which again excludes some machines.=20
>>>
>>> Good point about 2's complements. However, all of these are what I have=
=20
>> already known. I still wonder why these (at least partially) width-aware=
=20
>> types are not in the core language while traditional fundamental integer=
=20
>> types are still in it.
>>
>
> ... why does it matter if it's a reserved keyword or not? It's *there*;=
=20
> it's available on every platform that provides C++11 or better. You can u=
se=20
> it to solve the problem you have with types not having a relatively fixed=
=20
> size.
>
> I don't think "to solve the problem you have with types not having a=20
relatively fixed size" useful in reality. Overflow of signed integers leads=
=20
to UB. Wrapped behavior on unsigned integers will cause unexpected result=
=20
too easily. Without a concrete limit of the range, they are dangerous (if=
=20
not that useless). So we need to know the size sooner or later. When size=
=20
is needed, they are *almost always suboptimal* choices. With such types we=
=20
actually have some implicit weak guarantees, e.g. an INT_MAX should be=20
greater than 32767. That's too subtle on readability. And I find nothing=20
reasonable to encourage such use. Then keeping them would cause=20
teachability problems, probably.

Well, I admit I am not motivated enough to push the change forward=20
currently since it does not benefit much at once. But getting consensus on=
=20
some points of design should be good.

The placement of something in the standard library or core language is not=
=20
> based on some evaluation of the *merit* of the feature.
>

Please also note "it works" should not be a normal reason in a process of=
=20
standardization. There will be great risks to simply pile features without=
=20
enough alternative choices considered carefully, and this will probably=20
waste time a lot in future (e.g. `export` and dynamic exception=20
specification). To do the "right thing" pedantically is unlikely to be a=20
premature optimization in such cases than in ordinary projects.

There should be at least one topic concerned here: the return type of=20
`std::uncaught_exceptions`.=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/4fcf4f5e-4a0a-49b9-b62e-ac9569858b11%40isocpp.or=
g.

------=_Part_1783_582962063.1472557722340
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: 1456px; height: 188px; visibility: hidden;" fram=
eborder=3D"0"></iframe><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=889:33:09=EF=BC=8CNicol Bolas=
=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">On Tuesday, August 23, 2016 at 7:31:20 AM UTC-4, FrankHB1989 =
wrote:<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">=E5=9C=A8 20=
16=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=
=E5=8D=8812:49:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=BC=9A<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">On segunda-feira, 22 de agosto de 2016 21:=
36:12 PDT FrankHB1989 wrote:
<br>&gt; OK, I should have said, they are not mandated *by the core languag=
e*, or,=20
<br>&gt; not guaranteed both built-in and portable.
<br>
<br>They are mandated in a header that complements the core language. Just =
like=20
<br>&lt;intializer_list&gt;, &lt;type_traits&gt; and &lt;limits&gt;, those =
types cannot be=20
<br>implemented by anyone except the compiler vendor.
<br>
<br>Therefore, for all intents and purposes, the minimum-width and fast int=
eger=20
<br>types are guaranteed to be portable.
<br>
<br>The exact-width ones aren&#39;t guaranteed to be portable because their=
 concept=20
<br>isn&#39;t portable. Some machines don&#39;t have 8-, 16-, 32- and 64-bi=
t types (they=20
<br>could be multiples of 9 bits). Also note how int32_t is required to use=
 two&#39;s=20
<br>complement representation, which again excludes some machines.
<br>
<br></blockquote><div>Good point about 2&#39;s complements. However, all of=
 these are what I have already known. I still wonder why these (at least pa=
rtially) width-aware types are not in the core language while traditional f=
undamental integer types are still in it.</div></div></blockquote><div><br>=
.... why does it matter if it&#39;s a reserved keyword or not? It&#39;s <i>t=
here</i>; it&#39;s available on every platform that provides C++11 or bette=
r. You can use it to solve the problem you have with types not having a rel=
atively fixed size.<br><br></div></div></blockquote><div>I don&#39;t think =
&quot;to solve the problem you have with types not having a=20
relatively fixed size&quot; useful in reality. Overflow of signed integers=
=20
leads to UB. Wrapped behavior on unsigned integers will cause unexpected
 result too easily. Without a concrete limit of the range, they are=20
dangerous (if not that useless). So we need to know the size sooner or=20
later. When size is needed, they are <i>almost always suboptimal</i>=20
choices. With such types we actually have some implicit weak guarantees,
 e.g. an INT_MAX should be greater than 32767. That&#39;s too subtle on=20
readability. And I find nothing reasonable to encourage such=20
use. Then keeping them would cause teachability problems, probably.<br><br>=
Well, I admit I am not motivated enough to push the change forward=20
currently since it does not benefit much at once. But getting consensus=20
on some points of design should be good.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>The placement of something in=
 the standard library or core language is not based on some evaluation of t=
he <i>merit</i> of the feature.<br></div></div></blockquote><div><br>Please=
 also note &quot;it works&quot; should=20
not be a normal reason in a process of standardization. There will be great=
 risks to simply pile features without enough alternative choices considere=
d carefully, and this will probably waste time a lot in future (e.g. `expor=
t` and dynamic exception specification). To do the &quot;right thing&quot; =
pedantically is unlikely to be a premature optimization in such cases than =
in ordinary projects.<br><br>There should be at least one topic concerned h=
ere: the return type of `std::uncaught_exceptions`. <br><br><br><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/4fcf4f5e-4a0a-49b9-b62e-ac9569858b11%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4fcf4f5e-4a0a-49b9-b62e-ac9569858b11=
%40isocpp.org</a>.<br />

------=_Part_1783_582962063.1472557722340--

------=_Part_1782_591487521.1472557722340--

.

------=_Part_1764_1623985175.1472559300959
Content-Type: multipart/alternative;
 boundary="----=_Part_1765_873464785.1472559300959"

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



=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8810:45:52=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote:=
=20
> > Good point about 2's complements. However, all of these are what I have=
=20
> > already known. I still wonder why these (at least partially) width-awar=
e=20
> > types are not in the core language while traditional fundamental intege=
r=20
> > types are still in it. In a systemic view of design, this is an=20
> > inappropriate inversion of abstraction layers -- all implementations in=
=20
> > reality build these fundamental types on some integer types with known=
=20
> > width provided by underlying specification, or just with the width=20
> > specified artificially. Since we always will have some exact width=20
> integers=20
> > in the stacks of implementation, why not lift the uncertainty to the=20
> higher=20
> > level? Though I don't think declaring `short` or `long` by users very=
=20
> > useful, but it gives us an opportunity to have the core language=20
> cleaner,=20
> > with less confusion, meeting better to the principle of zero-cost=20
> > abstraction mentally, and being a little easier to implement.=20
> > Or perhaps better keeping them all out of the core language?=20
>
> Like Nicol said, I don't see what the issue is about having to #include=
=20
> something before you can use the types. I find that having the exact-widt=
h=20
> types *not* be reserved keywords is a better option, because it won't=20
> break=20
> code that has myNS::int32_t, nor code that was ABI-dependent but fully=20
> valid=20
> that defined (and defines) int32_t in the global namespace.=20
>
> Actually I don't much care about the #include stuff. Keeping fixed-with=
=20
types away with hard-coded keywords also sounds better to me, though ABI=20
issues here are only caused by historical reasons -- e.g. if we does not=20
have them in current language, we would probably not reserve mangled=20
encoding for troublesome things like `unsigned long`, so many problems=20
would not exist at all.

However, I care why the so-called "fundamental" types *are there* even=20
there are nothing good reasons to use them? And, why not change, besides=20
the compatibility issues?
=20

> Moreover, as we've said time and again, the exact-width integer types=20
> aren't=20
> required to exist in all implementations. Your statement saying "we will=
=20
> always have some exact width integers" is incorrect. So what's the point=
=20
> of=20
> having a reserved word that can't be used?=20
>
> No. I did not mean the type of the C++ language, but the fixed-width=20
integer notions in *the whole stack* of the implementation, including ABI=
=20
references like ISA spec, and internal specification of hardware design,=20
etc. Since you can't physically implement "unspecified" width effectively,=
=20
you have to know at least one of the exact widths. That width is then *eras=
ed=20
*in some high level language like C and C++ before you recover it in a even=
=20
higher abstraction. It is a waste of effort on leaking abstraction.

BTW, I wish fixed-with integer type with certain strategies (2's=20
complement, wrapping behavior, UB or not on overflow, etc) mandated some=20
day, at least on hosted implementations, as BS put arbitrarily-width=20
integer type in the wishlist of standardization (IIRC).
=20

> You may not think that using short or long is very useful, but others may=
=20
> disagree with you. I personally agree partially and disagree on other=20
> parts.=20
> More to the point, changing the fundamental integer types now is a simple=
=20
> non-=20
> starter. Leave them alone.=20
>
> It is still arguable what is deserved to be true "fundamental", before=20
they are proposed to be changed.
=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/2e027e3a-4b4c-47e4-b6a2-f03e23c7e480%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:45:52=EF=BC=8CThiago Maciei=
ra=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote:
<br>&gt; Good point about 2&#39;s complements. However, all of these are wh=
at I have=20
<br>&gt; already known. I still wonder why these (at least partially) width=
-aware=20
<br>&gt; types are not in the core language while traditional fundamental i=
nteger=20
<br>&gt; types are still in it. In a systemic view of design, this is an=20
<br>&gt; inappropriate inversion of abstraction layers -- all implementatio=
ns in=20
<br>&gt; reality build these fundamental types on some integer types with k=
nown=20
<br>&gt; width provided by underlying specification, or just with the width=
=20
<br>&gt; specified artificially. Since we always will have some exact width=
 integers=20
<br>&gt; in the stacks of implementation, why not lift the uncertainty to t=
he higher
<br>&gt; level? Though I don&#39;t think declaring `short` or `long` by use=
rs very
<br>&gt; useful, but it gives us an opportunity to have the core language c=
leaner,
<br>&gt; with less confusion, meeting better to the principle of zero-cost
<br>&gt; abstraction mentally, and being a little easier to implement.
<br>&gt; Or perhaps better keeping them all out of the core language?
<br>
<br>Like Nicol said, I don&#39;t see what the issue is about having to #inc=
lude=20
<br>something before you can use the types. I find that having the exact-wi=
dth=20
<br>types *not* be reserved keywords is a better option, because it won&#39=
;t break=20
<br>code that has myNS::int32_t, nor code that was ABI-dependent but fully =
valid=20
<br>that defined (and defines) int32_t in the global namespace.
<br>
<br></blockquote><div>Actually I don&#39;t much care about the #include stu=
ff. Keeping fixed-with types away with hard-coded keywords also sounds bett=
er to me, though ABI issues here are only caused by historical reasons -- e=
..g. if we does not have them in current language, we would probably not res=
erve mangled encoding for troublesome things like `unsigned long`, so many =
problems would not exist at all.<br><br>However, I care why the so-called &=
quot;fundamental&quot; types <i>are there</i> even there are nothing good r=
easons to use them? And, why not change, besides the compatibility issues?<=
br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Moreover, a=
s we&#39;ve said time and again, the exact-width integer types aren&#39;t=
=20
<br>required to exist in all implementations. Your statement saying &quot;w=
e will=20
<br>always have some exact width integers&quot; is incorrect. So what&#39;s=
 the point of=20
<br>having a reserved word that can&#39;t be used?
<br>
<br></blockquote><div>No. I did not mean the type of the C++ language, but =
the fixed-width integer notions in <i>the whole stack</i> of the implementa=
tion, including ABI references like ISA spec, and internal specification of=
 hardware design, etc. Since you can&#39;t physically implement &quot;unspe=
cified&quot; width effectively, you have to know at least one of the exact =
widths. That width is then <i>erased </i>in some high level language like C=
 and C++ before you recover it in a even higher abstraction. It is a waste =
of effort on leaking abstraction.<br><br>BTW, I wish fixed-with integer typ=
e with certain strategies (2&#39;s complement, wrapping behavior, UB or not=
 on overflow, etc) mandated some day, at least on hosted implementations, a=
s BS put arbitrarily-width integer type in the wishlist of standardization =
(IIRC).<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You=
 may not think that using short or long is very useful, but others may=20
<br>disagree with you. I personally agree partially and disagree on other p=
arts.=20
<br>More to the point, changing the fundamental integer types now is a simp=
le non-
<br>starter. Leave them alone.
<br>
<br></blockquote><div>It is still arguable what is deserved to be true &quo=
t;fundamental&quot;, before they are proposed to be changed.<br>=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 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></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/2e027e3a-4b4c-47e4-b6a2-f03e23c7e480%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e027e3a-4b4c-47e4-b6a2-f03e23c7e480=
%40isocpp.org</a>.<br />

------=_Part_1765_873464785.1472559300959--

------=_Part_1764_1623985175.1472559300959--

.

--089e014934acb20c6f053b50f745
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 30, 2016 at 7:48 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> There should be at least one topic concerned here: the return type of
> `std::uncaught_exceptions`.
>
>
>

IIRC (I don't recall which meeting or which subgroup however) that was
discussed at committee.  We intentionally picked int.  It wasn't just "go
with whatever was in the proposal", it was discussed and debated.
Consensus was int, and I don't think it was contentious.


For the general topic of signed vs unsigned, see Stroustrup et al at

https://www.youtube.com/watch?v=3DPuio5dly9N8

First mentioned at 9:50,
41:08 for the long answer
1:02:50 for where they just give the short answer: =E2=80=9Csorry=E2=80=9D


--=20
Be seeing you,
Tony

--=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/CAOHCbisCBBLqDBT1yMTmi2RHPUvpx1v%2BxqW_ZW%3Df0Bn=
vufkf%2BA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Aug 30, 2016 at 7:48 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a t=
arget=3D"_blank" href=3D"mailto:frankhb1989@gmail.com">frankhb1989@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote=
">=C2=A0<br><div dir=3D"ltr"><div><br>There should be at least one topic co=
ncerned here: the return type of `std::uncaught_exceptions`. <br><br><br></=
div></div></blockquote><div><br><br>IIRC (I=20
don&#39;t recall which meeting or which subgroup however) that was discusse=
d
 at committee.=C2=A0 We intentionally picked int.=C2=A0 It wasn&#39;t just =
&quot;go with=20
whatever was in the proposal&quot;, it was discussed and debated.=C2=A0 Con=
sensus=20
was int, and I don&#39;t think it was contentious.<br><br><br><div>For the =
general topic of signed vs unsigned, see Stroustrup et al at <br><p><a href=
=3D"https://www.youtube.com/watch?v=3DPuio5dly9N8">https://www.youtube.com/=
watch?v=3DPuio5dly9N8</a> <br></p><p>First mentioned at 9:50,<br>
41:08 for the long answer<br>
1:02:50 for where they just give the short answer: =E2=80=9Csorry=E2=80=9D<=
/p><br clear=3D"all"></div></div></div><br>-- <br><div class=3D"gmail_signa=
ture"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></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/CAOHCbisCBBLqDBT1yMTmi2RHPUvpx1v%2Bxq=
W_ZW%3Df0Bnvufkf%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisCBB=
LqDBT1yMTmi2RHPUvpx1v%2BxqW_ZW%3Df0Bnvufkf%2BA%40mail.gmail.com</a>.<br />

--089e014934acb20c6f053b50f745--

.