------=_Part_6227_168825676.1412364772621
Content-Type: text/plain; charset=UTF-8

I have mulled over this for a while now. Since long long and unsigned long
long are a part of the standard now, why not long long double?

Essentially, it would be a floating-point type such that sizeof(long
double) <= sizeof(long long double). This would enable compilers to use long
double for the x86 extended precision format
<https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format>
while using long long double for the quadruple-precision floating point
format
<https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>
on systems on which both are supported.

Anyone else think this is a good idea?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I have mulled over this for a while now. Since <span style=
=3D"font-family: courier new,monospace;">long long</span> and <span style=
=3D"font-family: courier new,monospace;">unsigned long long</span> are a pa=
rt of the standard now, why not <span style=3D"font-family: courier new,mon=
ospace;">long long double</span>?<br><br>Essentially, it would be a floatin=
g-point type such that <span style=3D"font-family: courier new,monospace;">=
sizeof(long double) &lt;=3D sizeof(long long double)</span>. This would ena=
ble compilers to use <span style=3D"font-family: courier new,monospace;">lo=
ng double </span>for the <a href=3D"https://en.wikipedia.org/wiki/Extended_=
precision#x86_Extended_Precision_Format">x86 extended precision format</a> =
while using <span style=3D"font-family: courier new,monospace;">long long d=
ouble</span> for the <a href=3D"https://en.wikipedia.org/wiki/Quadruple-pre=
cision_floating-point_format">quadruple-precision floating point format</a>=
 on systems on which both are supported.<br><br>Anyone else think this is a=
 good idea?<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6227_168825676.1412364772621--

.

------=_Part_4958_20707362.1412451525623
Content-Type: text/plain; charset=UTF-8

On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:
>
> I have mulled over this for a while now. Since long long and unsigned
> long long are a part of the standard now, why not long long double?
>
> Essentially, it would be a floating-point type such that sizeof(long
> double) <= sizeof(long long double). This would enable compilers to use long
> double for the x86 extended precision format
> <https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format>
> while using long long double for the quadruple-precision floating point
> format
> <https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>
> on systems on which both are supported.
>
> Anyone else think this is a good idea?
>

And so Visual C++ would be forced to have to implement *another* type that
is physically but not semantically identical to double?

Maybe instead the rules should just be modified to be like integers, and
allow implementations to define "extended floating point types" much like
how implementations can have extended integer types, like GCC's __int128.

Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I have mulled o=
ver this for a while now. Since <span style=3D"font-family:courier new,mono=
space">long long</span> and <span style=3D"font-family:courier new,monospac=
e">unsigned long long</span> are a part of the standard now, why not <span =
style=3D"font-family:courier new,monospace">long long double</span>?<br><br=
>Essentially, it would be a floating-point type such that <span style=3D"fo=
nt-family:courier new,monospace">sizeof(long double) &lt;=3D sizeof(long lo=
ng double)</span>. This would enable compilers to use <span style=3D"font-f=
amily:courier new,monospace">long double </span>for the <a href=3D"https://=
en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format" tar=
get=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtended_precision%23x86_Extended_Pr=
ecision_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNHQ3pk61cM5dzLhGbs_EfrObHj=
FAw';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtended_precision%23x86_Extended_Pr=
ecision_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNHQ3pk61cM5dzLhGbs_EfrObHj=
FAw';return true;">x86 extended precision format</a> while using <span styl=
e=3D"font-family:courier new,monospace">long long double</span> for the <a =
href=3D"https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_fo=
rmat" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FQuadruple-precision_floatin=
g-point_format\46sa\75D\46sntz\0751\46usg\75AFQjCNG-kikLjGOnSCM0zxiYPNfLUFt=
yPg';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FQuadruple-precision_floating-point_f=
ormat\46sa\75D\46sntz\0751\46usg\75AFQjCNG-kikLjGOnSCM0zxiYPNfLUFtyPg';retu=
rn true;">quadruple-precision floating point format</a> on systems on which=
 both are supported.<br><br>Anyone else think this is a good idea?<br></div=
></blockquote><div><br>And so Visual C++ would be forced to have to impleme=
nt <i>another</i> type that is physically but not semantically identical to=
 <span style=3D"font-family: courier new,monospace;">double</span>?<br><br>=
Maybe instead the rules should just be modified to be like integers, and al=
low implementations to define "extended floating point types" much like how=
 implementations can have extended integer types, like GCC's <span style=3D=
"font-family: courier new,monospace;">__int128</span>.<br><br>Melissa<br></=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4958_20707362.1412451525623--

.

------=_Part_330_1972786645.1412457951000
Content-Type: text/plain; charset=UTF-8

On Saturday, 4 October 2014 21:38:45 UTC+2, Myriachan wrote:
>
> And so Visual C++ would be forced to have to implement *another* type
> that is physically but not semantically identical to double?
>

I don't see what that has to do with anything. If Microsoft is incapable of
making a good compiler*, that's their problem, not something which should
burden the C++ standard.

* - For me, on Windows 7 64-bit, with GCC (MinGW-w64
<https://sourceforge.net/projects/mingw-w64/>), sizeof(double) is 8 while sizeof(long
double) is 16.


> Maybe instead the rules should just be modified to be like integers, and
> allow implementations to define "extended floating point types" much like
> how implementations can have extended integer types, like GCC's __int128.
>

I'm not sure what you mean by "extended floating point types (...)  like
GCC's __int128". If you mean what I think you mean, that is sort of already
the case - GCC has __float128 for guaranteed quadruple-precision
floating-point on systems which support it, however that's GCC's
non-standard extension - that is not specified anywhere in the standard. As
such, it is not portable at all, i.e. only works with GCC, which is sort of
the whole point of my proposal - to provide a standardised way for
compilers to have both the 80-bit extended-precision floating-point as well
as 128-bit quadruple-precision floating-point (if the system supports them
both) with the code being standard-conforming and portable, not just a
specific compiler's non-standard-conforming addition (i.e. hack).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Saturday, 4 October 2014 21:38:45 UTC+2, Myriachan  wro=
te:<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>And s=
o Visual C++ would be forced to have to implement <i>another</i> type that =
is physically but not semantically identical to <span style=3D"font-family:=
courier new,monospace">double</span>?<br></div></div></blockquote><div><br>=
I don't see what that has to do with anything. If Microsoft is incapable of=
 making a good compiler*, that's their problem, not something which should =
burden the C++ standard.<br><br>* - For me, on Windows 7 64-bit, with GCC (=
<a href=3D"https://sourceforge.net/projects/mingw-w64/">MinGW-w64</a>), <sp=
an style=3D"font-family: courier new,monospace;">sizeof(double)</span> is 8=
 while <span style=3D"font-family: courier new,monospace;">sizeof(long doub=
le)</span> is 16.<br>&nbsp;</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>Maybe instead the rules should just be modified to=
 be like integers, and allow implementations to define "extended floating p=
oint types" much like how implementations can have extended integer types, =
like GCC's <span style=3D"font-family:courier new,monospace">__int128</span=
>.<br></div></div></blockquote><div><br>I'm not sure what you mean by "exte=
nded floating point types (...)&nbsp; like GCC's <span style=3D"font-family=
: courier new,monospace;">__int128</span>". If you mean what I think you me=
an, that is sort of already the case - GCC has <span style=3D"font-family: =
courier new,monospace;"><code>__float128<font face=3D"arial,sans-serif"> fo=
r guaranteed quadruple-precision floating-point on systems which support it=
, however that's GCC's non-standard extension - that is not specified anywh=
ere in the standard. As such, it is not portable at all, i.e. only works wi=
th GCC, which is sort of the whole point of my proposal - to provide a stan=
dardised way for compilers to have both the 80-bit extended-precision float=
ing-point as well as 128-bit quadruple-precision floating-point (if the sys=
tem supports them both) with the code being standard-conforming and portabl=
e, not just a specific compiler's non-standard-conforming addition (i.e. ha=
ck).</font><br></code></span></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_330_1972786645.1412457951000--

.

On Saturday 04 October 2014 14:25:50 Ivo wrote:
> as 128-bit quadruple-precision floating-point (if the system supports them
> both) with the code being standard-conforming and portable, not just a

What systems are those?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2902_467543128.1412461703847
Content-Type: text/plain; charset=UTF-8

