------=_Part_757_765626005.1439920295059
Content-Type: multipart/alternative;
 boundary="----=_Part_758_252001204.1439920295059"

------=_Part_758_252001204.1439920295059
Content-Type: text/plain; charset=UTF-8

Is there also a `static_dealloc` to go along with that? Or is it not
allowed to create a std::string/vector/etc as a temporary?

Also, how do you detect when to use the `static_alloc` allocator and when
not to? Generally speaking, as I understand it, there is no mechanism in
C++ (yet) that allows you to detect when the compiler is
really-truly-honest-to-God executing your code at compile time and when it
isn't. After all, you can call those constexpr constructors at
non-constexpr times too.

--

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

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

<div dir=3D"ltr">Is there also a `static_dealloc` to go along with that? Or=
 is it not allowed to create a std::string/vector/etc as a temporary?<br><b=
r>Also, how do you detect when to use the `static_alloc` allocator and when=
 not to? Generally speaking, as I understand it, there is no mechanism in C=
++ (yet) that allows you to detect when the compiler is really-truly-honest=
-to-God executing your code at compile time and when it isn&#39;t. After al=
l, you can call those constexpr constructors at non-constexpr times too.<br=
></div>

<p></p>

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

------=_Part_758_252001204.1439920295059--
------=_Part_757_765626005.1439920295059--

.

------=_Part_5146_318584516.1439954023668
Content-Type: multipart/alternative;
 boundary="----=_Part_5147_936559967.1439954023668"

------=_Part_5147_936559967.1439954023668
Content-Type: text/plain; charset=UTF-8

This is very exciting work.  I'd like to echo the sentiment from others as
well that making new/delete, std::allocator (and possibly malloc/free) work
at compile-time rather than requiring a compile-time-specific allocation
call, so that there is no need for special compile-time container classes
in the standard library, would enable a lot more use cases.  It seems if
the compiler determines that references to a compile-time allocation
survives to runtime, then it would have to do something special (either
arrange for it to be copied to the runtime heap during program
initialization, or ensure that the deallocation function knows to ignore
pointers to these memory regions), but this seems quite solvable.  This
would allow almost all of C++ to be used at compile-time (and perhaps
correspondingly it would make sense to eliminate the requirement of
annotating functions with the constexpr keyword).  If there is a need for a
compile-time-only allocator that ensures the data is stored in ROM, it
could be provided as e.g. std::static_allocator that could be used with any
of the standard containers, so that there would still be no need for
different container classes.

