Topic: constexpr dynamic allocations
Author: Avi Kivity <avi@scylladb.com>
Date: Thu, 28 Jun 2018 12:34:21 +0300
Raw View
Allowing dynamic allocations in constexpr context would allow using much=20
of the standard library in these contexts. I think it can be done if we=20
apply the following rule:
=C2=A0- a constexpr evaluation may not return an object containing=20
dynamically allocated memory
So the following works:
=C2=A0constexpr most_frequent(std::initializer_list<int> inputs) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unordered_map<int, int> fr=
equencies;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (auto k : inputs) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 f=
requencies[k] +=3D 1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto it =3D std::max_element(fr=
equencies.begin(),=20
frequencies.end(), ...);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return it->first;
=C2=A0}
char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1
because after evaluating the expression, all dynamically allocated=20
memory has been returned.
Internally, the compiler would have its constexpr operator new return an=20
unforgeable type-safe pointer (probably an index into an internal=20
table). The compiler will use constexpr versions of operator new and=20
operator delete, even if the program provides its own implementations.=20
When evaluation is complete, the compiler walks the object graph and=20
makes sure all pointers are null.
I see this was proposed in the past, but with a static_allocator, which=20
makes the feature harder to reuse by requiring that all user code be a=20
template on the allocator (if the user wishes to preserve dual use of=20
their code).
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.=
com.
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Thu, 28 Jun 2018 11:40:09 +0200
Raw View
--0000000000000f0a34056fb0851d
Content-Type: text/plain; charset="UTF-8"
There is a proposal to allow just that and it even allows for an allocation
to "transcend" compile time evaluation.
See P0784 for more info. It saw great encouragement in EWG.
On Thu, Jun 28, 2018, 11:34 AM Avi Kivity <avi@scylladb.com> wrote:
> Allowing dynamic allocations in constexpr context would allow using much
> of the standard library in these contexts. I think it can be done if we
> apply the following rule:
>
>
> - a constexpr evaluation may not return an object containing
> dynamically allocated memory
>
>
> So the following works:
>
>
> constexpr most_frequent(std::initializer_list<int> inputs) {
>
> std::unordered_map<int, int> frequencies;
>
> for (auto k : inputs) {
>
> frequencies[k] += 1;
>
> }
>
> auto it = std::max_element(frequencies.begin(),
> frequencies.end(), ...);
>
> return it->first;
>
> }
>
>
> char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1
>
>
> because after evaluating the expression, all dynamically allocated
> memory has been returned.
>
>
> Internally, the compiler would have its constexpr operator new return an
> unforgeable type-safe pointer (probably an index into an internal
> table). The compiler will use constexpr versions of operator new and
> operator delete, even if the program provides its own implementations.
> When evaluation is complete, the compiler walks the object graph and
> makes sure all pointers are null.
>
>
> I see this was proposed in the past, but with a static_allocator, which
> makes the feature harder to reuse by requiring that all user code be a
> template on the allocator (if the user wishes to preserve dual use of
> their code).
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com.
--0000000000000f0a34056fb0851d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>There is a proposal to allow just that and it even a=
llows for an allocation to "transcend" compile time evaluation.<d=
iv dir=3D"auto"><br></div><div dir=3D"auto">See P0784 for more info. It saw=
great encouragement in EWG.</div><br><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Thu, Jun 28, 2018, 11:34 AM Avi Kivity <<a href=3D"mailto:=
avi@scylladb.com">avi@scylladb.com</a>> wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">Allowing dynamic allocations in constexpr context would allo=
w using much <br>
of the standard library in these contexts. I think it can be done if we <br=
>
apply the following rule:<br>
<br>
<br>
=C2=A0=C2=A0- a constexpr evaluation may not return an object containing <b=
r>
dynamically allocated memory<br>
<br>
<br>
So the following works:<br>
<br>
<br>
=C2=A0=C2=A0constexpr most_frequent(std::initializer_list<int> inputs=
) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unordered_map<int,=
int> frequencies;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (auto k : inputs) {<br=
>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 frequencies[k] +=3D 1;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto it =3D std::max_eleme=
nt(frequencies.begin(), <br>
frequencies.end(), ...);<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return it->first;<br>
<br>
=C2=A0=C2=A0}<br>
<br>
<br>
char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1<br>
<br>
<br>
because after evaluating the expression, all dynamically allocated <br>
memory has been returned.<br>
<br>
<br>
Internally, the compiler would have its constexpr operator new return an <b=
r>
unforgeable type-safe pointer (probably an index into an internal <br>
table). The compiler will use constexpr versions of operator new and <br>
operator delete, even if the program provides its own implementations. <br>
When evaluation is complete, the compiler walks the object graph and <br>
makes sure all pointers are null.<br>
<br>
<br>
I see this was proposed in the past, but with a static_allocator, which <br=
>
makes the feature harder to reuse by requiring that all user code be a <br>
template on the allocator (if the user wishes to preserve dual use of <br>
their code).<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%=
40scylladb.com" rel=3D"noreferrer noreferrer" target=3D"_blank">https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9=
b1d37c20596%40scylladb.com</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_y=
GKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVO=
JxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com</a>.<br />
--0000000000000f0a34056fb0851d--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Thu, 28 Jun 2018 12:48:00 +0300
Raw View
This is a multi-part message in MIME format.
--------------891AEC2B14FD4511F84CE770
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
That's wonderful to hear. I see it's mentioned in the same breath as=20
reflection, which is exactly the use case I had in mind. Things like=20
lex/yacc can be embedded into C++ code, so we'll never have to leave the=20
warm safety of the compiler, except to buy more RAM.
I can't find the actual P0784 though, just references to it. Do you have=20
a link handy?
On 2018-06-28 12:40, Nicolas Lesser wrote:
> There is a proposal to allow just that and it even allows for an=20
> allocation to "transcend" compile time evaluation.
>
> See P0784 for more info. It saw great encouragement in EWG.
>
>
> On Thu, Jun 28, 2018, 11:34 AM Avi Kivity <avi@scylladb.com=20
> <mailto:avi@scylladb.com>> wrote:
>
> Allowing dynamic allocations in constexpr context would allow
> using much
> of the standard library in these contexts. I think it can be done
> if we
> apply the following rule:
>
>
> =C2=A0=C2=A0- a constexpr evaluation may not return an object contain=
ing
> dynamically allocated memory
>
>
> So the following works:
>
>
> =C2=A0=C2=A0constexpr most_frequent(std::initializer_list<int> inputs=
) {
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unordered_map<i=
nt, int> frequencies;
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (auto k : inputs=
) {
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 frequencies[k] +=3D 1;
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto it =3D std::max=
_element(frequencies.begin(),
> frequencies.end(), ...);
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return it->first;
>
> =C2=A0=C2=A0}
>
>
> char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1
>
>
> because after evaluating the expression, all dynamically allocated
> memory has been returned.
>
>
> Internally, the compiler would have its constexpr operator new
> return an
> unforgeable type-safe pointer (probably an index into an internal
> table). The compiler will use constexpr versions of operator new and
> operator delete, even if the program provides its own
> implementations.
> When evaluation is complete, the compiler walks the object graph and
> makes sure all pointers are null.
>
>
> I see this was proposed in the past, but with a static_allocator,
> which
> makes the feature harder to reuse by requiring that all user code
> be a
> template on the allocator (if the user wishes to preserve dual use of
> their code).
>
> --=20
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5=
-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com.
>
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u=
8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5=
u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/77ea3f99-5292-c00e-33ef-aa682b224327%40scylladb.=
com.
--------------891AEC2B14FD4511F84CE770
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>That's wonderful to hear. I see it's mentioned in the same breath
as reflection, which is exactly the use case I had in mind. Things
like lex/yacc can be embedded into C++ code, so we'll never have
to leave the warm safety of the compiler, except to buy more RAM.<br>
</p>
<br>
I can't find the actual P0784 though, just references to it. Do you
have a link handy?<br>
<br>
<div class=3D"moz-cite-prefix">On 2018-06-28 12:40, Nicolas Lesser
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ@mail.gmail.=
com">
<div dir=3D"auto">
<div>There is a proposal to allow just that and it even allows
for an allocation to "transcend" compile time evaluation.
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">See P0784 for more info. It saw great
encouragement in EWG.</div>
<br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Jun 28, 2018, 11:34 AM Avi Kivity
<<a href=3D"mailto:avi@scylladb.com"
moz-do-not-send=3D"true">avi@scylladb.com</a>> wrote:<br=
>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Allowing
dynamic allocations in constexpr context would allow using
much <br>
of the standard library in these contexts. I think it can
be done if we <br>
apply the following rule:<br>
<br>
<br>
=C2=A0=C2=A0- a constexpr evaluation may not return an object
containing <br>
dynamically allocated memory<br>
<br>
<br>
So the following works:<br>
<br>
<br>
=C2=A0=C2=A0constexpr most_frequent(std::initializer_list<=
int>
inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unorder=
ed_map<int, int> frequencies;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (auto k =
: inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 frequencies[k] +=3D 1;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto it =3D =
std::max_element(frequencies.begin(), <br>
frequencies.end(), ...);<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return it-&g=
t;first;<br>
<br>
=C2=A0=C2=A0}<br>
<br>
<br>
char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1<br=
>
<br>
<br>
because after evaluating the expression, all dynamically
allocated <br>
memory has been returned.<br>
<br>
<br>
Internally, the compiler would have its constexpr operator
new return an <br>
unforgeable type-safe pointer (probably an index into an
internal <br>
table). The compiler will use constexpr versions of
operator new and <br>
operator delete, even if the program provides its own
implementations. <br>
When evaluation is complete, the compiler walks the object
graph and <br>
makes sure all pointers are null.<br>
<br>
<br>
I see this was proposed in the past, but with a
static_allocator, which <br>
makes the feature harder to reuse by requiring that all
user code be a <br>
template on the allocator (if the user wishes to preserve
dual use of <br>
their code).<br>
<br>
-- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
target=3D"_blank" rel=3D"noreferrer" moz-do-not-send=3D"tru=
e">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank"
rel=3D"noreferrer" moz-do-not-send=3D"true">std-proposals@i=
socpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255=
d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com"
rel=3D"noreferrer noreferrer" target=3D"_blank"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.=
com</a>.<br>
</blockquote>
</div>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDw=
q1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40ma=
il.gmail.com</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/77ea3f99-5292-c00e-33ef-aa682b224327%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/77ea3f99-5292-c00e-33ef-aa682b2243=
27%40scylladb.com</a>.<br />
--------------891AEC2B14FD4511F84CE770--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Thu, 28 Jun 2018 11:52:39 +0200
Raw View
--000000000000b3c070056fb0b12e
Content-Type: text/plain; charset="UTF-8"
You can check out https://wg21.link:
https://wg21.link/p0784
On Thu, Jun 28, 2018, 11:48 AM Avi Kivity <avi@scylladb.com> wrote:
> That's wonderful to hear. I see it's mentioned in the same breath as
> reflection, which is exactly the use case I had in mind. Things like
> lex/yacc can be embedded into C++ code, so we'll never have to leave the
> warm safety of the compiler, except to buy more RAM.
>
> I can't find the actual P0784 though, just references to it. Do you have a
> link handy?
>
> On 2018-06-28 12:40, Nicolas Lesser wrote:
>
> There is a proposal to allow just that and it even allows for an
> allocation to "transcend" compile time evaluation.
>
> See P0784 for more info. It saw great encouragement in EWG.
>
>
> On Thu, Jun 28, 2018, 11:34 AM Avi Kivity <avi@scylladb.com> wrote:
>
>> Allowing dynamic allocations in constexpr context would allow using much
>> of the standard library in these contexts. I think it can be done if we
>> apply the following rule:
>>
>>
>> - a constexpr evaluation may not return an object containing
>> dynamically allocated memory
>>
>>
>> So the following works:
>>
>>
>> constexpr most_frequent(std::initializer_list<int> inputs) {
>>
>> std::unordered_map<int, int> frequencies;
>>
>> for (auto k : inputs) {
>>
>> frequencies[k] += 1;
>>
>> }
>>
>> auto it = std::max_element(frequencies.begin(),
>> frequencies.end(), ...);
>>
>> return it->first;
>>
>> }
>>
>>
>> char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1
>>
>>
>> because after evaluating the expression, all dynamically allocated
>> memory has been returned.
>>
>>
>> Internally, the compiler would have its constexpr operator new return an
>> unforgeable type-safe pointer (probably an index into an internal
>> table). The compiler will use constexpr versions of operator new and
>> operator delete, even if the program provides its own implementations.
>> When evaluation is complete, the compiler walks the object graph and
>> makes sure all pointers are null.
>>
>>
>> I see this was proposed in the past, but with a static_allocator, which
>> makes the feature harder to reuse by requiring that all user code be a
>> template on the allocator (if the user wishes to preserve dual use of
>> their code).
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0R4SuxAOZpHGLFRXA%3DYJV4AVYKs6frbrjaHVH9w_OjhQ%40mail.gmail.com.
--000000000000b3c070056fb0b12e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">You can check out <a href=3D"https://wg21.link">https://w=
g21.link</a>:<div dir=3D"auto"><br></div><div dir=3D"auto"><a href=3D"https=
://wg21.link/p0784">https://wg21.link/p0784</a></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jun 28, 2018, 11:48 AM Avi Kivity=
<<a href=3D"mailto:avi@scylladb.com">avi@scylladb.com</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>That's wonderful to hear. I see it's mentioned in the same b=
reath
as reflection, which is exactly the use case I had in mind. Things
like lex/yacc can be embedded into C++ code, so we'll never have
to leave the warm safety of the compiler, except to buy more RAM.<br>
</p>
<br>
I can't find the actual P0784 though, just references to it. Do you
have a link handy?<br>
<br>
<div class=3D"m_4667079210953332999moz-cite-prefix">On 2018-06-28 12:40=
, Nicolas Lesser
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"auto">
<div>There is a proposal to allow just that and it even allows
for an allocation to "transcend" compile time evaluatio=
n.
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">See P0784 for more info. It saw great
encouragement in EWG.</div>
<br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Jun 28, 2018, 11:34 AM Avi Kivity
<<a href=3D"mailto:avi@scylladb.com" target=3D"_blank" rel=
=3D"noreferrer">avi@scylladb.com</a>> wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Allowing
dynamic allocations in constexpr context would allow using
much <br>
of the standard library in these contexts. I think it can
be done if we <br>
apply the following rule:<br>
<br>
<br>
=C2=A0=C2=A0- a constexpr evaluation may not return an object
containing <br>
dynamically allocated memory<br>
<br>
<br>
So the following works:<br>
<br>
<br>
=C2=A0=C2=A0constexpr most_frequent(std::initializer_list<=
int>
inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unorder=
ed_map<int, int> frequencies;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (auto k =
: inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 frequencies[k] +=3D 1;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto it =3D =
std::max_element(frequencies.begin(), <br>
frequencies.end(), ...);<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return it-&g=
t;first;<br>
<br>
=C2=A0=C2=A0}<br>
<br>
<br>
char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1<br=
>
<br>
<br>
because after evaluating the expression, all dynamically
allocated <br>
memory has been returned.<br>
<br>
<br>
Internally, the compiler would have its constexpr operator
new return an <br>
unforgeable type-safe pointer (probably an index into an
internal <br>
table). The compiler will use constexpr versions of
operator new and <br>
operator delete, even if the program provides its own
implementations. <br>
When evaluation is complete, the compiler walks the object
graph and <br>
makes sure all pointers are null.<br>
<br>
<br>
I see this was proposed in the past, but with a
static_allocator, which <br>
makes the feature harder to reuse by requiring that all
user code be a <br>
template on the allocator (if the user wishes to preserve
dual use of <br>
their code).<br>
<br>
-- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals&q=
uot;
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"mailto:std-proposals%2Bu=
nsubscribe@isocpp.org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-pr=
oposals@isocpp.org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-pro=
posals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f8=
-9b1d37c20596%40scylladb.com" rel=3D"noreferrer noreferrer noreferrer" targ=
et=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/=
7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com</a>.<br>
</blockquote>
</div>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.o=
rg" target=3D"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.o=
rg</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4B=
a1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrz=
udSWwQ%40mail.gmail.com</a>.<br>
</blockquote>
<br>
</div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq0R4SuxAOZpHGLFRXA%3DYJV4AVYKs6=
frbrjaHVH9w_OjhQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0R4SuxAO=
ZpHGLFRXA%3DYJV4AVYKs6frbrjaHVH9w_OjhQ%40mail.gmail.com</a>.<br />
--000000000000b3c070056fb0b12e--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Thu, 28 Jun 2018 13:03:21 +0300
Raw View
This is a multi-part message in MIME format.
--------------3AA47BE2BB467B369F0347F0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Thanks! Hoping this gets in.
On 2018-06-28 12:52, Nicolas Lesser wrote:
> You can check out https://wg21.link:
>
> https://wg21.link/p0784
>
> On Thu, Jun 28, 2018, 11:48 AM Avi Kivity <avi@scylladb.com=20
> <mailto:avi@scylladb.com>> wrote:
>
> That's wonderful to hear. I see it's mentioned in the same breath
> as reflection, which is exactly the use case I had in mind. Things
> like lex/yacc can be embedded into C++ code, so we'll never have
> to leave the warm safety of the compiler, except to buy more RAM.
>
>
> I can't find the actual P0784 though, just references to it. Do
> you have a link handy?
>
> On 2018-06-28 12:40, Nicolas Lesser wrote:
>> There is a proposal to allow just that and it even allows for an
>> allocation to "transcend" compile time evaluation.
>>
>> See P0784 for more info. It saw great encouragement in EWG.
>>
>>
>> On Thu, Jun 28, 2018, 11:34 AM Avi Kivity <avi@scylladb.com
>> <mailto:avi@scylladb.com>> wrote:
>>
>> Allowing dynamic allocations in constexpr context would allow
>> using much
>> of the standard library in these contexts. I think it can be
>> done if we
>> apply the following rule:
>>
>>
>> =C2=A0=C2=A0- a constexpr evaluation may not return an object co=
ntaining
>> dynamically allocated memory
>>
>>
>> So the following works:
>>
>>
>> =C2=A0=C2=A0constexpr most_frequent(std::initializer_list<int> i=
nputs) {
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unordered_=
map<int, int> frequencies;
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (auto k : i=
nputs) {
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 frequencies[k] +=3D 1;
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto it =3D std=
::max_element(frequencies.begin(),
>> frequencies.end(), ...);
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return it->firs=
t;
>>
>> =C2=A0=C2=A0}
>>
>>
>> char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1
>>
>>
>> because after evaluating the expression, all dynamically
>> allocated
>> memory has been returned.
>>
>>
>> Internally, the compiler would have its constexpr operator
>> new return an
>> unforgeable type-safe pointer (probably an index into an
>> internal
>> table). The compiler will use constexpr versions of operator
>> new and
>> operator delete, even if the program provides its own
>> implementations.
>> When evaluation is complete, the compiler walks the object
>> graph and
>> makes sure all pointers are null.
>>
>>
>> I see this was proposed in the past, but with a
>> static_allocator, which
>> makes the feature harder to reuse by requiring that all user
>> code be a
>> template on the allocator (if the user wishes to preserve
>> dual use of
>> their code).
>>
>> --=20
>> You received this message because you are subscribed to the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7=
255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com.
>>
>> --=20
>> You received this message because you are subscribed to the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq=
1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDw=
q1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/559291d2-20f0-0ecd-b26f-7a328f167c36%40scylladb.=
com.
--------------3AA47BE2BB467B369F0347F0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>Thanks! Hoping this gets in.<br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 2018-06-28 12:52, Nicolas Lesser
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CALmDwq0R4SuxAOZpHGLFRXA=3DYJV4AVYKs6frbrjaHVH9w_OjhQ@mail.gmai=
l.com">
<div dir=3D"auto">You can check out <a href=3D"https://wg21.link"
moz-do-not-send=3D"true">https://wg21.link</a>:
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><a href=3D"https://wg21.link/p0784"
moz-do-not-send=3D"true">https://wg21.link/p0784</a></div>
</div>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Jun 28, 2018, 11:48 AM Avi Kivity <<a
href=3D"mailto:avi@scylladb.com" moz-do-not-send=3D"true">avi@s=
cylladb.com</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>That's wonderful to hear. I see it's mentioned in the
same breath as reflection, which is exactly the use case I
had in mind. Things like lex/yacc can be embedded into C++
code, so we'll never have to leave the warm safety of the
compiler, except to buy more RAM.<br>
</p>
<br>
I can't find the actual P0784 though, just references to it.
Do you have a link handy?<br>
<br>
<div class=3D"m_4667079210953332999moz-cite-prefix">On
2018-06-28 12:40, Nicolas Lesser wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"auto">
<div>There is a proposal to allow just that and it even
allows for an allocation to "transcend" compile time
evaluation.
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">See P0784 for more info. It saw great
encouragement in EWG.</div>
<br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Jun 28, 2018, 11:34 AM Avi
Kivity <<a href=3D"mailto:avi@scylladb.com"
target=3D"_blank" rel=3D"noreferrer"
moz-do-not-send=3D"true">avi@scylladb.com</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">All=
owing
dynamic allocations in constexpr context would
allow using much <br>
of the standard library in these contexts. I think
it can be done if we <br>
apply the following rule:<br>
<br>
<br>
=C2=A0=C2=A0- a constexpr evaluation may not return a=
n
object containing <br>
dynamically allocated memory<br>
<br>
<br>
So the following works:<br>
<br>
<br>
=C2=A0=C2=A0constexpr
most_frequent(std::initializer_list<int>
inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std:=
:unordered_map<int, int>
frequencies;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for =
(auto k : inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 frequencies[k] +=3D 1;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br=
>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto=
it =3D
std::max_element(frequencies.begin(), <br>
frequencies.end(), ...);<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 retu=
rn it->first;<br>
<br>
=C2=A0=C2=A0}<br>
<br>
<br>
char a[most_frequent({1, 1, 3, 1, 5})]; // array
of size 1<br>
<br>
<br>
because after evaluating the expression, all
dynamically allocated <br>
memory has been returned.<br>
<br>
<br>
Internally, the compiler would have its constexpr
operator new return an <br>
unforgeable type-safe pointer (probably an index
into an internal <br>
table). The compiler will use constexpr versions
of operator new and <br>
operator delete, even if the program provides its
own implementations. <br>
When evaluation is complete, the compiler walks
the object graph and <br>
makes sure all pointers are null.<br>
<br>
<br>
I see this was proposed in the past, but with a
static_allocator, which <br>
makes the feature harder to reuse by requiring
that all user code be a <br>
template on the allocator (if the user wishes to
preserve dual use of <br>
their code).<br>
<br>
-- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++ Standard
- Future Proposals" group.<br>
To unsubscribe from this group and stop receiving
emails from it, send an email to <a
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.o=
rg"
rel=3D"noreferrer noreferrer" target=3D"_blank"
moz-do-not-send=3D"true">std-proposals+unsubscribe@=
isocpp.org</a>.<br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org"
rel=3D"noreferrer noreferrer" target=3D"_blank"
moz-do-not-send=3D"true">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255=
d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com"
rel=3D"noreferrer noreferrer noreferrer"
target=3D"_blank" moz-do-not-send=3D"true">https://=
groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8aaa-a6f=
8-9b1d37c20596%40scylladb.com</a>.<br>
</blockquote>
</div>
</div>
</div>
-- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals"
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
target=3D"_blank" rel=3D"noreferrer" moz-do-not-send=3D"tru=
e">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank"
rel=3D"noreferrer" moz-do-not-send=3D"true">std-proposals@i=
socpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDw=
q1Jg5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter"
target=3D"_blank" rel=3D"noreferrer" moz-do-not-send=3D"tru=
e">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5=
u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com</a>.<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/559291d2-20f0-0ecd-b26f-7a328f167c36%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/559291d2-20f0-0ecd-b26f-7a328f167c=
36%40scylladb.com</a>.<br />
--------------3AA47BE2BB467B369F0347F0--
.
Author: Daniel Gutson <danielgutson@gmail.com>
Date: Thu, 28 Jun 2018 07:51:40 -0300
Raw View
--000000000000e2977b056fb1840c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
FWIW we did a gcc prototype in 2012 for embedded systems where space is
small and initialization time had to be also small, so STL containers got
in ROM already processed (e.g. hashes and trees). We even could allow a
variant of std::array wheee it didn't require the jumber of elements.
I'm not familiar with the current proposal but the prototype is usable.
El jue., 28 de junio de 2018 7:03, Avi Kivity <avi@scylladb.com> escribi=C3=
=B3:
> Thanks! Hoping this gets in.
>
> On 2018-06-28 12:52, Nicolas Lesser wrote:
>
> You can check out https://wg21.link:
>
> https://wg21.link/p0784
>
> On Thu, Jun 28, 2018, 11:48 AM Avi Kivity <avi@scylladb.com> wrote:
>
>> That's wonderful to hear. I see it's mentioned in the same breath as
>> reflection, which is exactly the use case I had in mind. Things like
>> lex/yacc can be embedded into C++ code, so we'll never have to leave the
>> warm safety of the compiler, except to buy more RAM.
>>
>> I can't find the actual P0784 though, just references to it. Do you have
>> a link handy?
>>
>> On 2018-06-28 12:40, Nicolas Lesser wrote:
>>
>> There is a proposal to allow just that and it even allows for an
>> allocation to "transcend" compile time evaluation.
>>
>> See P0784 for more info. It saw great encouragement in EWG.
>>
>>
>> On Thu, Jun 28, 2018, 11:34 AM Avi Kivity <avi@scylladb.com> wrote:
>>
>>> Allowing dynamic allocations in constexpr context would allow using muc=
h
>>> of the standard library in these contexts. I think it can be done if we
>>> apply the following rule:
>>>
>>>
>>> - a constexpr evaluation may not return an object containing
>>> dynamically allocated memory
>>>
>>>
>>> So the following works:
>>>
>>>
>>> constexpr most_frequent(std::initializer_list<int> inputs) {
>>>
>>> std::unordered_map<int, int> frequencies;
>>>
>>> for (auto k : inputs) {
>>>
>>> frequencies[k] +=3D 1;
>>>
>>> }
>>>
>>> auto it =3D std::max_element(frequencies.begin(),
>>> frequencies.end(), ...);
>>>
>>> return it->first;
>>>
>>> }
>>>
>>>
>>> char a[most_frequent({1, 1, 3, 1, 5})]; // array of size 1
>>>
>>>
>>> because after evaluating the expression, all dynamically allocated
>>> memory has been returned.
>>>
>>>
>>> Internally, the compiler would have its constexpr operator new return a=
n
>>> unforgeable type-safe pointer (probably an index into an internal
>>> table). The compiler will use constexpr versions of operator new and
>>> operator delete, even if the program provides its own implementations.
>>> When evaluation is complete, the compiler walks the object graph and
>>> makes sure all pointers are null.
>>>
>>>
>>> I see this was proposed in the past, but with a static_allocator, which
>>> makes the feature harder to reuse by requiring that all user code be a
>>> template on the allocator (if the user wishes to preserve dual use of
>>> their code).
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-9=
4d4-8aaa-a6f8-9b1d37c20596%40scylladb.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5=
u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg=
5u8ngVOJxdVrv0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/559291d2-20f=
0-0ecd-b26f-7a328f167c36%40scylladb.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/559291d2-20=
f0-0ecd-b26f-7a328f167c36%40scylladb.com?utm_medium=3Demail&utm_source=3Dfo=
oter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-0Y%2BtBAjZ8XiGHxJpEj7WrU1E8rK_%3D9%2BA9sk=
tMyUb-m2g%40mail.gmail.com.
--000000000000e2977b056fb1840c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">FWIW we did a gcc prototype in 2012 for embedded systems =
where space is small and initialization time had to be also small, so STL c=
ontainers got in ROM already processed (e.g. hashes and trees). We even cou=
ld allow a variant of std::array wheee it didn't require the jumber of =
elements.<div dir=3D"auto">I'm not familiar with the current proposal b=
ut the prototype is usable.</div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr">El jue., 28 de junio de 2018 7:03, Avi Kivity <<a href=3D"ma=
ilto:avi@scylladb.com">avi@scylladb.com</a>> escribi=C3=B3:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>Thanks! Hoping this gets in.<br>
</p>
<br>
<div class=3D"m_6638829690123626572moz-cite-prefix">On 2018-06-28 12:52=
, Nicolas Lesser
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"auto">You can check out <a href=3D"https://wg21.link" tar=
get=3D"_blank" rel=3D"noreferrer">https://wg21.link</a>:
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><a href=3D"https://wg21.link/p0784" target=3D"_bl=
ank" rel=3D"noreferrer">https://wg21.link/p0784</a></div>
</div>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Jun 28, 2018, 11:48 AM Avi Kivity <<a h=
ref=3D"mailto:avi@scylladb.com" target=3D"_blank" rel=3D"noreferrer">avi@sc=
ylladb.com</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>That's wonderful to hear. I see it's mentioned in th=
e
same breath as reflection, which is exactly the use case I
had in mind. Things like lex/yacc can be embedded into C++
code, so we'll never have to leave the warm safety of the
compiler, except to buy more RAM.<br>
</p>
<br>
I can't find the actual P0784 though, just references to it=
..
Do you have a link handy?<br>
<br>
<div class=3D"m_6638829690123626572m_4667079210953332999moz-cit=
e-prefix">On
2018-06-28 12:40, Nicolas Lesser wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"auto">
<div>There is a proposal to allow just that and it even
allows for an allocation to "transcend" compile=
time
evaluation.
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">See P0784 for more info. It saw great
encouragement in EWG.</div>
<br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Jun 28, 2018, 11:34 AM Avi
Kivity <<a href=3D"mailto:avi@scylladb.com" rel=3D=
"noreferrer noreferrer" target=3D"_blank">avi@scylladb.com</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">Allowing
dynamic allocations in constexpr context would
allow using much <br>
of the standard library in these contexts. I think
it can be done if we <br>
apply the following rule:<br>
<br>
<br>
=C2=A0=C2=A0- a constexpr evaluation may not return a=
n
object containing <br>
dynamically allocated memory<br>
<br>
<br>
So the following works:<br>
<br>
<br>
=C2=A0=C2=A0constexpr
most_frequent(std::initializer_list<int>
inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std:=
:unordered_map<int, int>
frequencies;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for =
(auto k : inputs) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 frequencies[k] +=3D 1;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br=
>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto=
it =3D
std::max_element(frequencies.begin(), <br>
frequencies.end(), ...);<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 retu=
rn it->first;<br>
<br>
=C2=A0=C2=A0}<br>
<br>
<br>
char a[most_frequent({1, 1, 3, 1, 5})]; // array
of size 1<br>
<br>
<br>
because after evaluating the expression, all
dynamically allocated <br>
memory has been returned.<br>
<br>
<br>
Internally, the compiler would have its constexpr
operator new return an <br>
unforgeable type-safe pointer (probably an index
into an internal <br>
table). The compiler will use constexpr versions
of operator new and <br>
operator delete, even if the program provides its
own implementations. <br>
When evaluation is complete, the compiler walks
the object graph and <br>
makes sure all pointers are null.<br>
<br>
<br>
I see this was proposed in the past, but with a
static_allocator, which <br>
makes the feature harder to reuse by requiring
that all user code be a <br>
template on the allocator (if the user wishes to
preserve dual use of <br>
their code).<br>
<br>
-- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++ Standar=
d
- Future Proposals" group.<br>
To unsubscribe from this group and stop receiving
emails from it, send an email to <a href=3D"mailto:st=
d-proposals%2Bunsubscribe@isocpp.org" rel=3D"noreferrer noreferrer noreferr=
er" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailt=
o:std-proposals@isocpp.org" rel=3D"noreferrer noreferrer noreferrer" target=
=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7c7255d5-94d4-8=
aaa-a6f8-9b1d37c20596%40scylladb.com" rel=3D"noreferrer noreferrer noreferr=
er noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/7c7255d5-94d4-8aaa-a6f8-9b1d37c20596%40scylladb.com</a>.=
<br>
</blockquote>
</div>
</div>
</div>
-- <br>
You received this message because you are subscribed to
the Google Groups "ISO C++ Standard - Future Proposals&q=
uot;
group.<br>
To unsubscribe from this group and stop receiving emails
from it, send an email to <a href=3D"mailto:std-proposals+uns=
ubscribe@isocpp.org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-pr=
oposals@isocpp.org" rel=3D"noreferrer noreferrer" target=3D"_blank">std-pro=
posals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv=
0fCZzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com?utm_medium=3Demail&utm_so=
urce=3Dfooter" rel=3D"noreferrer noreferrer" target=3D"_blank">https://grou=
ps.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1Jg5u8ngVOJxdVrv0fC=
Zzs4Ba1Hw_yGKaLxfrzudSWwQ%40mail.gmail.com</a>.<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/559291d2-20f0-0ecd-b26f-7a328f167c36%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank=
" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/559291d2-20f0-0ecd-b26f-7a328f167c36%40scylladb.com</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0Y%2BtBAjZ8XiGHxJpEj7WrU1E8rK_=
%3D9%2BA9sktMyUb-m2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0Y%2=
BtBAjZ8XiGHxJpEj7WrU1E8rK_%3D9%2BA9sktMyUb-m2g%40mail.gmail.com</a>.<br />
--000000000000e2977b056fb1840c--
.