On Sunday, 5 October 2014 00:06:32 UTC+2, Thiago Macieira wrote:
>
> On Saturday 04 October 2014 14:25:50 Ivo wrote:
> > as 128-bit quadruple-precision floating-point (if the system supports
> them
> > both) with the code being standard-conforming and portable, not just a
>
> What systems are those?
>

Well, from here
<https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format>
:

> The x86 Extended Precision Format is an 80-bit format first implemented in
> the Intel 8087 <https://en.wikipedia.org/wiki/Intel_8087> math coprocessor
> <https://en.wikipedia.org/wiki/Coprocessor> and *is supported by all
> processors that are based on the x86 design
> <https://en.wikipedia.org/wiki/X86_architecture> which incorporate a
> floating point unit <https://en.wikipedia.org/wiki/Floating_point_unit>*.


Since GCC uses quadruple-precision for long double on my computer which has
a processor based on the x86 architecture, my computer supports both
extended precision and quadruple-precision.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Sunday, 5 October 2014 00:06:32 UTC+2, Thiago Macieira =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday 04 October =
2014 14:25:50 Ivo wrote:
<br>&gt; as 128-bit quadruple-precision floating-point (if the system suppo=
rts them=20
<br>&gt; both) with the code being standard-conforming and portable, not ju=
st a=20
<br>
<br>What systems are those?
<br></blockquote><div><br>Well, from <a href=3D"https://en.wikipedia.org/wi=
ki/Extended_precision#x86_Extended_Precision_Format">here</a>:<br><blockquo=
te style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;" class=3D"gmail_quote">The x86 Extended Precision=
 Format is an 80-bit format first implemented in the <a href=3D"https://en.=
wikipedia.org/wiki/Intel_8087" title=3D"Intel 8087">Intel 8087</a> math <a =
href=3D"https://en.wikipedia.org/wiki/Coprocessor" title=3D"Coprocessor">co=
processor</a> and <b>is supported by all processors that are based on the <=
a href=3D"https://en.wikipedia.org/wiki/X86_architecture" title=3D"X86 arch=
itecture" class=3D"mw-redirect">x86 design</a> which incorporate a <a href=
=3D"https://en.wikipedia.org/wiki/Floating_point_unit" title=3D"Floating po=
int unit" class=3D"mw-redirect">floating point unit</a></b>.</blockquote><d=
iv><br>Since GCC uses quadruple-precision for <span style=3D"font-family: c=
ourier new,monospace;">long double</span> on my computer which has a proces=
sor based on the x86 architecture, my computer supports both extended preci=
sion and quadruple-precision.<br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2902_467543128.1412461703847--

.

------=_Part_19_1765880795.1412470000479
Content-Type: text/plain; charset=UTF-8

Can we maybe shy away from adding yet more imprecise and confusing names
for types and aim for direct and meaningful names? float128_t, float64_t,
etc. make more sense and parellel int8_t, uint16_t, and so on.

They can be optional for platforms that don't support them. Libraries can
make use of SG10 feature detection support for selecting "big enough" types
if for some reason they think they _could_ use extended precision but don't
require it (is there any such reasonable use case) or better yet use
templates to let the user select based on target hardware.

On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:
>
> I have mulled over this for a while now. Since long long and unsigned
> long long are a part of the standard now, why not long long double?
>
> Essentially, it would be a floating-point type such that sizeof(long
> double) <= sizeof(long long double). This would enable compilers to use long
> double for the x86 extended precision format
> <https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format>
> while using long long double for the quadruple-precision floating point
> format
> <https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>
> on systems on which both are supported.
>
> Anyone else think this is a good idea?
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Can we maybe shy away from adding yet more imprecise and c=
onfusing names for types and aim for direct and meaningful names? float128_=
t, float64_t, etc. make more sense and parellel int8_t, uint16_t, and so on=
..<div><br></div><div>They can be optional for platforms that don't support =
them. Libraries can make use of SG10 feature detection support for selectin=
g "big enough" types if for some reason they think they _could_ use extende=
d precision but don't require it (is there any such reasonable use case) or=
 better yet use templates to let the user select based on target hardware.<=
/div><div><br></div><div>On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo =
wrote:<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">I have =
mulled over this for a while now. Since <span style=3D"font-family:courier =
new,monospace">long long</span> and <span style=3D"font-family:courier new,=
monospace">unsigned long long</span> are a part of the standard now, why no=
t <span style=3D"font-family:courier new,monospace">long long double</span>=
?<br><br>Essentially, it would be a floating-point type such that <span sty=
le=3D"font-family:courier new,monospace">sizeof(long double) &lt;=3D sizeof=
(long long double)</span>. This would enable compilers to use <span style=
=3D"font-family:courier new,monospace">long double </span>for the <a href=
=3D"https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision=
_Format" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.c=
om/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtended_precision%23x86=
_Extended_Precision_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNHQ3pk61cM5dzL=
hGbs_EfrObHjFAw';return true;" onclick=3D"this.href=3D'https://www.google.c=
om/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtended_precision%23x86=
_Extended_Precision_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNHQ3pk61cM5dzL=
hGbs_EfrObHjFAw';return true;">x86 extended precision format</a> while usin=
g <span style=3D"font-family:courier new,monospace">long long double</span>=
 for the <a href=3D"https://en.wikipedia.org/wiki/Quadruple-precision_float=
ing-point_format" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FQuadruple-preci=
sion_floating-point_format\46sa\75D\46sntz\0751\46usg\75AFQjCNG-kikLjGOnSCM=
0zxiYPNfLUFtyPg';return true;" onclick=3D"this.href=3D'https://www.google.c=
om/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FQuadruple-precision_floa=
ting-point_format\46sa\75D\46sntz\0751\46usg\75AFQjCNG-kikLjGOnSCM0zxiYPNfL=
UFtyPg';return true;">quadruple-precision floating point format</a> on syst=
ems on which both are supported.<br><br>Anyone else think this is a good id=
ea?<br></div></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_19_1765880795.1412470000479--

.

--Apple-Mail=_5F9A5866-B6D1-4F7A-AA95-4758E0882AE1
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-05, at 6:28 AM, Ivo <ivo.doko@gmail.com> wrote:

> Since GCC uses quadruple-precision for long double on my computer which has a processor based on the x86 architecture, my computer supports both extended precision and quadruple-precision.

Tell us more about this microprocessor, the flags you passed to GCC, and your process for determining that long double is quadruple precision. Note that sizeof(long double)==16 using extended double precision as well.

The method of naming types in <cstdint> is superior to the hack of tacking on more longs, so let's adapt that to FP instead. For a name as long as long long double, floatmin_128t would be less typing too.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_5F9A5866-B6D1-4F7A-AA95-4758E0882AE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;05, at 6:28 AM, Ivo &lt;<a href=3D"mailto:ivo.doko@gmail.com=
">ivo.doko@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-new=
line"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; displa=
y: inline !important;">Since GCC uses quadruple-precision for<span class=3D=
"Apple-converted-space">&nbsp;</span></span><span style=3D"font-size: 12px;=
 font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; font-family: 'courier new', mon=
ospace;">long double</span><span style=3D"font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant: normal; font-weight: normal; lett=
er-spacing: normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: in=
line !important;"><span class=3D"Apple-converted-space">&nbsp;</span>on my =
computer which has a processor based on the x86 architecture, my computer s=
upports both extended precision and quadruple-precision.</span></blockquote=
></div><br><div>Tell us more about this microprocessor, the flags you passe=
d to GCC, and your process for determining that long double is quadruple pr=
ecision. Note that <font face=3D"Courier">sizeof(long double)=3D=3D16</font=
> using extended double precision as well.</div><div><br></div><div>The met=
hod of naming types in <font face=3D"Courier">&lt;cstdint&gt;</font> is sup=
erior to the hack of tacking on more <font face=3D"Courier">long</font>s, s=
o let&rsquo;s adapt that to FP instead. For a name as long as <font face=3D=
"Courier">long long double</font>, <font face=3D"Courier">floatmin_128t</fo=
nt> would be less typing too.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_5F9A5866-B6D1-4F7A-AA95-4758E0882AE1--

.

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