On Tuesday, August 18, 2015 at 9:51:06 AM UTC-7, dgutson wrote:
>
> Hi.
>
> We are working in a custom gcc (plus a plugin) which is able to
> "statically allocate" memory and modify its content during constexpr
> constructors.
> We basically provide a "static_alloc<T>(size_t n)" function for this
> purpose.
> With this infrastructure, we were able to write two examples:
> - an uppercase_static_string class that receives a C-string in its
> constexpr ctor, allocates a (const) char array, copies the content
> transforming all the
> characters to uppercase. The whole object is stored in the .rodata
> section of the binary. The access methods are a subset of the const of
> the std::string.
> - a static_sorted_array class that receives an initializer_list<int>,
> allocates the content and sorts it. The resulting array also is stored
> in the .rodata section.
>
> We are working towards applying the same infrastructure for
> non-constant objects (of static storage duration) as a superior
> solution to
> allocators with pre-allocated memory pools, since the exact required
> memory is calculated during compile time and out-of-memory detection
> can cause a compilation failure.
>
> This work is mainly inspired by embedded and safety systems needs, and
> has relation with Andrew's "predynamic storage".
>
> As for our need, we have to provide a "static" version of some STL
> containers, though a deeper analysis has to be done in order to
> see if this infrastructure (or the "static_alloc" direction) could be
> applied to the current STL containers by adding new constexpr
> constructors
> (I don't think it's possible, but I didn't get into it yet).
>
> If there are people attending the forthcoming meetings interested in
> championship this and being a co-author, please let me know (PM) and
> we
> will provide details and the prototype (which is actively under
> development in order to overcome two implementation issues). We are
> also
> looking for help to implement the static containers (we will implement
> only the unordered_map and multiset counterparts).
>
> What is going to happen soon is: we will send some patches to gcc and
> I will write a technical report about this with details.
>
>

--

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

<div dir=3D"ltr">This is very exciting work.=C2=A0 I&#39;d like to echo the=
 sentiment from others as well that making new/delete, std::allocator (and =
possibly malloc/free) work at compile-time rather than requiring a compile-=
time-specific allocation call, so that there is no need for special compile=
-time container classes in the standard library, would enable a lot more us=
e cases.=C2=A0 It seems if the compiler determines that references to a com=
pile-time allocation survives to runtime, then it would have to do somethin=
g special (either arrange for it to be copied to the runtime heap during pr=
ogram initialization, or ensure that the deallocation function knows to ign=
ore pointers to these memory regions), but this seems quite solvable.=C2=A0=
 This would allow almost all of C++ to be used at compile-time (and perhaps=
 correspondingly it would make sense to eliminate the requirement of annota=
ting functions with the constexpr keyword).=C2=A0 If there is a need for a =
compile-time-only allocator that ensures the data is stored in ROM, it coul=
d be provided as e.g. std::static_allocator that could be used with any of =
the standard containers, so that there would still be no need for different=
 container classes.<br><br>On Tuesday, August 18, 2015 at 9:51:06 AM UTC-7,=
 dgutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi.
<br>
<br>We are working in a custom gcc (plus a plugin) which is able to
<br>&quot;statically allocate&quot; memory and modify its content during co=
nstexpr
<br>constructors.
<br>We basically provide a &quot;static_alloc&lt;T&gt;(size_t n)&quot; func=
tion for this purpose.
<br>With this infrastructure, we were able to write two examples:
<br>- an uppercase_static_string class that receives a C-string in its
<br>constexpr ctor, allocates a (const) char array, copies the content
<br>transforming all the
<br>characters to uppercase. The whole object is stored in the .rodata
<br>section of the binary. The access methods are a subset of the const of
<br>the std::string.
<br>- a static_sorted_array class that receives an initializer_list&lt;int&=
gt;,
<br>allocates the content and sorts it. The resulting array also is stored
<br>in the .rodata section.
<br>
<br>We are working towards applying the same infrastructure for
<br>non-constant objects (of static storage duration) as a superior
<br>solution to
<br>allocators with pre-allocated memory pools, since the exact required
<br>memory is calculated during compile time and out-of-memory detection
<br>can cause a compilation failure.
<br>
<br>This work is mainly inspired by embedded and safety systems needs, and
<br>has relation with Andrew&#39;s &quot;predynamic storage&quot;.
<br>
<br>As for our need, we have to provide a &quot;static&quot; version of som=
e STL
<br>containers, though a deeper analysis has to be done in order to
<br>see if this infrastructure (or the &quot;static_alloc&quot; direction) =
could be
<br>applied to the current STL containers by adding new constexpr
<br>constructors
<br>(I don&#39;t think it&#39;s possible, but I didn&#39;t get into it yet)=
..
<br>
<br>If there are people attending the forthcoming meetings interested in
<br>championship this and being a co-author, please let me know (PM) and
<br>we
<br>will provide details and the prototype (which is actively under
<br>development in order to overcome two implementation issues). We are
<br>also
<br>looking for help to implement the static containers (we will implement
<br>only the unordered_map and multiset counterparts).
<br>
<br>What is going to happen soon is: we will send some patches to gcc and
<br>I will write a technical report about this with details.
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_5147_936559967.1439954023668--
------=_Part_5146_318584516.1439954023668--

.