------=_Part_3762_712830513.1421096208584
Content-Type: multipart/alternative;
 boundary="----=_Part_3763_1878649025.1421096208584"

------=_Part_3763_1878649025.1421096208584
Content-Type: text/plain; charset=UTF-8

Now that Item 15 of Effective Modern C++ ("use constexpr whenever
possible", see e.g. this recent presentation
<https://www.youtube.com/watch?v=J-tA17slViE>) has brought C++14 relaxed
constexpr into the mainstream, it is perhaps time to introduce this feature
into the Standard Library.

I write "introduce" rather than "update" because AFAICS, there is currently
*zero* usage of relaxed constexpr (e.g. non-const but constexpr member
functions) in the current Draft Standard.

As a proof of concept, I have written a fully constexpr version of
std::array (available from BitBucket
<https://bitbucket.org/rhalbersma/xstd/src/484d0a3bf868b2229334d43310edbe41954cb102/include/xstd/array.hpp?at=default>).
In order to do so, I also had to transitively add the constexpr keyword to
a bunch of other facilities apart from the header <array> (as Scott Meyers
writes "constexpr begets constexpr").

   - from the header <algorithm>: fill_n, swap_ranges, equal and
   lexicographical_compare
   - from the header <iterator>: reverse_iterator
   - from the header <utility>: swap

Here I benefitted from the fact that the new "diamond operators"  such as
std::less<> already have a constexpr templated application operator. I chose
std::array for this exercise because of its relative simplicity and because
it nicely complements the new compile-time integer sequence facilities.

The only obstacle I encountered was a single dispatch of fill_n that (at
least in libc++) delegates to std::memset for which I had no access to the
underlying source code. With that caveat, it was a completely
straightforward excercise of transitively adding the keyword constexpr. No
other code mofications were necessary.

I don't claim to have made a full survey of the entire Standard Library,
but a I believe a similar exercise is possible for std::complex, std::bitset
(apart from the std::string constructors) and almost all the algorithms
from <algorithm> and <numeric> (apart from a few allocating algorithms such
as stable_sort, stable_partition and inplace_merge).

Of course, constexpr-ifying the standard algorithms would greatly benefit
from extra language support as well (constexpr lambdas, some form of heap
allocation to allow compile-time std::string). Nevertheless, given the
C++14 features, the Standard Library currently feels vastly underpowered to
what the core language offers in terms of constexpr.

My question is: how does the community and the committee feel about moving
a greater part (the majority?) of the Standard Library towards C++14
relaxed constexpr? I am willing to write a proposal along these lines given
enough support (or perhaps there are already efforts underway?)

--

---
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_3763_1878649025.1421096208584
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Now that Item 15 of Effective Modern C++ ("use <font face=
=3D"courier new, monospace">constexpr</font> whenever possible", see e.g. t=
his <a href=3D"https://www.youtube.com/watch?v=3DJ-tA17slViE">recent presen=
tation</a>) has brought C++14 relaxed <font face=3D"courier new, monospace"=
>constexpr</font> into the mainstream, it is perhaps time to introduce this=
 feature into the Standard Library.&nbsp;<div><br></div><div>I write "intro=
duce" rather than "update" because AFAICS, there is currently *zero* usage =
of relaxed <font face=3D"courier new, monospace">constexpr</font> (e.g. non=
-const but <font face=3D"courier new, monospace">constexpr</font> member fu=
nctions) in the current Draft Standard.&nbsp;<div><br></div><div>As a proof=
 of concept, I have written a fully <font face=3D"courier new, monospace">c=
onstexpr</font> version of <font face=3D"courier new, monospace">std::array=
</font> (available <a href=3D"https://bitbucket.org/rhalbersma/xstd/src/484=
d0a3bf868b2229334d43310edbe41954cb102/include/xstd/array.hpp?at=3Ddefault">=
from BitBucket</a>). In order to do so, I also had to transitively add the =
<font face=3D"courier new, monospace">constexpr</font> keyword to a bunch o=
f other facilities apart from the header <font face=3D"courier new, monospa=
ce">&lt;array&gt;</font> (a<span style=3D"font-size: 12.7272720336914px;">s=
 Scott Meyers writes "constexpr begets constexpr")</span><span style=3D"fon=
t-size: 13px;">.&nbsp;</span></div><div><ul><li><span style=3D"line-height:=
 normal;">from the header <font face=3D"courier new, monospace">&lt;algorit=
hm&gt;</font>:<font face=3D"courier new, monospace"> fill_n</font>, <font f=
ace=3D"courier new, monospace">swap_ranges</font>, <font face=3D"courier ne=
w, monospace">equal</font> and <font face=3D"courier new, monospace">lexico=
graphical_compare</font></span></li><li><span style=3D"line-height: normal;=
">from the header <font face=3D"courier new, monospace">&lt;iterator&gt;</f=
ont>: <font face=3D"courier new, monospace">reverse_iterator</font></span><=
/li><li><span style=3D"line-height: normal;">from the header <font face=3D"=
courier new, monospace">&lt;utility&gt;</font>: <font face=3D"courier new, =
monospace">swap</font></span></li></ul></div><div>Here I benefitted from th=
e fact that the new "diamond operators" &nbsp;such as <font face=3D"courier=
 new, monospace">std::less&lt;&gt;</font> already have a <font face=3D"cour=
ier new, monospace">constexpr</font> templated application operator. I chos=
e<font face=3D"courier new, monospace"> std::array</font>&nbsp;for this exe=
rcise because of its relative simplicity and because it nicely complements =
the new compile-time integer sequence facilities.&nbsp;</div><div><br></div=
><div>The only obstacle I encountered was a single dispatch of <font face=
=3D"courier new, monospace">fill_n</font> that (at least in libc++) delegat=
es to <font face=3D"courier new, monospace">std::memset</font> for which I =
had no access to the underlying source code. With that caveat, it was a com=
pletely straightforward excercise of transitively adding the keyword&nbsp;<=
font face=3D"courier new, monospace">constexpr</font>. No other code mofica=
tions were necessary.</div><div><br></div><div>I don't claim to have made a=
 full survey of the entire Standard Library, but a I believe a similar exer=
cise is possible for <font face=3D"courier new, monospace">std::complex</fo=
nt>, <font face=3D"courier new, monospace">std::bitset </font>(apart from t=
he <font face=3D"courier new, monospace">std::string</font> constructors) a=
nd almost all the algorithms from <font face=3D"courier new, monospace">&lt=
;algorithm&gt; </font>and<font face=3D"courier new, monospace"> &lt;numeric=
&gt;</font> (apart from a few allocating algorithms such as <font face=3D"c=
ourier new, monospace">stable_sort</font>, <font face=3D"courier new, monos=
pace">stable_partition</font> and <font face=3D"courier new, monospace">inp=
lace_merge</font>).&nbsp;</div><div><br></div><div>Of course, constexpr-ify=
ing the standard algorithms would greatly benefit from extra language suppo=
rt as well (<font face=3D"courier new, monospace">constexpr</font> lambdas,=
 some form of heap allocation to allow compile-time <font face=3D"courier n=
ew, monospace">std::string</font>). Nevertheless, given the C++14 features,=
 the Standard Library currently feels vastly underpowered to what the core =
language offers in terms of <font face=3D"courier new, monospace">constexpr=
</font>.&nbsp;</div><div><br></div><div>My question is: how does the commun=
ity and the committee feel about moving a greater part (the majority?) of t=
he Standard Library towards C++14 relaxed <font face=3D"courier new, monosp=
ace">constexpr</font>? I am willing to write a proposal along these lines g=
iven enough support (or perhaps there are already efforts underway?)</div><=
div><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_3763_1878649025.1421096208584--
------=_Part_3762_712830513.1421096208584--

.

On 2015-01-12 15:56, rhalbersma@gmail.com wrote:
> [...] it is perhaps time to introduce this feature
> into the Standard Library.
>
> I write "introduce" rather than "update" because AFAICS, there is currently
> *zero* usage of relaxed constexpr (e.g. non-const but constexpr member
> functions) in the current Draft Standard.

Some implementations have apparently started adding constexpr anyway.

If a concerted effort is made to 'fix' this, please don't forget places
like <limits>, <cmath>, etc. (I had to change some code that was
originally written against libstdc++ because libc++ does not have
constexpr of e.g. ldexp. Having constexpr of basic math functions and
number manipulation functions seems like a no-brainer...)

--
Matthew

--

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

.

On 12 January 2015 at 22:56,  <rhalbersma@gmail.com> wrote:
> Of course, constexpr-ifying the standard algorithms would greatly benefit
> from extra language support as well (constexpr lambdas, some form of heap
> allocation to allow compile-time std::string). Nevertheless, given the C++14
> features, the Standard Library currently feels vastly underpowered to what
> the core language offers in terms of constexpr.


For what it's worth, I plan to propose allowing constexpr lambdas. I
have no plans
to touch dynamic allocation at this time, though. If you want a
string-like thing
that works in constant expressions, perhaps std::experimental::string_view
works.

--

---
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_3913_1891146908.1421100128439
Content-Type: multipart/alternative;
 boundary="----=_Part_3914_1748107156.1421100128439"

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



=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=D0=B8=D0=BA, 12 =D1=8F=D0=
=BD=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 22:56:48 UTC+2, rhalb...@gmail.co=
m =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> Now that Item 15 of Effective Modern C++ ("use constexpr whenever=20
> possible", see e.g. this recent presentation=20
> <https://www.youtube.com/watch?v=3DJ-tA17slViE>) has brought C++14 relaxe=
d=20
> constexpr into the mainstream, it is perhaps time to introduce this=20
> feature into the Standard Library.=20
>
> I write "introduce" rather than "update" because AFAICS, there is=20
> currently *zero* usage of relaxed constexpr (e.g. non-const but constexpr=
=20
> member functions) in the current Draft Standard.=20
>
> As a proof of concept, I have written a fully constexpr version of=20
> std::array (available from BitBucket=20
> <https://bitbucket.org/rhalbersma/xstd/src/484d0a3bf868b2229334d43310edbe=
41954cb102/include/xstd/array.hpp?at=3Ddefault>).=20
> In order to do so, I also had to transitively add the constexpr keyword=
=20
> to a bunch of other facilities apart from the header <array> (as Scott=20
> Meyers writes "constexpr begets constexpr").=20
>
>    - from the header <algorithm>: fill_n, swap_ranges, equal and=20
>    lexicographical_compare
>    - from the header <iterator>: reverse_iterator
>    - from the header <utility>: swap
>
> Here I benefitted from the fact that the new "diamond operators"  such as=
=20
> std::less<> already have a constexpr templated application operator. I=20
> chose std::array for this exercise because of its relative simplicity and=
=20
> because it nicely complements the new compile-time integer sequence=20
> facilities.=20
>
> The only obstacle I encountered was a single dispatch of fill_n that (at=
=20
> least in libc++) delegates to std::memset for which I had no access to=20
> the underlying source code. With that caveat, it was a completely=20
> straightforward excercise of transitively adding the keyword constexpr.=
=20
> No other code mofications were necessary.
>
> I don't claim to have made a full survey of the entire Standard Library,=
=20
> but a I believe a similar exercise is possible for std::complex, std::bit=
set=20
> (apart from the std::string constructors) and almost all the algorithms=
=20
> from <algorithm> and <numeric> (apart from a few allocating algorithms=20
> such as stable_sort, stable_partition and inplace_merge).=20
>
> Of course, constexpr-ifying the standard algorithms would greatly benefit=
=20
> from extra language support as well (constexpr lambdas, some form of heap=
=20
> allocation to allow compile-time std::string). Nevertheless, given the=20
> C++14 features, the Standard Library currently feels vastly underpowered =
to=20
> what the core language offers in terms of constexpr.=20
>
> My question is: how does the community and the committee feel about movin=
g=20
> a greater part (the majority?) of the Standard Library towards C++14=20
> relaxed constexpr? I am willing to write a proposal along these lines=20
> given enough support (or perhaps there are already efforts underway?)
>
>
This is a good idea but I think that we first need to fix those 'constexpr'=
=20
before supporting them in libraries. Here=20
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/B5R4IsL=
gRgs>is=20
where I have written it's fix and where is also link for it's problems.

--=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_3914_1748107156.1421100128439
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D0=BD=
=D0=B8=D0=BA, 12 =D1=8F=D0=BD=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 22:56:4=
8 UTC+2, rhalb...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Now that Item 15 of Eff=
ective Modern C++ ("use <font face=3D"courier new, monospace">constexpr</fo=
nt> whenever possible", see e.g. this <a href=3D"https://www.youtube.com/wa=
tch?v=3DJ-tA17slViE" target=3D"_blank" onmousedown=3D"this.href=3D'https://=
www.youtube.com/watch?v\75J-tA17slViE';return true;" onclick=3D"this.href=
=3D'https://www.youtube.com/watch?v\75J-tA17slViE';return true;">recent pre=
sentation</a>) has brought C++14 relaxed <font face=3D"courier new, monospa=
ce">constexpr</font> into the mainstream, it is perhaps time to introduce t=
his feature into the Standard Library.&nbsp;<div><br></div><div>I write "in=
troduce" rather than "update" because AFAICS, there is currently *zero* usa=
ge of relaxed <font face=3D"courier new, monospace">constexpr</font> (e.g. =
non-const but <font face=3D"courier new, monospace">constexpr</font> member=
 functions) in the current Draft Standard.&nbsp;<div><br></div><div>As a pr=
oof of concept, I have written a fully <font face=3D"courier new, monospace=
">constexpr</font> version of <font face=3D"courier new, monospace">std::ar=
ray</font> (available <a href=3D"https://bitbucket.org/rhalbersma/xstd/src/=
484d0a3bf868b2229334d43310edbe41954cb102/include/xstd/array.hpp?at=3Ddefaul=
t" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url=
?q\75https%3A%2F%2Fbitbucket.org%2Frhalbersma%2Fxstd%2Fsrc%2F484d0a3bf868b2=
229334d43310edbe41954cb102%2Finclude%2Fxstd%2Farray.hpp%3Fat%3Ddefault\46sa=
\75D\46sntz\0751\46usg\75AFQjCNEIFsCdp4jGfwysbupXwY7z60zqQA';return true;" =
onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbuc=
ket.org%2Frhalbersma%2Fxstd%2Fsrc%2F484d0a3bf868b2229334d43310edbe41954cb10=
2%2Finclude%2Fxstd%2Farray.hpp%3Fat%3Ddefault\46sa\75D\46sntz\0751\46usg\75=
AFQjCNEIFsCdp4jGfwysbupXwY7z60zqQA';return true;">from BitBucket</a>). In o=
rder to do so, I also had to transitively add the <font face=3D"courier new=
, monospace">constexpr</font> keyword to a bunch of other facilities apart =
from the header <font face=3D"courier new, monospace">&lt;array&gt;</font> =
(a<span style=3D"font-size:12.7272720336914px">s Scott Meyers writes "const=
expr begets constexpr")</span><span style=3D"font-size:13px">.&nbsp;</span>=
</div><div><ul><li><span style=3D"line-height:normal">from the header <font=
 face=3D"courier new, monospace">&lt;algorithm&gt;</font>:<font face=3D"cou=
rier new, monospace"> fill_n</font>, <font face=3D"courier new, monospace">=
swap_ranges</font>, <font face=3D"courier new, monospace">equal</font> and =
<font face=3D"courier new, monospace">lexicographical_compare</font></span>=
</li><li><span style=3D"line-height:normal">from the header <font face=3D"c=
ourier new, monospace">&lt;iterator&gt;</font>: <font face=3D"courier new, =
monospace">reverse_iterator</font></span></li><li><span style=3D"line-heigh=
t:normal">from the header <font face=3D"courier new, monospace">&lt;utility=
&gt;</font>: <font face=3D"courier new, monospace">swap</font></span></li><=
/ul></div><div>Here I benefitted from the fact that the new "diamond operat=
ors" &nbsp;such as <font face=3D"courier new, monospace">std::less&lt;&gt;<=
/font> already have a <font face=3D"courier new, monospace">constexpr</font=
> templated application operator. I chose<font face=3D"courier new, monospa=
ce"> std::array</font>&nbsp;for this exercise because of its relative simpl=
icity and because it nicely complements the new compile-time integer sequen=
ce facilities.&nbsp;</div><div><br></div><div>The only obstacle I encounter=
ed was a single dispatch of <font face=3D"courier new, monospace">fill_n</f=
ont> that (at least in libc++) delegates to <font face=3D"courier new, mono=
space">std::memset</font> for which I had no access to the underlying sourc=
e code. With that caveat, it was a completely straightforward excercise of =
transitively adding the keyword&nbsp;<font face=3D"courier new, monospace">=
constexpr</font>. No other code mofications were necessary.</div><div><br><=
/div><div>I don't claim to have made a full survey of the entire Standard L=
ibrary, but a I believe a similar exercise is possible for <font face=3D"co=
urier new, monospace">std::complex</font>, <font face=3D"courier new, monos=
pace">std::bitset </font>(apart from the <font face=3D"courier new, monospa=
ce">std::string</font> constructors) and almost all the algorithms from <fo=
nt face=3D"courier new, monospace">&lt;algorithm&gt; </font>and<font face=
=3D"courier new, monospace"> &lt;numeric&gt;</font> (apart from a few alloc=
ating algorithms such as <font face=3D"courier new, monospace">stable_sort<=
/font>, <font face=3D"courier new, monospace">stable_partition</font> and <=
font face=3D"courier new, monospace">inplace_merge</font>).&nbsp;</div><div=
><br></div><div>Of course, constexpr-ifying the standard algorithms would g=
reatly benefit from extra language support as well (<font face=3D"courier n=
ew, monospace">constexpr</font> lambdas, some form of heap allocation to al=
low compile-time <font face=3D"courier new, monospace">std::string</font>).=
 Nevertheless, given the C++14 features, the Standard Library currently fee=
ls vastly underpowered to what the core language offers in terms of <font f=
ace=3D"courier new, monospace">constexpr</font>.&nbsp;</div><div><br></div>=
<div>My question is: how does the community and the committee feel about mo=
ving a greater part (the majority?) of the Standard Library towards C++14 r=
elaxed <font face=3D"courier new, monospace">constexpr</font>? I am willing=
 to write a proposal along these lines given enough support (or perhaps the=
re are already efforts underway?)</div><div><br></div></div></div></blockqu=
ote><div><br></div><div>This is a good idea but I think that we first need =
to fix those 'constexpr' before supporting them in libraries. <a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/B5R4IsLgRg=
s">Here </a>is where I have written it's fix and where is also link for it'=
s problems.</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_3914_1748107156.1421100128439--
------=_Part_3913_1891146908.1421100128439--

.

On Monday 12 January 2015 16:39:29 Matthew Woehlke wrote:
> On 2015-01-12 15:56, rhalbersma@gmail.com wrote:
> > [...] it is perhaps time to introduce this feature
> > into the Standard Library.
> >
> > I write "introduce" rather than "update" because AFAICS, there is
> > currently
> > *zero* usage of relaxed constexpr (e.g. non-const but constexpr member
> > functions) in the current Draft Standard.
>
> Some implementations have apparently started adding constexpr anyway.
>
> If a concerted effort is made to 'fix' this, please don't forget places
> like <limits>, <cmath>, etc. (I had to change some code that was
> originally written against libstdc++ because libc++ does not have
> constexpr of e.g. ldexp. Having constexpr of basic math functions and
> number manipulation functions seems like a no-brainer...)

Note that the difference is whether the intrinsic functions are considered
constexpr or not. For GCC, __builtin_ldexp is constexpr but isn't for Clang:

$ cat test.cpp
constexpr int f() { return __builtin_ldexp(1, 2); }

$ gcc -c test.cpp

$ clang -c test.cpp
test.cpp:1:15: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
constexpr int f() { return __builtin_ldexp(1, 2); }
              ^
test.cpp:1:28: note: subexpression not valid in a constant expression
constexpr int f() { return __builtin_ldexp(1, 2); }
                           ^

libstdc++ is written specifically for GCC, so it makes use of that fact.
  template<typename _Tp>
    inline _GLIBCXX_CONSTEXPR
    typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
                                    double>::__type
    ldexp(_Tp __x, int __exp)
    { return __builtin_ldexp(__x, __exp); }

Not so with libc++, which supports multiple compilers and thus doesn't use the
intrinsic but instead calls the libm function:

template <class _A1>
inline _LIBCPP_INLINE_VISIBILITY
typename enable_if<is_integral<_A1>::value, double>::type
ldexp(_A1 __x, int __e) _NOEXCEPT {return ldexp((double)__x, __e);}

--
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/.

.

--Apple-Mail=_AA3B34B7-2707-4BD9-A87A-F51F6768CA25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9313, at 6:43 AM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> Note that the difference is whether the intrinsic functions are considere=
d=20
> constexpr or not. For GCC, __builtin_ldexp is constexpr but isn't for Cla=
ng:

For GCC, most of <cmath> is constexpr because it has supported compile-time=
 evaluation of constant floating-point expressions since time immemorial. O=
nly in C++11 (once constexpr extensions were forbidden) did this extension =
become nonconforming.

I almost finished a paper for Urbana, =E2=80=9CRefining floating-point cons=
texpr,=E2=80=9D but ultimately I had enough other material, and the impleme=
ntations kept evolving under my feet. I should finish it and find a present=
er for Lenexa. Co-authors are welcome!

--=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=_AA3B34B7-2707-4BD9-A87A-F51F6768CA25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9313, at 6:43 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><span style=3D"font-family: Helvet=
ica; 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: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: non=
e; display: inline !important;" class=3D"">Note that the difference is whet=
her the intrinsic functions are considered<span class=3D"Apple-converted-sp=
ace">&nbsp;</span></span><br style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: 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;" class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; float: none; display: inline !important;" class=3D"">constexpr or n=
ot. For GCC, __builtin_ldexp is constexpr but isn't for Clang:</span><br st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><div cl=
ass=3D"">For GCC, most of <font face=3D"Courier" class=3D"">&lt;cmath&gt;</=
font> is constexpr because it has supported compile-time evaluation of cons=
tant floating-point expressions since time immemorial. Only in C++11 (once =
<font face=3D"Courier" class=3D"">constexpr</font> extensions were forbidde=
n) did this extension become nonconforming.</div><div class=3D""><br class=
=3D""></div><div class=3D"">I almost finished a paper for Urbana, =E2=80=9C=
Refining floating-point constexpr,=E2=80=9D but ultimately I had enough oth=
er material, and the implementations kept evolving under my feet. I should =
finish it and find a presenter for Lenexa. Co-authors are welcome!</div></b=
ody></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=_AA3B34B7-2707-4BD9-A87A-F51F6768CA25--

.

On Tuesday 13 January 2015 09:18:13 David Krauss wrote:
> > On 2015=E2=80=9301=E2=80=9313, at 6:43 AM, Thiago Macieira <thiago@maci=
eira.org> wrote:
> >=20
> > Note that the difference is whether the intrinsic functions are conside=
red
>=20
> > constexpr or not. For GCC, __builtin_ldexp is constexpr but isn't for=
=20
Clang:
> For GCC, most of <cmath> is constexpr because it has supported compile-ti=
me
> evaluation of constant floating-point expressions since time immemorial.
> Only in C++11 (once constexpr extensions were forbidden) did this extensi=
on
> become nonconforming.
>=20
> I almost finished a paper for Urbana, =E2=80=9CRefining floating-point co=
nstexpr,=E2=80=9D
> but ultimately I had enough other material, and the implementations kept
> evolving under my feet. I should finish it and find a presenter for Lenex=
a.
> Co-authors are welcome!

I believe you should leave those functions in cmath be optionally constexpr=
..=20
Compilers do not have to make them constexpr if they are not equipped for=
=20
evaluating them at compile time, like GCC was.

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

--=20

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

.

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

On Mon, Jan 12, 2015 at 7:01 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Tuesday 13 January 2015 09:18:13 David Krauss wrote:
> > > On 2015=E2=80=9301=E2=80=9313, at 6:43 AM, Thiago Macieira <thiago@ma=
cieira.org>
> wrote:
> > >
> > > Note that the difference is whether the intrinsic functions are
> considered
> >
> > > constexpr or not. For GCC, __builtin_ldexp is constexpr but isn't for
> Clang:
> > For GCC, most of <cmath> is constexpr because it has supported
> compile-time
> > evaluation of constant floating-point expressions since time immemorial=
..
> > Only in C++11 (once constexpr extensions were forbidden) did this
> extension
> > become nonconforming.
> >
> > I almost finished a paper for Urbana, =E2=80=9CRefining floating-point
> constexpr,=E2=80=9D
> > but ultimately I had enough other material, and the implementations kep=
t
> > evolving under my feet. I should finish it and find a presenter for
> Lenexa.
> > Co-authors are welcome!
>
> I believe you should leave those functions in cmath be optionally
> constexpr.
> Compilers do not have to make them constexpr if they are not equipped for
> evaluating them at compile time, like GCC was.


It doesn't seem unreasonable to require more of C++17 implementations. I
think it's much better to make the functions unconditionally constexpr and
require the implementations to do the right thing.

One consideration, though: C supports controlling the floating point
environment in various ways, and C++ pays lipservice to this by providing
the <cfenv> header. If we ever start also supporting "#pragma STDC
FENV_ACCESS" and following the C rules here (which seems like a very bad
idea, but we're already half-way there) then that will have "interesting"
interactions with compile-time evaluation of floating-point expressions.

--=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/.

--089e01294836f6f1e3050c807998
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 M=
on, Jan 12, 2015 at 7:01 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tues=
day 13 January 2015 09:18:13 David Krauss wrote:<br>
&gt; &gt; On 2015=E2=80=9301=E2=80=9313, at 6:43 AM, Thiago Macieira &lt;<a=
 href=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Note that the difference is whether the intrinsic functions are c=
onsidered<br>
&gt;<br>
&gt; &gt; constexpr or not. For GCC, __builtin_ldexp is constexpr but isn&#=
39;t for<br>
Clang:<br>
&gt; For GCC, most of &lt;cmath&gt; is constexpr because it has supported c=
ompile-time<br>
&gt; evaluation of constant floating-point expressions since time immemoria=
l.<br>
&gt; Only in C++11 (once constexpr extensions were forbidden) did this exte=
nsion<br>
&gt; become nonconforming.<br>
&gt;<br>
&gt; I almost finished a paper for Urbana, =E2=80=9CRefining floating-point=
 constexpr,=E2=80=9D<br>
&gt; but ultimately I had enough other material, and the implementations ke=
pt<br>
&gt; evolving under my feet. I should finish it and find a presenter for Le=
nexa.<br>
&gt; Co-authors are welcome!<br>
<br>
</span>I believe you should leave those functions in cmath be optionally co=
nstexpr.<br>
Compilers do not have to make them constexpr if they are not equipped for<b=
r>
evaluating them at compile time, like GCC was.</blockquote><div><br></div><=
div>It doesn&#39;t seem unreasonable to require more of C++17 implementatio=
ns. I think it&#39;s much better to make the functions unconditionally cons=
texpr and require the implementations to do the right thing.</div><div><br>=
</div><div>One consideration, though: C supports controlling the floating p=
oint environment in various ways, and C++ pays lipservice to this by provid=
ing the &lt;cfenv&gt; header. If we ever start also supporting &quot;#pragm=
a STDC FENV_ACCESS&quot; and following the C rules here (which seems like a=
 very bad idea, but we&#39;re already half-way there) then that will have &=
quot;interesting&quot; interactions with compile-time evaluation of floatin=
g-point expressions.</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 />

--089e01294836f6f1e3050c807998--

.

------=_Part_868_153195147.1421121272403
Content-Type: multipart/alternative;
 boundary="----=_Part_869_2065426523.1421121272403"

------=_Part_869_2065426523.1421121272403
Content-Type: text/plain; charset=UTF-8

On Monday, January 12, 2015 at 5:18:18 PM UTC-8, David Krauss wrote:
>
> For GCC, most of <cmath> is constexpr because it has supported
> compile-time evaluation of constant floating-point expressions since time
> immemorial. Only in C++11 (once constexpr extensions were forbidden) did
> this extension become nonconforming.
>
>
Is it still the case that implementations aren't allowed to declare
standard functions as constexpr that are not explicitly constexpr in the
Standard?  What this thread is about is otherwise confusing me...sorry.

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_869_2065426523.1421121272403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, January 12, 2015 at 5:18:18 PM UTC-8, David Kra=
uss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-w=
rap:break-word">For GCC, most of <font face=3D"Courier">&lt;cmath&gt;</font=
> is constexpr because it has supported compile-time evaluation of constant=
 floating-point expressions since time immemorial. Only in C++11 (once <fon=
t face=3D"Courier">constexpr</font> extensions were forbidden) did this ext=
ension become nonconforming.<div><br></div></div></blockquote><div><br>Is i=
t still the case that implementations aren't allowed to declare standard fu=
nctions as <span style=3D"font-family: courier new,monospace;">constexpr</s=
pan> that are not explicitly <span style=3D"font-family: courier new,monosp=
ace;">constexpr</span> in the Standard?&nbsp; What this thread is about is =
otherwise confusing me...sorry.<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_869_2065426523.1421121272403--
------=_Part_868_153195147.1421121272403--

.

--Apple-Mail=_AC2654A7-ED28-4CEC-9B30-D2F8139AD82B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9313, at 11:54 AM, Myriachan <myriachan@gmail.co=
m> wrote:
>=20
> Is it still the case that implementations aren't allowed to declare stand=
ard functions as constexpr that are not explicitly constexpr in the Standar=
d?  What this thread is about is otherwise confusing me=E2=80=A6sorry.

Yes, it=E2=80=99s still the case. My recollection is that the restriction w=
as added by a DR which was resolved after C++11, but it might have been bef=
ore.

Considering the potential for language fragmentation, the decision is unlik=
ely to be reversed.


> On 2015=E2=80=9301=E2=80=9313, at 11:47 AM, Richard Smith <richard@metafo=
o.co.uk> wrote:
>=20
> One consideration, though: C supports controlling the floating point envi=
ronment in various ways, and C++ pays lipservice to this by providing the <=
cfenv> header. If we ever start also supporting "#pragma STDC FENV_ACCESS" =
and following the C rules here (which seems like a very bad idea, but we're=
 already half-way there) then that will have "interesting" interactions wit=
h compile-time evaluation of floating-point expressions.

Nothing that #pragma STDC FP_CONTRACT doesn=E2=80=99t already do. Such inte=
ractions are acknowledged and dealt with simply. C99/C11 =C2=A76.5/8:

> Otherwise, whether and how expressions are contracted is implementation-d=
efined. *
>=20
> * This license is specifically intended to allow implementations to explo=
it fast machine instructions that combine multiple C operators. As contract=
ions potentially undermine predictability, and can even decrease accuracy f=
or containing expressions, their use needs to be well-defined and clearly d=
ocumented.

The difference is that FP_CONTRACT can be turned off but constexpr can=E2=
=80=99t. If we set aside the C/C++ rivalry, would it be too unreasonable to=
 let <cmath> be non-constexpr when FP_CONTRACT OFF is in effect in the scop=
e enclosing the call? (Despite being a pragma, it is scoped.)

--=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=_AC2654A7-ED28-4CEC-9B30-D2F8139AD82B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9313, at 11:54 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.c=
om" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div class=
=3D"">Is it still the case that implementations aren't allowed to declare s=
tandard functions as <span style=3D"font-family: courier new,monospace;" cl=
ass=3D"">constexpr</span> that are not explicitly <span style=3D"font-famil=
y: courier new,monospace;" class=3D"">constexpr</span> in the Standard?&nbs=
p; What this thread is about is otherwise confusing me=E2=80=A6sorry.<br cl=
ass=3D""></div></div></div></blockquote><div><br class=3D""></div><div>Yes,=
 it=E2=80=99s still the case. My recollection is that the restriction was a=
dded by a DR which was resolved after C++11, but it might have been before.=
</div><div><br class=3D""></div><div>Considering the potential for language=
 fragmentation, the decision is unlikely to be reversed.</div><div><br clas=
s=3D""></div><div><br class=3D""></div><div><blockquote type=3D"cite" class=
=3D""><div class=3D"">On 2015=E2=80=9301=E2=80=9313, at 11:47 AM, Richard S=
mith &lt;<a href=3D"mailto:richard@metafoo.co.uk" class=3D"">richard@metafo=
o.co.uk</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div cl=
ass=3D""><span class=3D"" style=3D"float: none; display: inline !important;=
">One consideration, though: C supports controlling the floating point envi=
ronment in various ways, and C++ pays lipservice to this by providing the &=
lt;cfenv&gt; header. If we ever start also supporting "#pragma STDC FENV_AC=
CESS" and following the C rules here (which seems like a very bad idea, but=
 we're already half-way there) then that will have "interesting" interactio=
ns with compile-time evaluation of floating-point expressions.</span></div>=
</blockquote><div class=3D""><div class=3D""><span class=3D"" style=3D"floa=
t: none; display: inline !important;"><br class=3D""></span></div></div><di=
v class=3D""><span class=3D"" style=3D"float: none; display: inline !import=
ant;">Nothing that <font face=3D"Courier" class=3D"">#pragma STDC FP_CONTRA=
CT</font> doesn=E2=80=99t already do. Such interactions are acknowledged an=
d dealt with simply. C99/C11 =C2=A76.5/8:</span></div><div class=3D""><span=
 class=3D"" style=3D"float: none; display: inline !important;"><br class=3D=
""></span></div><div class=3D""></div><blockquote type=3D"cite" class=3D"">=
<div class=3D""><span class=3D"" style=3D"float: none; display: inline !imp=
ortant;">Otherwise, whether and how expressions are&nbsp;contracted is impl=
ementation-defined. *</span></div><div class=3D""><span class=3D"" style=3D=
"float: none; display: inline !important;"><br class=3D""></span></div><div=
 class=3D""><span class=3D"" style=3D"float: none; display: inline !importa=
nt;">*&nbsp;</span>This license is specifically intended to allow implement=
ations to exploit fast machine instructions that&nbsp;combine multiple C op=
erators. As contractions&nbsp;potentially undermine predictability, and can=
 even&nbsp;decrease accuracy for containing expressions, their use needs to=
 be well-defined and clearly&nbsp;documented.</div></blockquote><div class=
=3D""><br class=3D""></div><div class=3D"">The difference is that <font fac=
e=3D"Courier" class=3D"">FP_CONTRACT</font> can be turned off but <font fac=
e=3D"Courier" class=3D"">constexpr</font> can=E2=80=99t. If we set aside th=
e C/C++ rivalry, would it be too unreasonable to let <font face=3D"Courier"=
 class=3D"">&lt;cmath&gt;</font> be non-constexpr when <font face=3D"Courie=
r" class=3D"">FP_CONTRACT OFF</font> is in effect in the scope enclosing th=
e call? (Despite being a pragma, it is scoped.)</div></div></div></body></h=
tml>

<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=_AC2654A7-ED28-4CEC-9B30-D2F8139AD82B--

.

------=_Part_2754_1091509529.1421140834165
Content-Type: multipart/alternative;
 boundary="----=_Part_2755_727983994.1421140834165"

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

I am sorry for my silly question. What is  Urbana?

On Tuesday, January 13, 2015 at 4:18:18 AM UTC+3, David Krauss wrote:
>
>
> On 2015=E2=80=9301=E2=80=9313, at 6:43 AM, Thiago Macieira <thi...@maciei=
ra.org=20
> <javascript:>> wrote:
>
> Note that the difference is whether the intrinsic functions are considere=
d
> =20
> constexpr or not. For GCC, __builtin_ldexp is constexpr but isn't for=20
> Clang:
>
>
> For GCC, most of <cmath> is constexpr because it has supported=20
> compile-time evaluation of constant floating-point expressions since time=
=20
> immemorial. Only in C++11 (once constexpr extensions were forbidden) did=
=20
> this extension become nonconforming.
>
> I almost finished a paper for Urbana, =E2=80=9CRefining floating-point co=
nstexpr,=E2=80=9D=20
> but ultimately I had enough other material, and the implementations kept=
=20
> evolving under my feet. I should finish it and find a presenter for Lenex=
a.=20
> Co-authors are welcome!
>

--=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_2755_727983994.1421140834165
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am sorry for my silly question. What is&nbsp; Urbana?<br=
><br>On Tuesday, January 13, 2015 at 4:18:18 AM UTC+3, David Krauss wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;"><div style=3D"-ms-word-wrap: break-word;"><br><=
div><blockquote type=3D"cite"><div>On 2015=E2=80=9301=E2=80=9313, at 6:43 A=
M, Thiago Macieira &lt;<a onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"0SCGdM2UFJgJ">thi...@macieira=
..org</a>&gt; wrote:</div><br><div><span style=3D"font: 12px/normal Helvetic=
a; text-transform: none; text-indent: 0px; letter-spacing: normal; word-spa=
cing: 0px; float: none; display: inline !important; white-space: normal; fo=
nt-size-adjust: none; font-stretch: normal;">Note that the difference is wh=
ether the intrinsic functions are considered<span>&nbsp;</span></span><br s=
tyle=3D"font: 12px/normal Helvetica; text-transform: none; text-indent: 0px=
; letter-spacing: normal; word-spacing: 0px; white-space: normal; font-size=
-adjust: none; font-stretch: normal;"><span style=3D"font: 12px/normal Helv=
etica; text-transform: none; text-indent: 0px; letter-spacing: normal; word=
-spacing: 0px; float: none; display: inline !important; white-space: normal=
; font-size-adjust: none; font-stretch: normal;">constexpr or not. For GCC,=
 __builtin_ldexp is constexpr but isn't for Clang:</span><br style=3D"font:=
 12px/normal Helvetica; text-transform: none; text-indent: 0px; letter-spac=
ing: normal; word-spacing: 0px; white-space: normal; font-size-adjust: none=
; font-stretch: normal;"></div></blockquote></div><br><div>For GCC, most of=
 <font face=3D"Courier">&lt;cmath&gt;</font> is constexpr because it has su=
pported compile-time evaluation of constant floating-point expressions sinc=
e time immemorial. Only in C++11 (once <font face=3D"Courier">constexpr</fo=
nt> extensions were forbidden) did this extension become nonconforming.</di=
v><div><br></div><div>I almost finished a paper for Urbana, =E2=80=9CRefini=
ng floating-point constexpr,=E2=80=9D but ultimately I had enough other mat=
erial, and the implementations kept evolving under my feet. I should finish=
 it and find a presenter for Lenexa. Co-authors are welcome!</div></div></b=
lockquote></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_2755_727983994.1421140834165--
------=_Part_2754_1091509529.1421140834165--

.

> On 2015=E2=80=9301=E2=80=9313, at 5:20 PM, Vlad from Moscow <vlad.moscow@=
mail.ru> wrote:
>=20
> I am sorry for my silly question. What is  Urbana?

The most recent ISO C++ meeting. It was the first meeting I attended, and I=
 presented 7 papers, which was already a lot. (Also, it is a small city in =
Illinois, USA, which contains most of a large university.)

Lenexa is the next meeting. I will not attend it.

--=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_4197_983953073.1421144292598
Content-Type: multipart/alternative;
 boundary="----=_Part_4198_1675216011.1421144292598"

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

Thanks. I had thought at first that iit is a journal on computing.:)

On Tuesday, January 13, 2015 at 1:13:05 PM UTC+3, David Krauss wrote:
>
>
> > On 2015=E2=80=9301=E2=80=9313, at 5:20 PM, Vlad from Moscow <vlad....@m=
ail.ru=20
> <javascript:>> wrote:=20
> >=20
> > I am sorry for my silly question. What is  Urbana?=20
>
> The most recent ISO C++ meeting. It was the first meeting I attended, and=
=20
> I presented 7 papers, which was already a lot. (Also, it is a small city =
in=20
> Illinois, USA, which contains most of a large university.)=20
>
> Lenexa is the next meeting. I will not attend it.

--=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_4198_1675216011.1421144292598
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks. I had thought at first that iit is a journal on co=
mputing.:)<br><br>On Tuesday, January 13, 2015 at 1:13:05 PM UTC+3, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">
<br>&gt; On 2015=E2=80=9301=E2=80=9313, at 5:20 PM, Vlad from Moscow &lt;<a=
 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"4EXGerK-PLMJ">vlad....@mail.ru</a>&gt; wrote:
<br>&gt;=20
<br>&gt; I am sorry for my silly question. What is &nbsp;Urbana?
<br>
<br>The most recent ISO C++ meeting. It was the first meeting I attended, a=
nd I presented 7 papers, which was already a lot. (Also, it is a small city=
 in Illinois, USA, which contains most of a large university.)
<br>
<br>Lenexa is the next meeting. I will not attend it.</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_4198_1675216011.1421144292598--
------=_Part_4197_983953073.1421144292598--

.

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

On Mon, Jan 12, 2015 at 9:20 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2015=E2=80=9301=E2=80=9313, at 11:54 AM, Myriachan <myriachan@gmail.co=
m> wrote:
>
> Is it still the case that implementations aren't allowed to declare
> standard functions as constexpr that are not explicitly constexpr in the
> Standard?  What this thread is about is otherwise confusing me=E2=80=A6so=
rry.
>
>
> Yes, it=E2=80=99s still the case. My recollection is that the restriction=
 was
> added by a DR which was resolved after C++11, but it might have been befo=
re.
>
> Considering the potential for language fragmentation, the decision is
> unlikely to be reversed.
>
>
> On 2015=E2=80=9301=E2=80=9313, at 11:47 AM, Richard Smith <richard@metafo=
o.co.uk> wrote:
>
> One consideration, though: C supports controlling the floating point
> environment in various ways, and C++ pays lipservice to this by providing
> the <cfenv> header. If we ever start also supporting "#pragma STDC
> FENV_ACCESS" and following the C rules here (which seems like a very bad
> idea, but we're already half-way there) then that will have "interesting"
> interactions with compile-time evaluation of floating-point expressions.
>
>
> Nothing that #pragma STDC FP_CONTRACT doesn=E2=80=99t already do. Such
> interactions are acknowledged and dealt with simply. C99/C11 =C2=A76.5/8:
>
> Otherwise, whether and how expressions are contracted is
> implementation-defined. *
>
> * This license is specifically intended to allow implementations to
> exploit fast machine instructions that combine multiple C operators. As
> contractions potentially undermine predictability, and can even decrease
> accuracy for containing expressions, their use needs to be well-defined a=
nd
> clearly documented.
>
>
> The difference is that FP_CONTRACT can be turned off but constexpr can=E2=
=80=99t.
> If we set aside the C/C++ rivalry, would it be too unreasonable to let
> <cmath> be non-constexpr when FP_CONTRACT OFF is in effect in the scope
> enclosing the call? (Despite being a pragma, it is scoped.)
>

(I was talking about FENV_ACCESS, not FP_CONTRACT. Dealing with FP_CONTRACT
is easy; just don't do contractions in constexpr evaluation.) On
reflection, I think this goes further than <cmath>, since fesetround
affects the results of (for instance) floating point addition, too. So
there's no *new* problem here. =3D)

--=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/.

--20cf3011dd81758b05050c8fb5ac
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 M=
on, Jan 12, 2015 at 9:20 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9301=E2=80=9313, at=
 11:54 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.com" target=3D"_=
blank">myriachan@gmail.com</a>&gt; wrote:</div><br><div><div dir=3D"ltr"><d=
iv>Is it still the case that implementations aren&#39;t allowed to declare =
standard functions as <span style=3D"font-family:courier new,monospace">con=
stexpr</span> that are not explicitly <span style=3D"font-family:courier ne=
w,monospace">constexpr</span> in the Standard?=C2=A0 What this thread is ab=
out is otherwise confusing me=E2=80=A6sorry.<br></div></div></div></blockqu=
ote><div><br></div><div>Yes, it=E2=80=99s still the case. My recollection i=
s that the restriction was added by a DR which was resolved after C++11, bu=
t it might have been before.</div><div><br></div><div>Considering the poten=
tial for language fragmentation, the decision is unlikely to be reversed.</=
div><div><br></div><div><br></div><div><span class=3D""><blockquote type=3D=
"cite"><div>On 2015=E2=80=9301=E2=80=9313, at 11:47 AM, Richard Smith &lt;<=
a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.c=
o.uk</a>&gt; wrote:</div><br><div><span style=3D"float:none;display:inline!=
important">One consideration, though: C supports controlling the floating p=
oint environment in various ways, and C++ pays lipservice to this by provid=
ing the &lt;cfenv&gt; header. If we ever start also supporting &quot;#pragm=
a STDC FENV_ACCESS&quot; and following the C rules here (which seems like a=
 very bad idea, but we&#39;re already half-way there) then that will have &=
quot;interesting&quot; interactions with compile-time evaluation of floatin=
g-point expressions.</span></div></blockquote><div><div><span style=3D"floa=
t:none;display:inline!important"><br></span></div></div></span><div><span s=
tyle=3D"float:none;display:inline!important">Nothing that <font face=3D"Cou=
rier">#pragma STDC FP_CONTRACT</font> doesn=E2=80=99t already do. Such inte=
ractions are acknowledged and dealt with simply. C99/C11 =C2=A76.5/8:</span=
></div><div><span style=3D"float:none;display:inline!important"><br></span>=
</div><div></div><blockquote type=3D"cite"><div><span style=3D"float:none;d=
isplay:inline!important">Otherwise, whether and how expressions are=C2=A0co=
ntracted is implementation-defined. *</span></div><div><span style=3D"float=
:none;display:inline!important"><br></span></div><div><span style=3D"float:=
none;display:inline!important">*=C2=A0</span>This license is specifically i=
ntended to allow implementations to exploit fast machine instructions that=
=C2=A0combine multiple C operators. As contractions=C2=A0potentially underm=
ine predictability, and can even=C2=A0decrease accuracy for containing expr=
essions, their use needs to be well-defined and clearly=C2=A0documented.</d=
iv></blockquote><div><br></div><div>The difference is that <font face=3D"Co=
urier">FP_CONTRACT</font> can be turned off but <font face=3D"Courier">cons=
texpr</font> can=E2=80=99t. If we set aside the C/C++ rivalry, would it be =
too unreasonable to let <font face=3D"Courier">&lt;cmath&gt;</font> be non-=
constexpr when <font face=3D"Courier">FP_CONTRACT OFF</font> is in effect i=
n the scope enclosing the call? (Despite being a pragma, it is scoped.)</di=
v></div></div></div></blockquote><div><br></div><div>(I was talking about F=
ENV_ACCESS, not FP_CONTRACT. Dealing with FP_CONTRACT is easy; just don&#39=
;t do contractions in constexpr evaluation.) On reflection, I think this go=
es further than &lt;cmath&gt;, since fesetround affects the results of (for=
 instance) floating point addition, too. So there&#39;s no *new* problem he=
re. =3D)</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 />

--20cf3011dd81758b05050c8fb5ac--

.

--Apple-Mail=_C9E71FB9-BB27-4A12-9767-829B1EBBEF62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9314, at 5:57 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>=20
> (I was talking about FENV_ACCESS, not FP_CONTRACT. Dealing with FP_CONTRA=
CT is easy; just don't do contractions in constexpr evaluation.)

Yes, and I=E2=80=99m talking about the intersection of FENV_ACCESS and FP_C=
ONTRACT.

You mentioned interaction between constexpr and FENV_ACCESS. Expressions wh=
ich are constexpr/contracted will not set overflow bits. FP_CONTRACT is the=
 C99 analogue to constexpr, although it provides few guarantees.

> On reflection, I think this goes further than <cmath>, since fesetround a=
ffects the results of (for instance) floating point addition, too. So there=
's no *new* problem here. =3D)

When things are done at compile time, all bets are off.

--=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=_C9E71FB9-BB27-4A12-9767-829B1EBBEF62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9314, at 5:57 AM, Richard Smith &lt;<a href=3D"mailto:richard@metafo=
o.co.uk" class=3D"">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">(I was ta=
lking about FENV_ACCESS, not FP_CONTRACT. Dealing with FP_CONTRACT is easy;=
 just don't do contractions in constexpr evaluation.)</div></div></div></di=
v></div></blockquote><div><br class=3D""></div><div><div>Yes, and I=E2=80=
=99m talking about the intersection of&nbsp;<font face=3D"Courier" class=3D=
"">FENV_ACCESS</font>&nbsp;and&nbsp;<font face=3D"Courier" class=3D"">FP_CO=
NTRACT</font>.</div><div><br class=3D""></div><div>You mentioned interactio=
n between&nbsp;<span style=3D"font-family: Courier;" class=3D"">constexpr</=
span>&nbsp;and&nbsp;<span style=3D"font-family: Courier;" class=3D"">FENV_A=
CCESS</span>. Expressions which are <font face=3D"Courier" class=3D"">const=
expr</font>/contracted will not set overflow bits.&nbsp;<span style=3D"font=
-family: Courier;" class=3D"">FP_CONTRACT</span>&nbsp;is the C99 analogue t=
o&nbsp;<font face=3D"Courier" class=3D"">constexpr</font>, although it prov=
ides few guarantees.</div></div><br class=3D""><blockquote type=3D"cite" cl=
ass=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div class=3D"">On reflection, I think this=
 goes further than &lt;cmath&gt;, since fesetround affects the results of (=
for instance) floating point addition, too. So there's no *new* problem her=
e. =3D)</div></div></div></div></div></blockquote><div><br class=3D""></div=
><div>When things are done at compile time, all bets are off.</div></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=_C9E71FB9-BB27-4A12-9767-829B1EBBEF62--

.