On Sunday, 5 October 2014 02:46:40 UTC+2, Sean Middleditch wrote:
>
> Can we maybe shy away from adding yet more imprecise and confusing names=
=20
> for types and aim for direct and meaningful names? float128_t, float64_t,=
=20
> etc. make more sense and parellel int8_t, uint16_t, and so on.
>
> They can be optional for platforms that don't support them. Libraries can=
=20
> make use of SG10 feature detection support for selecting "big enough" typ=
es=20
> if for some reason they think they _could_ use extended precision but don=
't=20
> require it (is there any such reasonable use case) or better yet use=20
> templates to let the user select based on target hardware.
>

That is, indeed, an even better idea!

As for the extended (80 bit) precision, it makes sense to use that in=20
certain situations, e.g. if you want a floating-point type big enough to be=
=20
able to represent all (signed and unsigned) 64-bit integer values exactly,=
=20
but would like to conserve memory (10 bytes is considerably less than 16).

Besides, maybe you just need a floating-point type more precise than double=
=20
but not taking up as much memory as quadruple precision floating point.=20
*shrug*

Of course, there's a possibility that I have no idea what I'm talking about=
=20
and extended precision floating-point values are aligned as quadruple=20
precision floating-point values in memory, taking up 16 bytes (especially=
=20
taking into consideration the following post), in which case please=20
disregard most of the things I've said.


On Sunday, 5 October 2014 04:05:10 UTC+2, David Krauss wrote:
>
> Note that sizeof(long double)=3D=3D16 using extended double precision as =
well.
>

Well then... you live and learn, I guess. *facepalm* I will report more=20
tomorrow, right now I don't have the time, sorry.=20
=20

> The method of naming types in <cstdint> is superior to the hack of=20
> tacking on more longs, so let=E2=80=99s adapt that to FP instead. For a n=
ame as=20
> long as long long double, floatmin_128t would be less typing too.
>
=20
I do completely agree with this.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Sunday, 5 October 2014 02:46:40 UTC+2, Sean Middleditch=
  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">Can
 we maybe shy away from adding yet more imprecise and confusing names=20
for types and aim for direct and meaningful names? float128_t,=20
float64_t, etc. make more sense and parellel int8_t, uint16_t, and so=20
on.<div><br></div><div>They can be optional for platforms that don't=20
support them. Libraries can make use of SG10 feature detection support=20
for selecting "big enough" types if for some reason they think they=20
_could_ use extended precision but don't require it (is there any such=20
reasonable use case) or better yet use templates to let the user select=20
based on target hardware.</div></div></blockquote><div><br>That is, indeed,=
 an even better idea!<br><br>As
 for the extended (80 bit) precision, it makes sense to use that in=20
certain situations, e.g. if you want a floating-point type big enough to
 be able to represent all (signed and unsigned) 64-bit integer values=20
exactly, but would like to conserve memory (10 bytes is considerably=20
less than 16).<br><br>Besides, maybe you just need a floating-point type mo=
re precise than <span style=3D"font-family: courier new,monospace;">double<=
/span> but not taking up as much memory as quadruple precision floating poi=
nt. *shrug*<br><br>Of course, there's a possibility that I have no idea wha=
t I'm talking about and extended precision floating-point values are aligne=
d as quadruple precision floating-point values in memory, taking up 16 byte=
s (especially taking into consideration the following post), in which case =
please disregard most of the things I've said.<br></div><br><br>On Sunday, =
5 October 2014 04:05:10 UTC+2, David Krauss  wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div>Note that <fo=
nt face=3D"Courier">sizeof(long double)=3D=3D16</font> using extended doubl=
e precision as well.</div></div></blockquote><div><br>Well then... you live=
 and learn, I guess. *facepalm* I will report more tomorrow, right now I do=
n't have the time, sorry. <br></div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div></div><div>=
The method of naming types in <font face=3D"Courier">&lt;cstdint&gt;</font>=
 is superior to the hack of tacking on more <font face=3D"Courier">long</fo=
nt>s, so let=E2=80=99s adapt that to FP instead. For a name as long as <fon=
t face=3D"Courier">long long double</font>, <font face=3D"Courier">floatmin=
_128t</font> would be less typing too.</div></div></blockquote><div>&nbsp;<=
br>I do completely agree with this.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9118_1170261168.1412475610947--

.

On Saturday 04 October 2014 19:20:10 Ivo wrote:
> Of course, there's a possibility that I have no idea what I'm talking about
> and extended precision floating-point values are aligned as quadruple
> precision floating-point values in memory, taking up 16 bytes (especially
> taking into consideration the following post), in which case please
> disregard most of the things I've said.

You're correct. 80-bit extended precision floating point types are aligned to
16 bytes because that's the most efficient possibility (it's a multiple of
alignof(void*)).

You should also have inspected the assembly GCC generates for __float128. It's
indeed different from 80-bit extended float. However, none of the operations are
supported by the processor. In other words, __float128 is no different from a
C++ class implementing 128-bit quadruple precision floating point.

I'm not saying those machines won't exist (or don't right now). But do we need
to go into this?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_638_431182458.1412532060415
Content-Type: text/plain; charset=UTF-8

On Sunday, 5 October 2014 05:27:46 UTC+2, Thiago Macieira wrote:
>
> You're correct. 80-bit extended precision floating point types are aligned
> to
> 16 bytes because that's the most efficient possibility (it's a multiple of
> alignof(void*)).
>
> You should also have inspected the assembly GCC generates for __float128.
> It's
> indeed different from 80-bit extended float. However, none of the
> operations are
> supported by the processor. In other words, __float128 is no different
> from a
> C++ class implementing 128-bit quadruple precision floating point.
>
> I'm not saying those machines won't exist (or don't right now). But do we
> need
> to go into this?
>

You're absolutely right. You'd think in all the years of relevant education
I've gone through this little detail about the alignment of 80-bit floating
point variables might have cropped up, but it apparently did not. Now I
feel embarrassed.

Anyway, so my original idea is useless, but what about <cstdint>-like type
names for floating-point variables? That might be handy.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Sunday, 5 October 2014 05:27:46 UTC+2, Thiago Macieira =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You're correct. 80-bit =
extended precision floating point types are aligned to=20
<br>16 bytes because that's the most efficient possibility (it's a multiple=
 of=20
<br>alignof(void*)).
<br>
<br>You should also have inspected the assembly GCC generates for __float12=
8. It's=20
<br>indeed different from 80-bit extended float. However, none of the opera=
tions are=20
<br>supported by the processor. In other words, __float128 is no different =
from a=20
<br>C++ class implementing 128-bit quadruple precision floating point.
<br>
<br>I'm not saying those machines won't exist (or don't right now). But do =
we need=20
<br>to go into this?
<br></blockquote><div><br>You're absolutely right. You'd think in all the y=
ears of relevant education I've gone through this little detail about the a=
lignment of 80-bit floating point variables might have cropped up, but it a=
pparently did not. Now I feel embarrassed.<br><br>Anyway, so my original id=
ea is useless, but what about <span style=3D"font-family: courier new,monos=
pace;">&lt;cstdint&gt;</span>-like type names for floating-point variables?=
 That might be handy.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_638_431182458.1412532060415--

.

2014-10-05 20:01 GMT+02:00 Ivo <ivo.doko@gmail.com>:
> Anyway, so my original idea is useless, but what about <cstdint>-like type
> names for floating-point variables? That might be handy.

Do you mean something like this existing proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf

?

The authors were also careful enough to inform the C committee for a
similar request:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1703.pdf

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-10-06, at 2:06 AM, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wro=
te:

> Do you mean something like this existing proposal:
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf

First time I've seen a personal copyright stamp on anything relating to int=
ernational standardization.

Aside from that instant procedural disqualification, how were these proposa=
ls received?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-10-06, at 2:20 AM, David Krauss <potswa@gmail.com> wrote:

> Aside from that instant procedural disqualification, how were these propo=
sals received?

Both papers are mentioned in the meeting minutes. It looks like SG6 (C++) d=
eferred their decision to the C committee, and the C committee recorded ant=
icipating the paper (this seems anachronistic, since it was registered mont=
hs earlier) and assigning a "champion" but did not record processing it at =
the next meeting.

Looks like it slipped through the cracks.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

On Sunday, 5 October 2014 20:06:21 UTC+2, Daniel Kr=C3=BCgler wrote:
>
> Do you mean something like this existing proposal:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf=20
>
> ?=20
>


Pretty much, yes.

However, I am also confused by the personal copyright stamp.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Sunday, 5 October 2014 20:06:21 UTC+2, Daniel Kr=C3=BCg=
ler  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Do you mean somethi=
ng like this existing proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n362=
6.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2013%2Fn3626.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGvp0K-VEdlZHWJ4tdkaTE=
dwiAm_g';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013=
%2Fn3626.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGvp0K-VEdlZHWJ4tdkaTEdwiAm_=
g';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/20=
13/<wbr>n3626.pdf</a>
<br>
<br>?
<br></blockquote><div><br><br>Pretty much, yes.<br><br>However, I am also c=
onfused by the personal copyright stamp.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2557_1096848095.1412536177559--

.

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

On Sat, Oct 4, 2014 at 12:38 PM, Myriachan <myriachan@gmail.com> wrote:

> On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:
>>
>> I have mulled over this for a while now. Since long long and unsigned
>> long long are a part of the standard now, why not long long double?
>>
>> Essentially, it would be a floating-point type such that sizeof(long
>> double) <= sizeof(long long double). This would enable compilers to use long
>> double for the x86 extended precision format
>> <https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format>
>> while using long long double for the quadruple-precision floating point
>> format
>> <https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>
>> on systems on which both are supported.
>>
>> Anyone else think this is a good idea?
>>
>
> And so Visual C++ would be forced to have to implement *another* type
> that is physically but not semantically identical to double?
>
> Maybe instead the rules should just be modified to be like integers, and
> allow implementations to define "extended floating point types" much like
> how implementations can have extended integer types, like GCC's __int128.
>

__int128 is *not* an extended integer type; it doesn't follow any of the
rules for extended integer types. (Overly large literals don't have that
type, for instance.) And it can't be made an extended integer type without
a massive ABI break, because that would require changing intmax_t to be
__int128. Instead, __int128 is simply a conforming extension unrelated to
extended integer types.

As far as I can see, we gained no benefit from adding extended integer
types to the standard. We should be cautious about adding extended floating
point types in case they suffer the same fate.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Oct 4, 2014 at 12:38 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">I have mulled over this for a whil=
e now. Since <span style=3D"font-family:courier new,monospace">long long</s=
pan> and <span style=3D"font-family:courier new,monospace">unsigned long lo=
ng</span> are a part of the standard now, why not <span style=3D"font-famil=
y:courier new,monospace">long long double</span>?<br><br>Essentially, it wo=
uld be a floating-point type such that <span style=3D"font-family:courier n=
ew,monospace">sizeof(long double) &lt;=3D sizeof(long long double)</span>. =
This would enable compilers to use <span style=3D"font-family:courier new,m=
onospace">long double </span>for the <a href=3D"https://en.wikipedia.org/wi=
ki/Extended_precision#x86_Extended_Precision_Format" target=3D"_blank">x86 =
extended precision format</a> while using <span style=3D"font-family:courie=
r new,monospace">long long double</span> for the <a href=3D"https://en.wiki=
pedia.org/wiki/Quadruple-precision_floating-point_format" target=3D"_blank"=
>quadruple-precision floating point format</a> on systems on which both are=
 supported.<br><br>Anyone else think this is a good idea?<br></div></blockq=
uote></span><div><br>And so Visual C++ would be forced to have to implement=
 <i>another</i> type that is physically but not semantically identical to <=
span style=3D"font-family:courier new,monospace">double</span>?<br><br>Mayb=
e instead the rules should just be modified to be like integers, and allow =
implementations to define &quot;extended floating point types&quot; much li=
ke how implementations can have extended integer types, like GCC&#39;s <spa=
n style=3D"font-family:courier new,monospace">__int128</span>.</div></div><=
/blockquote><div><br></div><div>__int128 is *not* an extended integer type;=
 it doesn&#39;t follow any of the rules for extended integer types. (Overly=
 large literals don&#39;t have that type, for instance.) And it can&#39;t b=
e made an extended integer type without a massive ABI break, because that w=
ould require changing intmax_t to be __int128. Instead, __int128 is simply =
a conforming extension unrelated to extended integer types.</div><div><br><=
/div><div>As far as I can see, we gained no benefit from adding extended in=
teger types to the standard. We should be cautious about adding extended fl=
oating point types in case they suffer the same fate.=C2=A0</div></div></di=
v></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec52c5e0ba438a80504b247be--

.

2014-10-05 21:09 GMT+02:00 Ivo <ivo.doko@gmail.com>:
> On Sunday, 5 October 2014 20:06:21 UTC+2, Daniel Kr=FCgler wrote:
>>
>> Do you mean something like this existing proposal:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf
>>
>> ?
>
> Pretty much, yes.
>
> However, I am also confused by the personal copyright stamp.

I don't think that it helps much, if participants of this forum try to
understand the reason for this copyright. I strongly suggest to
contact the author (as required, there always needs to be a contact
address) and possibly bring the author's attention to this discussion.

- Daniel

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

2014-10-05 21:50 GMT+02:00 Richard Smith <richard@metafoo.co.uk>:
> __int128 is *not* an extended integer type; it doesn't follow any of the
> rules for extended integer types. (Overly large literals don't have that
> type, for instance.) And it can't be made an extended integer type without a
> massive ABI break, because that would require changing intmax_t to be
> __int128. Instead, __int128 is simply a conforming extension unrelated to
> extended integer types.
>
> As far as I can see, we gained no benefit from adding extended integer types
> to the standard. We should be cautious about adding extended floating point
> types in case they suffer the same fate.

Your opinion on this matter sounds like bad news to me - I always had
believed that a conforming implementation could declare its __int128
as extended integer type.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sun, Oct 5, 2014 at 1:20 PM, Daniel Kr=C3=BCgler
<daniel.kruegler@gmail.com> wrote:
>
> Your opinion on this matter sounds like bad news to me - I always had
> believed that a conforming implementation could declare its __int128
> as extended integer type.

Oh, an implementation can use a 128-bit int as an extended integer
type. It's just that GCC, Clang, VC__, and so on choose not to for the
reasons that Richard outlined (ABI breakages).

Personally I see this more of intmax_t having been a terrible idea. We
needed less implementation-defined sizes for things, not more.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

I think the definition of intmax_t is what scares people away from creating=
=20
extended integer types.  If intmax_t were defined to be "the most efficient=
=20
type for the target machine and not necessarily the largest" this would=20
allow extended integer types to be defined where available without breaking=
=20
ABI.  For example, if you are compiling for a 32-bit target then a 32-bit=
=20
intmax_t might be the most efficient even though 64-bit or 128-bit integers=
=20
may be available on the machine.  Same goes for a 64-bit target machine=20
where the most efficient intmax_t would be 64-bit.  To me, this just makes=
=20
more sense.

As for the copyright message, I can understand listing the copyright if the=
=20
code in the draft is directly from Boost.  But since this is a standards=20
proposal (and the code is very trivial to implement) I think there should=
=20
at least be some kind of fair use clause inserted into the draft by each of=
=20
the authors even if fair use is implied by the license...


On Sunday, October 5, 2014 3:03:09 PM UTC-7, Sean Middleditch wrote:
>
> On Sun, Oct 5, 2014 at 1:20 PM, Daniel Kr=C3=BCgler=20
> <daniel....@gmail.com <javascript:>> wrote:=20
> >=20
> > Your opinion on this matter sounds like bad news to me - I always had=
=20
> > believed that a conforming implementation could declare its __int128=20
> > as extended integer type.=20
>
> Oh, an implementation can use a 128-bit int as an extended integer=20
> type. It's just that GCC, Clang, VC__, and so on choose not to for the=20
> reasons that Richard outlined (ABI breakages).=20
>
> Personally I see this more of intmax_t having been a terrible idea. We=20
> needed less implementation-defined sizes for things, not more.=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">I think the definition of intmax_t is what scares people a=
way from creating extended integer types. &nbsp;If intmax_t were defined to=
 be "the most efficient type for the target machine and not necessarily the=
 largest" this would allow extended integer types to be defined where avail=
able without breaking ABI. &nbsp;For example, if you are compiling for a 32=
-bit target then a 32-bit intmax_t might be the most efficient even though =
64-bit or 128-bit integers may be available on the machine. &nbsp;Same goes=
 for a 64-bit target machine where the most efficient intmax_t would be 64-=
bit. &nbsp;To me, this just makes more sense.<br><br>As for the copyright m=
essage, I can understand listing the copyright if the code in the draft is =
directly from Boost. &nbsp;But since this is a standards proposal (and the =
code is very trivial to implement) I think there should at least be some ki=
nd of fair use clause inserted into the draft by each of the authors even i=
f fair use is implied by the license...<br><br><br>On Sunday, October 5, 20=
14 3:03:09 PM UTC-7, Sean Middleditch wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">On Sun, Oct 5, 2014 at 1:20 PM, Daniel Kr=C3=BCgler
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
suP-8tXADcgJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">daniel....@gmail.com</a>&gt; w=
rote:
<br>&gt;
<br>&gt; Your opinion on this matter sounds like bad news to me - I always =
had
<br>&gt; believed that a conforming implementation could declare its __int1=
28
<br>&gt; as extended integer type.
<br>
<br>Oh, an implementation can use a 128-bit int as an extended integer
<br>type. It's just that GCC, Clang, VC__, and so on choose not to for the
<br>reasons that Richard outlined (ABI breakages).
<br>
<br>Personally I see this more of intmax_t having been a terrible idea. We
<br>needed less implementation-defined sizes for things, not more.
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_10_956027491.1412548901352--

.

------=_Part_8553_781727461.1412548985914
Content-Type: text/plain; charset=UTF-8

On Sunday, October 5, 2014 12:50:37 PM UTC-7, Richard Smith wrote:
>
> On Sat, Oct 4, 2014 at 12:38 PM, Myriachan <myri...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:
>>>
>>> I have mulled over this for a while now. Since long long and unsigned
>>> long long are a part of the standard now, why not long long double?
>>>
>>> Essentially, it would be a floating-point type such that sizeof(long
>>> double) <= sizeof(long long double). This would enable compilers to use long
>>> double for the x86 extended precision format
>>> <https://en.wikipedia.org/wiki/Extended_precision#x86_Extended_Precision_Format>
>>> while using long long double for the quadruple-precision floating point
>>> format
>>> <https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>
>>> on systems on which both are supported.
>>>
>>> Anyone else think this is a good idea?
>>>
>>
>> And so Visual C++ would be forced to have to implement *another* type
>> that is physically but not semantically identical to double?
>>
>> Maybe instead the rules should just be modified to be like integers, and
>> allow implementations to define "extended floating point types" much like
>> how implementations can have extended integer types, like GCC's __int128.
>>
>
> __int128 is *not* an extended integer type; it doesn't follow any of the
> rules for extended integer types. (Overly large literals don't have that
> type, for instance.) And it can't be made an extended integer type without
> a massive ABI break, because that would require changing intmax_t to be
> __int128. Instead, __int128 is simply a conforming extension unrelated to
> extended integer types.
>
> As far as I can see, we gained no benefit from adding extended integer
> types to the standard. We should be cautious about adding extended floating
> point types in case they suffer the same fate.
>

It seems to me like that definition of [u]intmax_t ought to be modified,
then, to allow uintmax_t to optionally not include extended integer types.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Sunday, October 5, 2014 12:50:37 PM UTC-7, Richard Smit=
h 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"><div>=
<div class=3D"gmail_quote">On Sat, Oct 4, 2014 at 12:38 PM, Myriachan <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"lRpJnz-0DyMJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gmail.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"ltr"><span=
>On Friday, October 3, 2014 12:32:52 PM UTC-7, Ivo wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">I have mulled over this for a while=
 now. Since <span style=3D"font-family:courier new,monospace">long long</sp=
an> and <span style=3D"font-family:courier new,monospace">unsigned long lon=
g</span> are a part of the standard now, why not <span style=3D"font-family=
:courier new,monospace">long long double</span>?<br><br>Essentially, it wou=
ld be a floating-point type such that <span style=3D"font-family:courier ne=
w,monospace">sizeof(long double) &lt;=3D sizeof(long long double)</span>. T=
his would enable compilers to use <span style=3D"font-family:courier new,mo=
nospace">long double </span>for the <a href=3D"https://en.wikipedia.org/wik=
i/Extended_precision#x86_Extended_Precision_Format" target=3D"_blank" onmou=
sedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fen.wiki=
pedia.org%2Fwiki%2FExtended_precision%23x86_Extended_Precision_Format\46sa\=
75D\46sntz\0751\46usg\75AFQjCNHQ3pk61cM5dzLhGbs_EfrObHjFAw';return true;" o=
nclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fen.wiki=
pedia.org%2Fwiki%2FExtended_precision%23x86_Extended_Precision_Format\46sa\=
75D\46sntz\0751\46usg\75AFQjCNHQ3pk61cM5dzLhGbs_EfrObHjFAw';return true;">x=
86 extended precision format</a> while using <span style=3D"font-family:cou=
rier new,monospace">long long double</span> for the <a href=3D"https://en.w=
ikipedia.org/wiki/Quadruple-precision_floating-point_format" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%=
2Fen.wikipedia.org%2Fwiki%2FQuadruple-precision_floating-point_format\46sa\=
75D\46sntz\0751\46usg\75AFQjCNG-kikLjGOnSCM0zxiYPNfLUFtyPg';return true;" o=
nclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fen.wiki=
pedia.org%2Fwiki%2FQuadruple-precision_floating-point_format\46sa\75D\46snt=
z\0751\46usg\75AFQjCNG-kikLjGOnSCM0zxiYPNfLUFtyPg';return true;">quadruple-=
precision floating point format</a> on systems on which both are supported.=
<br><br>Anyone else think this is a good idea?<br></div></blockquote></span=
><div><br>And so Visual C++ would be forced to have to implement <i>another=
</i> type that is physically but not semantically identical to <span style=
=3D"font-family:courier new,monospace">double</span>?<br><br>Maybe instead =
the rules should just be modified to be like integers, and allow implementa=
tions to define "extended floating point types" much like how implementatio=
ns can have extended integer types, like GCC's <span style=3D"font-family:c=
ourier new,monospace">__int128</span>.</div></div></blockquote><div><br></d=
iv><div>__int128 is *not* an extended integer type; it doesn't follow any o=
f the rules for extended integer types. (Overly large literals don't have t=
hat type, for instance.) And it can't be made an extended integer type with=
out a massive ABI break, because that would require changing intmax_t to be=
 __int128. Instead, __int128 is simply a conforming extension unrelated to =
extended integer types.</div><div><br></div><div>As far as I can see, we ga=
ined no benefit from adding extended integer types to the standard. We shou=
ld be cautious about adding extended floating point types in case they suff=
er the same fate.&nbsp;</div></div></div></div></blockquote><div><br>It see=
ms to me like that definition of [u]intmax_t ought to be modified, then, to=
 allow uintmax_t to optionally not include extended integer types.<br></div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8553_781727461.1412548985914--

.

--Apple-Mail=_670DD114-369D-4E46-B4C5-6028A1057A83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-06, at 3:50 AM, Richard Smith <richard@metafoo.co.uk> wrote:

> As far as I can see, we gained no benefit from adding extended integer ty=
pes to the standard. We should be cautious about adding extended floating p=
oint types in case they suffer the same fate.=20

Is there any other problem besides intmax_t? Although, this needs to be fix=
ed either in C or the ABI, not in C++. (Deprecating and removing the ABI de=
finition is necessary if users will benefit from the fixed feature.)

Also, floatmax_t could just as easily be removed from the proposal or adjus=
ted too. This would probably happen automatically if C had an open DR on th=
e subject.


On 2014-10-06, at 4:15 AM, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wro=
te:

> I don't think that it helps much, if participants of this forum try to
> understand the reason for this copyright.


The reason isn't very interesting, but it's a complete explanation for why =
the proposal might have hit a dead end. I'm not double-checking the ISO rul=
es right now, but it wouldn't be surprising if the WG were expressly forbid=
den from considering it, because its time is wasted and it only takes on un=
necessary risks by handling material that it cannot adopt. In principle it =
works the same with any standards body. If not expressly forbidden, they mi=
ght just decide it's a hot potato.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_670DD114-369D-4E46-B4C5-6028A1057A83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;06, at 3:50 AM, Richard Smith &lt;<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><span style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;">As far as I can see, we gained no be=
nefit from adding extended integer types to the standard. We should be caut=
ious about adding extended floating point types in case they suffer the sam=
e fate.&nbsp;</span></blockquote></div><br><div>Is there any other problem =
besides <font face=3D"Courier">intmax_t</font>? Although, this needs to be =
fixed either in C or the ABI, not in C++. (Deprecating and removing the ABI=
 definition is necessary if users will benefit from the fixed feature.)</di=
v><div><br></div><div>Also, <font face=3D"Courier">floatmax_t</font> could =
just as easily be removed from the proposal or adjusted too. This would pro=
bably happen automatically if C had an open DR on the subject.</div><div><b=
r></div><div><br></div><div><div>On 2014&ndash;10&ndash;06, at 4:15 AM, Dan=
iel Kr=FCgler &lt;<a href=3D"mailto:daniel.kruegler@gmail.com">daniel.krueg=
ler@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><=
blockquote type=3D"cite">I don't think that it helps much, if participants =
of this forum try to<br>understand the reason for this copyright.</blockquo=
te></div><div><br></div><div>The reason isn&rsquo;t very interesting, but i=
t&rsquo;s a complete explanation for why the proposal might have hit a dead=
 end. I&rsquo;m not double-checking the ISO rules right now, but it wouldn&=
rsquo;t be surprising if the WG were expressly forbidden from considering i=
t, because its time is wasted and it only takes on unnecessary risks by han=
dling material that it cannot adopt. In principle it works the same with an=
y standards body. If not expressly forbidden, they might just decide it&rsq=
uo;s a hot potato.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_670DD114-369D-4E46-B4C5-6028A1057A83--

.

--089e013a1e1203a40c0504b63ad5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 5, 2014 at 4:59 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-10-06, at 3:50 AM, Richard Smith <richard@metafoo.co.uk> wrote:
>
> As far as I can see, we gained no benefit from adding extended integer
> types to the standard. We should be cautious about adding extended floati=
ng
> point types in case they suffer the same fate.
>
>
> Is there any other problem besides intmax_t? Although, this needs to be
> fixed either in C or the ABI, not in C++. (Deprecating and removing the A=
BI
> definition is necessary if users will benefit from the fixed feature.)
>
> Also, floatmax_t could just as easily be removed from the proposal or
> adjusted too. This would probably happen automatically if C had an open D=
R
> on the subject.
>
>
> On 2014-10-06, at 4:15 AM, Daniel Kr=FCgler <daniel.kruegler@gmail.com>
> wrote:
>
> I don't think that it helps much, if participants of this forum try to
> understand the reason for this copyright.
>
>
> The reason isn't very interesting, but it's a complete explanation for wh=
y
> the proposal might have hit a dead end. I'm not double-checking the ISO
> rules right now, but it wouldn't be surprising if the WG were expressly
> forbidden from considering it, because its time is wasted and it only tak=
es
> on unnecessary risks by handling material that it cannot adopt. In
> principle it works the same with any standards body. If not expressly
> forbidden, they might just decide it's a hot potato.
>

Since I've been participating, I haven't seen the committee worry about the
presence or absence of an explicit copyright or license statement. Everyone
assumes that papers are submitted under the terms of
http://www.iso.org/iso/home/standards_development/resources-for-technical-w=
ork/data-protection-declaration.htm,
which allows ISO to use the content in standards.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e013a1e1203a40c0504b63ad5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Oct 5, 2014 at 4:59 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank" class=3D"cremed">potswa@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><span class=3D""><br><div><div>On 2014&ndash;10&ndash;06, at 3:50 AM, R=
ichard Smith &lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank"=
 class=3D"cremed">richard@metafoo.co.uk</a>&gt; wrote:</div><br><blockquote=
 type=3D"cite"><span style=3D"font-family:Helvetica;font-size:12px;font-sty=
le:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line=
-height:normal;text-align:start;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px;float:none;display:inline!important">As far as=
 I can see, we gained no benefit from adding extended integer types to the =
standard. We should be cautious about adding extended floating point types =
in case they suffer the same fate.&nbsp;</span></blockquote></div><br></spa=
n><div>Is there any other problem besides <font face=3D"Courier">intmax_t</=
font>? Although, this needs to be fixed either in C or the ABI, not in C++.=
 (Deprecating and removing the ABI definition is necessary if users will be=
nefit from the fixed feature.)</div><div><br></div><div>Also, <font face=3D=
"Courier">floatmax_t</font> could just as easily be removed from the propos=
al or adjusted too. This would probably happen automatically if C had an op=
en DR on the subject.</div><span class=3D""><div><br></div><div><br></div><=
div><div>On 2014&ndash;10&ndash;06, at 4:15 AM, Daniel Kr=FCgler &lt;<a hre=
f=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank" class=3D"cremed">d=
aniel.kruegler@gmail.com</a>&gt; wrote:</div><br><blockquote type=3D"cite">=
I don&#39;t think that it helps much, if participants of this forum try to<=
br>understand the reason for this copyright.</blockquote></div><div><br></d=
iv></span><div>The reason isn&rsquo;t very interesting, but it&rsquo;s a co=
mplete explanation for why the proposal might have hit a dead end. I&rsquo;=
m not double-checking the ISO rules right now, but it wouldn&rsquo;t be sur=
prising if the WG were expressly forbidden from considering it, because its=
 time is wasted and it only takes on unnecessary risks by handling material=
 that it cannot adopt. In principle it works the same with any standards bo=
dy. If not expressly forbidden, they might just decide it&rsquo;s a hot pot=
ato.</div><div></div></div></blockquote></div><br></div><div class=3D"gmail=
_extra">Since I&#39;ve been participating, I haven&#39;t seen the committee=
 worry about the presence or absence of an explicit copyright or license st=
atement. Everyone assumes that papers are submitted under the terms of&nbsp=
;<a href=3D"http://www.iso.org/iso/home/standards_development/resources-for=
-technical-work/data-protection-declaration.htm">http://www.iso.org/iso/hom=
e/standards_development/resources-for-technical-work/data-protection-declar=
ation.htm</a>, which allows ISO to use the content in standards.<br></div><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013a1e1203a40c0504b63ad5--

.

--Apple-Mail=_2C6F63F9-9287-414D-99AF-0857EA03DBCB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-06, at 8:32 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future =
Proposals <std-proposals@isocpp.org> wrote:

> Since I've been participating, I haven't seen the committee worry about t=
he presence or absence of an explicit copyright or license statement. Every=
one assumes that papers are submitted under the terms of http://www.iso.org=
/iso/home/standards_development/resources-for-technical-work/data-protectio=
n-declaration.htm, which allows ISO to use the content in standards.

According to the second point there, if a proposal including standardese is=
 copyrighted to someone else, they must also "assist ISO or ISO/IEC in obta=
ining appropriate permission" to use it.

The Boost license is only an open-source license, and it would have at most=
 required an attribution notice to be included in the standard document, an=
d the copyright stamp was most likely included by accident as part of a doc=
ument template intended for documentation or the like. The solution to this=
 problem would have been simply for someone from WG14 to contact the author=
s and get a new submission with the notice removed.

Often, though, when legalities require policy review and involve risks, the=
 easier way out is to drop everything and run. Folks, don't copyright or pa=
tent your submissions.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_2C6F63F9-9287-414D-99AF-0857EA03DBCB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;06, at 8:32 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Fut=
ure Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals=
@isocpp.org</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bl=
ockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">Since I've been participating, I haven't seen the commit=
tee worry about the presence or absence of an explicit copyright or license=
 statement. Everyone assumes that papers are submitted under the terms of&n=
bsp;<a href=3D"http://www.iso.org/iso/home/standards_development/resources-=
for-technical-work/data-protection-declaration.htm">http://www.iso.org/iso/=
home/standards_development/resources-for-technical-work/data-protection-dec=
laration.htm</a>, which allows ISO to use the content in standards.</div></=
div></div></blockquote><br></div><div>According to the second point there, =
if a proposal including standardese is copyrighted to someone else, they mu=
st also &ldquo;assist=20
ISO or ISO/IEC in obtaining appropriate permission&rdquo; to use it.</div><=
div><br></div><div>The Boost license is only an open-source license, and it=
 would have at most required an attribution notice to be included in the st=
andard document, and the copyright stamp was most likely included by accide=
nt as part of a document template intended for documentation or the like. T=
he solution to this problem would have been simply for someone from WG14 to=
 contact the authors and get a new submission with the notice removed.</div=
><div><br></div><div>Often, though, when legalities require policy review a=
nd involve risks, the easier way out is to drop everything and run. Folks, =
don&rsquo;t copyright or patent your submissions.</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_2C6F63F9-9287-414D-99AF-0857EA03DBCB--

.

--089e0158b114aef9fe0504b74a9d
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Oct 5, 2014 at 5:49 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-10-06, at 8:32 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>
> Since I've been participating, I haven't seen the committee worry about
> the presence or absence of an explicit copyright or license statement.
> Everyone assumes that papers are submitted under the terms of
> http://www.iso.org/iso/home/standards_development/resources-for-technical-work/data-protection-declaration.htm,
> which allows ISO to use the content in standards.
>
>
> According to the second point there, if a proposal including standardese
> is copyrighted to someone else, they must also "assist ISO or ISO/IEC in
> obtaining appropriate permission" to use it.
>

Where do you see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf being
copyright to someone other than its authors?


> The Boost license is only an open-source license, and it would have at
> most required an attribution notice to be included in the standard
> document, and the copyright stamp was most likely included by accident as
> part of a document template intended for documentation or the like. The
> solution to this problem would have been simply for someone from WG14 to
> contact the authors and get a new submission with the notice removed.
>
> Often, though, when legalities require policy review and involve risks,
> the easier way out is to drop everything and run. Folks, don't copyright or
> patent your submissions.
>

Writing down the copyright statement hasn't had a significant effect since
the Berne Convention was adopted, and it's not what would scare off the
committee. If we were worried, we'd insist on a specific license in papers,
but we don't. Looking at
http://wiki.edg.com/twiki/bin/view/Wg21bristol/SG6MinutesSpring2013,
there's no mention of copyright or licensing in the discussion of N3626.

Please don't introduce red herrings.

Jeffrey

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0158b114aef9fe0504b74a9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Oct 5, 2014 at 5:49 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank" class=3D"cremed">potswa@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><span class=3D""><br><div><div>On 2014&ndash;10&ndash;06, at 8:32 AM, &=
#39;Jeffrey Yasskin&#39; via ISO C++ Standard - Future Proposals &lt;<a hre=
f=3D"mailto:std-proposals@isocpp.org" target=3D"_blank" class=3D"cremed">st=
d-proposals@isocpp.org</a>&gt; wrote:</div><br><blockquote type=3D"cite"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Since =
I&#39;ve been participating, I haven&#39;t seen the committee worry about t=
he presence or absence of an explicit copyright or license statement. Every=
one assumes that papers are submitted under the terms of&nbsp;<a href=3D"ht=
tp://www.iso.org/iso/home/standards_development/resources-for-technical-wor=
k/data-protection-declaration.htm" target=3D"_blank" class=3D"cremed">http:=
//www.iso.org/iso/home/standards_development/resources-for-technical-work/d=
ata-protection-declaration.htm</a>, which allows ISO to use the content in =
standards.</div></div></div></blockquote><br></div></span><div>According to=
 the second point there, if a proposal including standardese is copyrighted=
 to someone else, they must also &ldquo;assist=20
ISO or ISO/IEC in obtaining appropriate permission&rdquo; to use it.</div><=
/div></blockquote><div><br></div><div>Where do you see <a href=3D"http://ww=
w.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf">http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf</a> being copyright to som=
eone other than its authors?</div><div>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div st=
yle=3D"word-wrap:break-word"><div></div><div>The Boost license is only an o=
pen-source license, and it would have at most required an attribution notic=
e to be included in the standard document, and the copyright stamp was most=
 likely included by accident as part of a document template intended for do=
cumentation or the like. The solution to this problem would have been simpl=
y for someone from WG14 to contact the authors and get a new submission wit=
h the notice removed.</div><div><br></div><div>Often, though, when legaliti=
es require policy review and involve risks, the easier way out is to drop e=
verything and run. Folks, don&rsquo;t copyright or patent your submissions.=
</div></div></blockquote><div><br></div><div>Writing down the copyright sta=
tement hasn&#39;t had a significant effect since the Berne Convention was a=
dopted, and it&#39;s not what would scare off the committee. If we were wor=
ried, we&#39;d insist on a specific license in papers, but we don&#39;t. Lo=
oking at&nbsp;<a href=3D"http://wiki.edg.com/twiki/bin/view/Wg21bristol/SG6=
MinutesSpring2013">http://wiki.edg.com/twiki/bin/view/Wg21bristol/SG6Minute=
sSpring2013</a>, there&#39;s no mention of copyright or licensing in the di=
scussion of&nbsp;N3626.</div><div><br></div><div>Please don&#39;t introduce=
 red herrings.</div><div><br></div><div>Jeffrey</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158b114aef9fe0504b74a9d--

.

--Apple-Mail=_594D8B7E-500E-4CF9-842A-E2586B211170
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-06, at 9:49 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future =
Proposals <std-proposals@isocpp.org> wrote:

> On Sun, Oct 5, 2014 at 5:49 PM, David Krauss <potswa@gmail.com> wrote:
> According to the second point there, if a proposal including standardese =
is copyrighted to someone else, they must also "assist ISO or ISO/IEC in ob=
taining appropriate permission" to use it.
>=20
> Where do you see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/=
n3626.pdf being copyright to someone other than its authors?

The authors are "someone else," and they did not include a copyright assign=
ment to ISO.

> Writing down the copyright statement hasn't had a significant effect sinc=
e the Berne Convention was adopted, and it's not what would scare off the c=
ommittee. If we were worried, we'd insist on a specific license in papers, =
but we don't. Looking at http://wiki.edg.com/twiki/bin/view/Wg21bristol/SG6=
MinutesSpring2013, there's no mention of copyright or licensing in the disc=
ussion of N3626.
>=20
> Please don't introduce red herrings.

Is there anything there about N3626 that would indicate it might be forward=
ed to CWG at all?

Putting a copyright notice on a paper serves no purpose other than to notif=
y anyone who would copy its content, especially into another another copyri=
ghted work, to seek permission to do so. I admit not knowing the Berne Conv=
ention or much about international copyright all, but the basic intent of c=
opyrighting contradicts the intent of submitting standardese. Copyrighting =
papers is a Really Bad Idea even if it never scared anyone before.

Maybe an alarm bell rang for someone in WG14, maybe not. Either way, it see=
ms to have slipped through the cracks.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_594D8B7E-500E-4CF9-842A-E2586B211170
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;06, at 9:49 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Fut=
ure Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals=
@isocpp.org</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bl=
ockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">On Sun, Oct 5, 2014 at 5:49 PM, David Krauss <span dir=
=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank" class=3D=
"cremed">potswa@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; borde=
r-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1=
ex; position: static; z-index: auto;"><div style=3D"word-wrap:break-word"><=
div>According to the second point there, if a proposal including standardes=
e is copyrighted to someone else, they must also &ldquo;assist=20
ISO or ISO/IEC in obtaining appropriate permission&rdquo; to use it.</div><=
/div></blockquote><div><br></div><div>Where do you see <a href=3D"http://ww=
w.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf">http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2013/n3626.pdf</a> being copyright to som=
eone other than its authors?</div></div></div></div></blockquote><div><br><=
/div><div>The authors are "someone else,&rdquo; and they did not include a =
copyright assignment to ISO.</div><div><br></div><blockquote type=3D"cite">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: so=
lid; padding-left: 1ex; position: static; z-index: auto;"><div style=3D"wor=
d-wrap:break-word"><div></div><div>Writing down the copyright statement has=
n't had a significant effect since the Berne Convention was adopted, and it=
's not what would scare off the committee. If we were worried, we'd insist =
on a specific license in papers, but we don't. Looking at&nbsp;<a href=3D"h=
ttp://wiki.edg.com/twiki/bin/view/Wg21bristol/SG6MinutesSpring2013">http://=
wiki.edg.com/twiki/bin/view/Wg21bristol/SG6MinutesSpring2013</a>, there's n=
o mention of copyright or licensing in the discussion of&nbsp;N3626.</div><=
/div></blockquote><div><br></div><div>Please don't introduce red herrings.<=
/div></div></div></div></blockquote><br></div><div>Is there anything there =
about N3626 that would indicate it might be forwarded to CWG at all?</div><=
br><div>Putting a copyright notice on a paper serves no purpose other than =
to notify anyone who would copy its content, especially into another anothe=
r copyrighted work, to seek permission to do so. I admit not knowing the Be=
rne Convention or much about international copyright all, but the basic int=
ent of copyrighting contradicts the intent of submitting standardese. Copyr=
ighting papers is a Really Bad Idea even if it never scared anyone before.<=
/div><div><br></div><div>Maybe an alarm bell rang for someone in WG14, mayb=
e not. Either way, it seems to have slipped through the cracks.</div></body=
></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_594D8B7E-500E-4CF9-842A-E2586B211170--

.

--089e01419e5e8998920504b987bc
Content-Type: text/plain; charset=UTF-8

On 5 October 2014 22:27, David Krauss <potswa@gmail.com> wrote:

>
> Putting a copyright notice on a paper serves no purpose other than to
> notify anyone who would copy its content, especially into another another
> copyrighted work, to seek permission to do so. I admit not knowing the
> Berne Convention or much about international copyright all, but the basic
> intent of copyrighting contradicts the intent of submitting standardese.
> Copyrighting papers is a Really Bad Idea even if it never scared anyone
> before.
>

Speculating on legal issues by non-lawyers is a Really Really Bad Idea.


> Maybe an alarm bell rang for someone in WG14, maybe not.
>

Is that comment based on anyone from WG14 stating it, or did you just make
it up?  Have you asked anyone in WG14 about it (since you seem to be so
concerned), or is invented rumor and innuendo better than facts?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On 5 October 2014 22:27, David Krauss <span dir=3D"ltr">&l=
t;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><d=
iv><span class=3D""><div>Putting a copyright notice on a paper serves no pu=
rpose other than to notify anyone who would copy its content, especially in=
to another another copyrighted work, to seek permission to do so. I admit n=
ot knowing the Berne Convention or much about international copyright all, =
but the basic intent of copyrighting contradicts the intent of submitting s=
tandardese. Copyrighting papers is a Really Bad Idea even if it never scare=
d anyone before.<br></div></span></div></div></blockquote><div><br></div><d=
iv>Speculating on legal issues by non-lawyers is a Really Really Bad Idea.<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><div><span class=3D""><div></div></span></div><div>Maybe an a=
larm bell rang for someone in WG14, maybe not.<br></div></div></blockquote>=
<div><br></div><div>Is that comment based on anyone from WG14 stating it, o=
r did you just make it up?=C2=A0 Have you asked anyone in WG14 about it (si=
nce you seem to be so concerned), or is invented rumor and innuendo better =
than facts?</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;m=
ailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evi=
loverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01419e5e8998920504b987bc--

.

--Apple-Mail=_8DA5DD49-77F4-4F02-805B-1C9DE16796D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-06, at 12:28 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> Speculating on legal issues by non-lawyers is a Really Really Bad Idea.

What part of this is legal speculation? I'm speculating on what might have =
happened to the paper, but not on legal issues.

The notion that accepting a copyrighted paper is OK is legal speculation. J=
effrey already cited the policy that says it's not. The downside to copyrig=
hting something you wish to be adopted and published by someone else should=
 be obvious.

> Is that comment based on anyone from WG14 stating it, or did you just mak=
e it up?  Have you asked anyone in WG14 about it (since you seem to be so c=
oncerned), or is invented rumor and innuendo better than facts?


I wouldn't consider anything I said to be innuendo or rumor. Someone should=
 ask Jim Thomas or the authors of the paper what happened to it.

I took the time to search the public records, but I'm not particularly conc=
erned with this proposal. If I contacted them, I would feel too personally =
responsible for further followups. If someone else asks, though, it would b=
e nice if they reported back in this thread, since it'll probably turn up i=
n Google results for WG14 N1703 or WG21 N3626.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_8DA5DD49-77F4-4F02-805B-1C9DE16796D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;06, at 12:28 PM, Nevin Liber &lt;<a href=3D"mailto:nevin@evi=
loverlord.com">nevin@eviloverlord.com</a>&gt; wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>Speculating on legal issu=
es by non-lawyers is a Really Really Bad Idea.</div></div></div></div></blo=
ckquote><div><br></div><div>What part of this is legal speculation? I&rsquo=
;m speculating on what might have happened to the paper, but not on legal i=
ssues.</div><div><br></div><div>The notion that accepting a copyrighted pap=
er is OK is legal speculation. Jeffrey already cited the policy that says i=
t&rsquo;s not. The downside to copyrighting something you wish to be adopte=
d and published by someone else should be obvious.</div><div><br></div><blo=
ckquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204);=
 border-left-style: solid; padding-left: 1ex; position: static; z-index: au=
to;"><div style=3D"word-wrap:break-word"><div><span class=3D""><div></div><=
/span></div></div></blockquote><div>Is that comment based on anyone from WG=
14 stating it, or did you just make it up?&nbsp; Have you asked anyone in W=
G14 about it (since you seem to be so concerned), or is invented rumor and =
innuendo better than facts?</div></div></div></div></blockquote></div><div>=
<br></div><div>I wouldn&rsquo;t consider anything I said to be innuendo or =
rumor. Someone should ask Jim Thomas or the authors of the paper what happe=
ned to it.</div><div><br></div><div>I took the time to search the public re=
cords, but I&rsquo;m not particularly concerned with this proposal. If I co=
ntacted them, I would feel too personally responsible for further followups=
.. If someone else asks, though, it would be nice if they reported back in t=
his thread, since it&rsquo;ll probably turn up in Google results for WG14 N=
1703 or WG21 N3626.</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_8DA5DD49-77F4-4F02-805B-1C9DE16796D0--

.

2014-10-06 0:03 GMT+02:00 Sean Middleditch <sean@middleditch.us>:
> On Sun, Oct 5, 2014 at 1:20 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>>
>> Your opinion on this matter sounds like bad news to me - I always had
>> believed that a conforming implementation could declare its __int128
>> as extended integer type.
>
> Oh, an implementation can use a 128-bit int as an extended integer
> type. It's just that GCC, Clang, VC__, and so on choose not to for the
> reasons that Richard outlined (ABI breakages).

I understand that. But if Richard tells us that adding such types is
controversial, it is a good idea to carefully listen to him. It
doesn't help much the C++ community, if the standard adds wording that
gives implementations freedom to add types, if this freedom won't be
used in realistic implementations. I'm very much interested in the
specific reasons for this resistance, because if there is already
resistance to provide extended integer, there presumably is even more
for extended floating point types. At the worst that would only add
complexity to the standard without providing benefit to the user of
the standard.

> Personally I see this more of intmax_t having been a terrible idea. We
> needed less implementation-defined sizes for things, not more.

I doubt that reducing implementation-defined sizes is acceptable given
that several compilers for embedded systems exist (where for example
CHAR_BIT may be much larger than 8) - no-one is intending to ban them
for good reasons.

I don't understand the specific controversity of intmax_t: Programmers
do have already the ability to compile-time-inspect a large number of
the compile-time environment. I guess the actual reason is that there
are (C) function signatures that depend on that type specifically. I
wonder how the C committee reacts on the proposal and how it solves
these kinds of problems, because it seems to occur much more here. If
I understand Richard correctly, just adding additional overloads to
existing ones (such as abs) wouldn't cause so much resistance. Is that
correct?

- Daniel

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Mon, Oct 6, 2014 at 10:19 PM, Daniel Kr=C3=BCgler
<daniel.kruegler@gmail.com> wrote:
> used in realistic implementations. I'm very much interested in the
> specific reasons for this resistance, because if there is already

It's pretty clear cut. You can't have a type that changes size over
time as an ISA is extended and not break users of that type over
binary interfaces.

If I compile my library using intmax_t in a public interface on
Compiler v.X with a 64-bit intmax and you compile your library with
Compiler v.Y with a 128-bit intmax and link them together then you get
undefined behavior when you use those interfaces. That's bad juju.

This is the same reason that Visual C++ isn't going to decide to make
sizeof(long)=3D=3D64 on x64 in the next release. You can't just change the
size of things without breakage.

Note that nothing stops an implementation from having larger integers
(or floats). They just can't be called standard extended integers and
must be considered implementation extensions (e.g. use of one of these
types is non-conforming) because standard extended integers must be no
larger than intmax_t.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D49595 for more backgroun=
d.

There's absolutely no reason that the standard can't add language for
standard extended floating point types. Just don't add an onerous
requirement for a floatmax_t.
--=20
Sean Middleditch
http://seanmiddleditch.com

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.