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

I was thinking about the possibility of
=20
=20
 void* operator new (std::size_t size, const std::stack_t& stack_value);

=20
to allocate memory on the stack, instead of the free store, in a similar=20
way to the GNU alloca() works.  There are a couple of issues that I don=E2=
=80=99t=20
know the best way of resolving, though:
=20
* How to maintain RAII
=20
* How to handle uncaught exceptions.

--=20

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

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

<div dir=3D"ltr"><DIV>I was thinking about the possibility of</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>void</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>*=
</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN=
 style=3D"COLOR: #008" class=3Dstyled-by-prettify>operator</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: =
#008" class=3Dstyled-by-prettify>new</SPAN><SPAN style=3D"COLOR: #000" clas=
s=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-b=
y-prettify>(</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>s=
td</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>::</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>size_t size</SPAN><SPA=
N style=3D"COLOR: #660" class=3Dstyled-by-prettify>,</SPAN><SPAN style=3D"C=
OLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" =
class=3Dstyled-by-prettify>const</SPAN><SPAN style=3D"COLOR: #000" class=3D=
styled-by-prettify> std</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by=
-prettify>::</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>s=
tack_t</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>&amp;</=
SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> stack_value</S=
PAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>);</SPAN></DIV><=
/CODE></DIV><BR>
<DIV>&nbsp;</DIV>
<DIV>to allocate memory on the stack, instead of the free store, in a simil=
ar way to the GNU alloca() works.&nbsp; There are a couple of issues that I=
 don=E2=80=99t know the best way of resolving, though:</DIV>
<DIV>&nbsp;</DIV>
<DIV>* How to maintain RAII</DIV>
<DIV>&nbsp;</DIV>
<DIV>* How to handle uncaught exceptions.</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_2074_1028834461.1415016048707--

.

------=_Part_171_102152140.1415016205770
Content-Type: text/plain; charset=UTF-8

I forgot to mention that there should be a variable std::stack of type
std::stack_t, in a similar way to having std::nothrow of type
std::nothrow_t.

--

---
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_171_102152140.1415016205770
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I forgot to mention that there should be a variable std::stack of type std::stack_t, in a similar way to having std::nothrow of type std::nothrow_t.</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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_171_102152140.1415016205770--

.

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

I don't particularly love the idea, but this is unrelated: 'std::stack' is
a stack (LIFO queue) in the standard.

On Mon, Nov 3, 2014 at 7:03 AM, Douglas Boffey <douglas.boffey@gmail.com>
wrote:

> I forgot to mention that there should be a variable std::stack of type
> std::stack_t, in a similar way to having std::nothrow of type
> std::nothrow_t.
>
> --
>
> ---
> 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/.
>

--

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

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

<div dir=3D"ltr">I don&#39;t particularly love the idea, but this is unrela=
ted: &#39;std::stack&#39; is a stack (LIFO queue) in the standard.</div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov 3, 2014 =
at 7:03 AM, Douglas Boffey <span dir=3D"ltr">&lt;<a href=3D"mailto:douglas.=
boffey@gmail.com" target=3D"_blank">douglas.boffey@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I forgot to ment=
ion that there should be a variable std::stack of type std::stack_t, in a s=
imilar way to having std::nothrow of type std::nothrow_t.</div><div class=
=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">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">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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 />

--e89a8f502982996cff0506f48ee1--

.

--Apple-Mail=_D5665DF3-3660-4B53-8FCE-A97FFE15C96F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9303, at 6:00 AM, Douglas Boffey <douglas.boffey@g=
mail.com> wrote:

> I was thinking about the possibility of
> =20
> =20
> void* operator new (std::size_t size, const std::stack_t& stack_value);
>=20
> =20
> to allocate memory on the stack, instead of the free store, in a similar =
way to the GNU alloca() works.  There are a couple of issues that I don=E2=
=80=99t know the best way of resolving, though:
> =20
> * How to maintain RAII
> =20
> * How to handle uncaught exceptions.

This basically comes down to a variant class, such as boost::variant. You d=
on=E2=80=99t really want alloca if there=E2=80=99s a strict upper bound to =
the size. And, direct use of new is best avoided.

It=E2=80=99s possible to parameterize a variant class on the maximum size a=
nd then use an indirect call to handle destruction. Like boost::any but wit=
h a =E2=80=9Csmall-object optimization.=E2=80=9D

--=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=_D5665DF3-3660-4B53-8FCE-A97FFE15C96F
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9303, at 6:00 AM, Douglas Boffey &lt;<a href=3D"mailto:do=
uglas.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr=
"><div>I was thinking about the possibility of</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3D"prettyprint"><code class=3D"pretty=
print">
<div class=3D"subprettyprint"><span style=3D"COLOR: #008" class=3D"styled-b=
y-prettify">void</span><span style=3D"COLOR: #660" class=3D"styled-by-prett=
ify">*</span><span style=3D"" class=3D"styled-by-prettify"> </span><span st=
yle=3D"COLOR: #008" class=3D"styled-by-prettify">operator</span><span style=
=3D"" class=3D"styled-by-prettify"> </span><span style=3D"COLOR: #008" clas=
s=3D"styled-by-prettify">new</span><span style=3D"" class=3D"styled-by-pret=
tify"> </span><span style=3D"COLOR: #660" class=3D"styled-by-prettify">(</s=
pan><span style=3D"" class=3D"styled-by-prettify">std</span><span style=3D"=
COLOR: #660" class=3D"styled-by-prettify">::</span><span style=3D"" class=
=3D"styled-by-prettify">size_t size</span><span style=3D"COLOR: #660" class=
=3D"styled-by-prettify">,</span><span style=3D"" class=3D"styled-by-prettif=
y"> </span><span style=3D"COLOR: #008" class=3D"styled-by-prettify">const</=
span><span style=3D"" class=3D"styled-by-prettify"> std</span><span style=
=3D"COLOR: #660" class=3D"styled-by-prettify">::</span><span style=3D"" cla=
ss=3D"styled-by-prettify">stack_t</span><span style=3D"COLOR: #660" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"" class=3D"styled-by-pre=
ttify"> stack_value</span><span style=3D"COLOR: #660" class=3D"styled-by-pr=
ettify">);</span></div></code></div><br>
<div>&nbsp;</div>
<div>to allocate memory on the stack, instead of the free store, in a simil=
ar way to the GNU alloca() works.&nbsp; There are a couple of issues that I=
 don=E2=80=99t know the best way of resolving, though:</div>
<div>&nbsp;</div>
<div>* How to maintain RAII</div>
<div>&nbsp;</div>
<div>* How to handle uncaught exceptions.</div></div></blockquote><div><br>=
</div><div>This basically comes down to a variant class, such as <font face=
=3D"Courier">boost::variant</font>. You don=E2=80=99t really want <font fac=
e=3D"Courier">alloca</font> if there=E2=80=99s a strict upper bound to the =
size. And, direct use of&nbsp;<font face=3D"Courier">new</font> is best avo=
ided.</div><div><br></div><div>It=E2=80=99s possible to parameterize a vari=
ant class on the maximum size and then use an indirect call to handle destr=
uction. Like <font face=3D"Courier">boost::any</font> but with a =E2=80=9Cs=
mall-object optimization.=E2=80=9D</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=_D5665DF3-3660-4B53-8FCE-A97FFE15C96F--

.

--part3534-boundary-1770165328-1907091916
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Could you please explain the motivation of this feature? Just because in a =
library is not a motivation itself.
-----Original Message-----
From: Douglas Boffey <douglas.boffey@gmail.com>
Date: Mon, 3 Nov 2014 04:00:48=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: [std-proposals] new (stack)

I was thinking about the possibility of
=20
=20
 void* operator new (std::size_t size, const std::stack_t& stack_value);

=20
to allocate memory on the stack, instead of the free store, in a similar=20
way to the GNU alloca() works.  There are a couple of issues that I don=E2=
=80=99t=20
know the best way of resolving, though:
=20
* How to maintain RAII
=20
* How to handle uncaught exceptions.

--=20

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

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

--part3534-boundary-1770165328-1907091916
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>Could you please explain the motivation of this feature? Just bec=
ause in a library is not a motivation itself.<hr/><div><b>From: </b> Dougla=
s Boffey &lt;douglas.boffey@gmail.com&gt;
</div><div><b>Date: </b>Mon, 3 Nov 2014 04:00:48 -0800 (PST)</div><div><b>T=
o: </b>&lt;std-proposals@isocpp.org&gt;</div><div><b>ReplyTo: </b> std-prop=
osals@isocpp.org
</div><div><b>Subject: </b>[std-proposals] new (stack)</div><div><br/></div=
><div dir=3D"ltr"><DIV>I was thinking about the possibility of</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>void</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>*=
</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN=
 style=3D"COLOR: #008" class=3Dstyled-by-prettify>operator</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: =
#008" class=3Dstyled-by-prettify>new</SPAN><SPAN style=3D"COLOR: #000" clas=
s=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-b=
y-prettify>(</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>s=
td</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>::</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>size_t size</SPAN><SPA=
N style=3D"COLOR: #660" class=3Dstyled-by-prettify>,</SPAN><SPAN style=3D"C=
OLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" =
class=3Dstyled-by-prettify>const</SPAN><SPAN style=3D"COLOR: #000" class=3D=
styled-by-prettify> std</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by=
-prettify>::</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>s=
tack_t</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>&amp;</=
SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> stack_value</S=
PAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>);</SPAN></DIV><=
/CODE></DIV><BR>
<DIV>&nbsp;</DIV>
<DIV>to allocate memory on the stack, instead of the free store, in a simil=
ar way to the GNU alloca() works.&nbsp; There are a couple of issues that I=
 don=E2=80=99t know the best way of resolving, though:</DIV>
<DIV>&nbsp;</DIV>
<DIV>* How to maintain RAII</DIV>
<DIV>&nbsp;</DIV>
<DIV>* How to handle uncaught exceptions.</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 />

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

--part3534-boundary-1770165328-1907091916--


.

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



On Tuesday, November 4, 2014 1:00:48 AM UTC+13, Douglas Boffey wrote:
>
> I was thinking about the possibility of
> =20
> =20
>  void* operator new (std::size_t size, const std::stack_t& stack_value);
>
> =20
> to allocate memory on the stack, instead of the free store, in a similar=
=20
> way to the GNU alloca() works.  There are a couple of issues that I don=
=E2=80=99t=20
> know the best way of resolving, though:
> =20
> * How to maintain RAII
> =20
> * How to handle uncaught exceptions.
>


Generally a bit more control of the stack would be nice, so on the one hand=
=20
I think it's a good discussion I'd like to see happen.
On the other hand, it seems a dangerous area to play in, so perhaps we=20
shouldn't encourage it by making it standard..

But if there is support for more stack control, perhaps something like what=
=20
you have proposed is ok but maybe something that switches to the heap in=20
the event of near exhaustion or on a certain usage amount like on n% of the=
=20
heap used or whatever.

Things like a standard allocator that could be passed to things like=20
std::vector that worked like a simple stack arena, but that could be=20
parameterized to not chew up all the stack, but start using the heap if=20
more than n bytes of the stack get used or something could be something to=
=20
consider. It'd be good to consider how whatever proposed could be used to=
=20
implement such features at least.

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

<div dir=3D"ltr"><br><br>On Tuesday, November 4, 2014 1:00:48 AM UTC+13, Do=
uglas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>I was=
 thinking about the possibility of</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 136);">void</span><span style=3D"color=
: rgb(102, 102, 0);">*</span><span style=3D"color: rgb(0, 0, 0);"> </span><=
span style=3D"color: rgb(0, 0, 136);">operator</span><span style=3D"color: =
rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">new</span><sp=
an style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 10=
2, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">std</span><span style=
=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, 0);"=
>size_t size</span><span style=3D"color: rgb(102, 102, 0);">,</span><span s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);=
">const</span><span style=3D"color: rgb(0, 0, 0);"> std</span><span style=
=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, 0);"=
>stack_t</span><span style=3D"color: rgb(102, 102, 0);">&amp;</span><span s=
tyle=3D"color: rgb(0, 0, 0);"> stack_value</span><span style=3D"color: rgb(=
102, 102, 0);">);</span></div></code></div><br>
<div>&nbsp;</div>
<div>to allocate memory on the stack, instead of the free store, in a simil=
ar way to the GNU alloca() works.&nbsp; There are a couple of issues that I=
 don=E2=80=99t know the best way of resolving, though:</div>
<div>&nbsp;</div>
<div>* How to maintain RAII</div>
<div>&nbsp;</div>
<div>* How to handle uncaught exceptions.</div></div></blockquote><div><br>=
</div><div><br></div><div><div>Generally a bit more control of the stack wo=
uld be nice, so on the one hand I think it's a good discussion I'd like to =
see happen.</div><div>On the other hand, it seems a dangerous area to play =
in,&nbsp;so perhaps we shouldn't&nbsp;encourage it by making it standard..<=
/div><div><br></div></div><div>But if there is support for more stack contr=
ol, perhaps something like what you have proposed is ok&nbsp;but maybe some=
thing that switches to the heap in the event of near exhaustion or on a cer=
tain usage amount like on n% of the heap used or whatever.</div><div><br></=
div><div>Things&nbsp;like&nbsp;a standard&nbsp;allocator&nbsp;that could be=
 passed to things like std::vector&nbsp;that worked like a simple stack are=
na, but&nbsp;that could be parameterized to not chew up all the stack, but =
start using the heap if more than n bytes&nbsp;of the stack get used or som=
ething could be something to consider. It'd be good to consider how whateve=
r proposed could be used to implement such features at least.</div><div><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_1853_1181052564.1415046439634--

.

------=_Part_2356_1151751412.1415061145899
Content-Type: text/plain; charset=UTF-8

On Monday, November 3, 2014 12:27:19 PM UTC-8, gmis...@gmail.com wrote:

> Generally a bit more control of the stack would be nice, so on the one
> hand I think it's a good discussion I'd like to see happen.
> On the other hand, it seems a dangerous area to play in, so perhaps we
> shouldn't encourage it by making it standard..
>
>
I think in a different way: Even if the master Standard shouldn't have it,
standardizing the non-standard features each compiler seems to have seems
like a good idea.  Theory needs to be kept up with practice, just like the
other way around.


> But if there is support for more stack control, perhaps something like
> what you have proposed is ok but maybe something that switches to the heap
> in the event of near exhaustion or on a certain usage amount like on n% of
> the heap used or whatever.
>
>
Not every platform has a meaningful concept of "stack size".  On many
systems, the maximum size of the stack is the amount of memory not used by
the heap.  Other systems get that limitation from when the stack collides
with the heap in addresses instead of physical memory.

On Linux, asking such a question actually requires parsing a text file at
runtime, due to the kernel people not implementing a "query memory" system
call.


> Things like a standard allocator that could be passed to things like
> std::vector that worked like a simple stack arena, but that could be
> parameterized to not chew up all the stack, but start using the heap if
> more than n bytes of the stack get used or something could be something to
> consider. It'd be good to consider how whatever proposed could be used to
> implement such features at least.
>
>
The problem with the above is that there's no good way to implement such an
allocator.  If vector::vector or vector::insert are a non-inlined function
calls, how could they possibly allocate from the stack of their callers?

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

<div dir=3D"ltr">On Monday, November 3, 2014 12:27:19 PM UTC-8, gmis...@gma=
il.com wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div>Generally a bit more control of the stack would be nice, so o=
n the one hand I think it's a good discussion I'd like to see happen.</div>=
<div>On the other hand, it seems a dangerous area to play in,&nbsp;so perha=
ps we shouldn't&nbsp;encourage it by making it standard..</div><div><br></d=
iv></div></div></blockquote><div><br>I think in a different way: Even if th=
e master Standard shouldn't have it, standardizing the non-standard feature=
s each compiler seems to have seems like a good idea.&nbsp; Theory needs to=
 be kept up with practice, just like the other way around.<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div></di=
v></div><div>But if there is support for more stack control, perhaps someth=
ing like what you have proposed is ok&nbsp;but maybe something that switche=
s to the heap in the event of near exhaustion or on a certain usage amount =
like on n% of the heap used or whatever.</div><div><br></div></div></blockq=
uote><div><br>Not every platform has a meaningful concept of "stack size".&=
nbsp; On many systems, the maximum size of the stack is the amount of memor=
y not used by the heap.&nbsp; Other systems get that limitation from when t=
he stack collides with the heap in addresses instead of physical memory.<br=
><br>On Linux, asking such a question actually requires parsing a text file=
 at runtime, due to the kernel people not implementing a "query memory" sys=
tem call.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><div>Things&nbsp;like&nbsp;a standard&nbsp;allocator=
&nbsp;that could be passed to things like std::vector&nbsp;that worked like=
 a simple stack arena, but&nbsp;that could be parameterized to not chew up =
all the stack, but start using the heap if more than n bytes&nbsp;of the st=
ack get used or something could be something to consider. It'd be good to c=
onsider how whatever proposed could be used to implement such features at l=
east.</div><div><br></div></div></blockquote><div><br>The problem with the =
above is that there's no good way to implement such an allocator.&nbsp; If =
vector::vector or vector::insert are a non-inlined function calls, how coul=
d they possibly allocate from the stack of their callers?<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_2356_1151751412.1415061145899--

.

On Monday 03 November 2014 12:27:19 gmisocpp@gmail.com wrote:
> Things like a standard allocator that could be passed to things like
> std::vector that worked like a simple stack arena, but that could be
> parameterized to not chew up all the stack, but start using the heap if
> more than n bytes of the stack get used or something could be something to
> consider. It'd be good to consider how whatever proposed could be used to
> implement such features at least.

What happens if you return such a vector from the scope it was in?

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

--

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

.

------=_Part_1495_1816364975.1415067726417
Content-Type: text/plain; charset=UTF-8



On Tuesday, November 4, 2014 1:32:26 PM UTC+13, Myriachan wrote:
>
> On Monday, November 3, 2014 12:27:19 PM UTC-8, gmis...@gmail.com wrote:
>
>> Generally a bit more control of the stack would be nice, so on the one
>> hand I think it's a good discussion I'd like to see happen.
>> On the other hand, it seems a dangerous area to play in, so perhaps we
>> shouldn't encourage it by making it standard..
>>
>>
> I think in a different way: Even if the master Standard shouldn't have it,
> standardizing the non-standard features each compiler seems to have seems
> like a good idea.  Theory needs to be kept up with practice, just like the
> other way around.
>
>
>> But if there is support for more stack control, perhaps something like
>> what you have proposed is ok but maybe something that switches to the heap
>> in the event of near exhaustion or on a certain usage amount like on n% of
>> the heap used or whatever.
>>
>>
> Not every platform has a meaningful concept of "stack size".  On many
> systems, the maximum size of the stack is the amount of memory not used by
> the heap.  Other systems get that limitation from when the stack collides
> with the heap in addresses instead of physical memory.
>
> On Linux, asking such a question actually requires parsing a text file at
> runtime, due to the kernel people not implementing a "query memory" system
> call.
>
>
>> Things like a standard allocator that could be passed to things like
>> std::vector that worked like a simple stack arena, but that could be
>> parameterized to not chew up all the stack, but start using the heap if
>> more than n bytes of the stack get used or something could be something to
>> consider. It'd be good to consider how whatever proposed could be used to
>> implement such features at least.
>>
>>
> The problem with the above is that there's no good way to implement such
> an allocator.  If vector::vector or vector::insert are a non-inlined
> function calls, how could they possibly allocate from the stack of their
> callers?
>

Yes, I am assuming they will be inlined. If not, then you can't use it.

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

<div dir=3D"ltr"><br><br>On Tuesday, November 4, 2014 1:32:26 PM UTC+13, My=
riachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Monday, Nove=
mber 3, 2014 12:27:19 PM UTC-8, <a>gmis...@gmail.com</a> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><div dir=3D"ltr"><div><div>Generally a bit more contro=
l of the stack would be nice, so on the one hand I think it's a good discus=
sion I'd like to see happen.</div><div>On the other hand, it seems a danger=
ous area to play in,&nbsp;so perhaps we shouldn't&nbsp;encourage it by maki=
ng it standard..</div><div><br></div></div></div></blockquote><div><br>I th=
ink in a different way: Even if the master Standard shouldn't have it, stan=
dardizing the non-standard features each compiler seems to have seems like =
a good idea.&nbsp; Theory needs to be kept up with practice, just like the =
other way around.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"l=
tr"><div><div></div></div><div>But if there is support for more stack contr=
ol, perhaps something like what you have proposed is ok&nbsp;but maybe some=
thing that switches to the heap in the event of near exhaustion or on a cer=
tain usage amount like on n% of the heap used or whatever.</div><div><br></=
div></div></blockquote><div><br>Not every platform has a meaningful concept=
 of "stack size".&nbsp; On many systems, the maximum size of the stack is t=
he amount of memory not used by the heap.&nbsp; Other systems get that limi=
tation from when the stack collides with the heap in addresses instead of p=
hysical memory.<br><br>On Linux, asking such a question actually requires p=
arsing a text file at runtime, due to the kernel people not implementing a =
"query memory" system call.<br>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v dir=3D"ltr"><div></div><div>Things&nbsp;like&nbsp;a standard&nbsp;allocat=
or&nbsp;that could be passed to things like std::vector&nbsp;that worked li=
ke a simple stack arena, but&nbsp;that could be parameterized to not chew u=
p all the stack, but start using the heap if more than n bytes&nbsp;of the =
stack get used or something could be something to consider. It'd be good to=
 consider how whatever proposed could be used to implement such features at=
 least.</div><div><br></div></div></blockquote><div><br>The problem with th=
e above is that there's no good way to implement such an allocator.&nbsp; I=
f vector::vector or vector::insert are a non-inlined function calls, how co=
uld they possibly allocate from the stack of their callers?<br></div></div>=
</blockquote><div><br></div><div>Yes, I am assuming they will be inlined. I=
f not, then you can't use it.</div><div><br></div><div>Melissa<br></div></d=
iv>

<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_1495_1816364975.1415067726417--

.

------=_Part_2201_1846004688.1415067808398
Content-Type: text/plain; charset=UTF-8



On Tuesday, November 4, 2014 2:18:19 PM UTC+13, Thiago Macieira wrote:
>
> On Monday 03 November 2014 12:27:19 gmis...@gmail.com <javascript:>
> wrote:
> > Things like a standard allocator that could be passed to things like
> > std::vector that worked like a simple stack arena, but that could be
> > parameterized to not chew up all the stack, but start using the heap if
> > more than n bytes of the stack get used or something could be something
> to
> > consider. It'd be good to consider how whatever proposed could be used
> to
> > implement such features at least.
>
> What happens if you return such a vector from the scope it was in?
>

yes don't do that. It's just for internal use to the function.

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

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, November 4, 2014 2:18:19 PM UTC+13, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;">On Monday 03 November 2014=
 12:27:19 <a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"trPJepoBfsMJ">gmis...@gmail.com</a> wrote:
<br>&gt; Things like a standard allocator that could be passed to things li=
ke=20
<br>&gt; std::vector that worked like a simple stack arena, but that could =
be=20
<br>&gt; parameterized to not chew up all the stack, but start using the he=
ap if=20
<br>&gt; more than n bytes of the stack get used or something could be some=
thing to=20
<br>&gt; consider. It'd be good to consider how whatever proposed could be =
used to=20
<br>&gt; implement such features at least.
<br>
<br>What happens if you return such a vector from the scope it was in?
<br></blockquote><div><br></div><div>yes don't do that. It's just for inter=
nal use to the function.</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<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_2201_1846004688.1415067808398--

.

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

I remember some c/c++ compilers that used to allow a variable as the size
parameter of an automatic array:

void foo(unsigned int n)
{
     int arr[n];
     ...
};

I can not imagine any other practical use case for stack allocation. Not to
mention that in order to keep the integrity of stack, any such allocation
need be undone automatically while unwinding the stack.

regards,
FM.


2014-11-04 5:53 GMT+03:30 <gmisocpp@gmail.com>:

>
>
> On Tuesday, November 4, 2014 2:18:19 PM UTC+13, Thiago Macieira wrote:
>>
>> On Monday 03 November 2014 12:27:19 gmis...@gmail.com wrote:
>> > Things like a standard allocator that could be passed to things like
>> > std::vector that worked like a simple stack arena, but that could be
>> > parameterized to not chew up all the stack, but start using the heap if
>> > more than n bytes of the stack get used or something could be something
>> to
>> > consider. It'd be good to consider how whatever proposed could be used
>> to
>> > implement such features at least.
>>
>> What happens if you return such a vector from the scope it was in?
>>
>
> yes don't do that. It's just for internal use to the function.
>
>>
>> --
>> 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/.


--
how am I supposed to end the twisted road of  your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!

--

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

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

<div dir=3D"rtl"><div dir=3D"ltr">I remember some c/c++ compilers that used=
 to allow a variable as the size parameter of an automatic array:</div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">void foo(unsigned int n)</div><div =
dir=3D"ltr">{</div><div dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0int arr[n];</div><d=
iv dir=3D"ltr">=C2=A0 =C2=A0 =C2=A0...</div><div dir=3D"ltr">};</div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr">I can not imagine any other practical=
 use case for stack allocation. Not to mention that in order to keep the in=
tegrity of stack, any such allocation need be undone automatically while un=
winding the stack.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">regards=
,</div><div dir=3D"ltr">FM.</div><div dir=3D"ltr"><br></div></div><div clas=
s=3D"gmail_extra"><div dir=3D"ltr"><br><div class=3D"gmail_quote">2014-11-0=
4 5:53 GMT+03:30  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmisocpp@gmail.co=
m" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span>:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><br><br>On Tuesday, November 4, 2014 2:18:19 PM UTC+13, Thia=
go Macieira wrote:<span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">On Monday 03 November =
2014 12:27:19 <a>gmis...@gmail.com</a> wrote:
<br>&gt; Things like a standard allocator that could be passed to things li=
ke=20
<br>&gt; std::vector that worked like a simple stack arena, but that could =
be=20
<br>&gt; parameterized to not chew up all the stack, but start using the he=
ap if=20
<br>&gt; more than n bytes of the stack get used or something could be some=
thing to=20
<br>&gt; consider. It&#39;d be good to consider how whatever proposed could=
 be used to=20
<br>&gt; implement such features at least.
<br>
<br>What happens if you return such a vector from the scope it was in?
<br></blockquote><div><br></div></span><div>yes don&#39;t do that. It&#39;s=
 just for internal use to the function.</div><span class=3D""><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></span></blockquote></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<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" target=3D"_=
blank">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">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></div><br clear=3D"all"><div><br></div>-- <br><div class=3D"gma=
il_signature"><div dir=3D"ltr">how am I supposed to end the twisted road of=
=C2=A0 your hair in the dark night??<br>unless the candle of your face does=
 turn a lamp up on my way!!!<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 />

--047d7b2e3db2ba87490507057c9e--

.

On 4 November 2014 09:56, Farid Mehrabi <farid.mehrabi@gmail.com> wrote:
> I remember some c/c++ compilers that used to allow a variable as the size
> parameter of an automatic array:
>
> void foo(unsigned int n)
> {
>      int arr[n];
>      ...
> };
>
No need to remember compilers which used to do it, both gcc and clang
accept the following code as C++ today, and I use this functionality
all the time.

int main(int argc, char** argv)
{
    int x[argc];
}

--

---
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 Tuesday 04 November 2014 13:26:52 Farid Mehrabi wrote:
> I remember some c/c++ compilers that used to allow a variable as the size
> parameter of an automatic array:
>
> void foo(unsigned int n)
> {
>      int arr[n];
>      ...
> };
>
> I can not imagine any other practical use case for stack allocation. Not to
> mention that in order to keep the integrity of stack, any such allocation
> need be undone automatically while unwinding the stack.

That's called Variable Length Arrays. They were added to the C standard with
C99. We had them slated for C++14, a little shorter than the C version (no
sizeof support), but it got dropped.

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

.

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

No wonder; assume n==10000 and sizeof(X)==100 what would happen to the
stack by this statement:

X x[n];

Regards,
FM.

2014-11-04 21:58 GMT+03:30 Thiago Macieira <thiago@macieira.org>:

> On Tuesday 04 November 2014 13:26:52 Farid Mehrabi wrote:
> > I remember some c/c++ compilers that used to allow a variable as the size
> > parameter of an automatic array:
> >
> > void foo(unsigned int n)
> > {
> >      int arr[n];
> >      ...
> > };
> >
> > I can not imagine any other practical use case for stack allocation. Not
> to
> > mention that in order to keep the integrity of stack, any such allocation
> > need be undone automatically while unwinding the stack.
>
> That's called Variable Length Arrays. They were added to the C standard
> with
> C99. We had them slated for C++14, a little shorter than the C version (no
> sizeof support), but it got dropped.
>
> --
> 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/.
>



--
how am I supposed to end the twisted road of  your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!

--

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

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

<div dir=3D"rtl"><div dir=3D"ltr">No wonder; assume n=3D=3D10000 and sizeof=
(X)=3D=3D100 what would happen to the stack by this statement:</div><div di=
r=3D"ltr"><br></div><div dir=3D"ltr">X x[n];</div><div dir=3D"ltr"><br></di=
v><div dir=3D"ltr">Regards,</div><div dir=3D"ltr">FM.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2014-11-04=
 21:58 GMT+03:30 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:th=
iago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span>:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tuesday 04 November 2=
014 13:26:52 Farid Mehrabi wrote:<br>
&gt; I remember some c/c++ compilers that used to allow a variable as the s=
ize<br>
&gt; parameter of an automatic array:<br>
&gt;<br>
&gt; void foo(unsigned int n)<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 int arr[n];<br>
&gt;=C2=A0 =C2=A0 =C2=A0 ...<br>
&gt; };<br>
&gt;<br>
&gt; I can not imagine any other practical use case for stack allocation. N=
ot to<br>
&gt; mention that in order to keep the integrity of stack, any such allocat=
ion<br>
&gt; need be undone automatically while unwinding the stack.<br>
<br>
</span>That&#39;s called Variable Length Arrays. They were added to the C s=
tandard with<br>
C99. We had them slated for C++14, a little shorter than the C version (no<=
br>
sizeof support), but it got dropped.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">how am I supposed to end th=
e twisted road of=C2=A0 your hair in the dark night??<br>unless the candle =
of your face does turn a lamp up on my way!!!<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 />

--001a11c26a081ece84050720c62e--

.

On Wednesday 05 November 2014 22:00:07 Farid Mehrabi wrote:
> No wonder; assume n==10000 and sizeof(X)==100 what would happen to the
> stack by this statement:
>
> X x[n];

The same that would happen to the stack if you had:

 X x[10000];

It may or may not run. It's not the compiler's fault if you abuse the stack in
your application.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_2528_577743105.1415225381625
Content-Type: text/plain; charset=UTF-8



On Thursday, November 6, 2014 10:32:11 AM UTC+13, Thiago Macieira wrote:
>
> On Wednesday 05 November 2014 22:00:07 Farid Mehrabi wrote:
> > No wonder; assume n==10000 and sizeof(X)==100 what would happen to the
> > stack by this statement:
> >
> > X x[n];
>
> The same that would happen to the stack if you had:
>
>         X x[10000];
>
> It may or may not run. It's not the compiler's fault if you abuse the
> stack in
> your application.
>

I'm sure this must have been discussed but why can't we generate calls to
the heap instead if the stack is exhausted or usage exceeds certain system
defined parameters?

--

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

<div dir=3D"ltr"><br><br>On Thursday, November 6, 2014 10:32:11 AM UTC+13, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On Wednesday 05 November=
 2014 22:00:07 Farid Mehrabi wrote:
<br>&gt; No wonder; assume n=3D=3D10000 and sizeof(X)=3D=3D100 what would h=
appen to the
<br>&gt; stack by this statement:
<br>&gt;=20
<br>&gt; X x[n];
<br>
<br>The same that would happen to the stack if you had:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;X x[10000];
<br>
<br>It may or may not run. It's not the compiler's fault if you abuse the s=
tack in=20
<br>your application.
<br></blockquote><div><br></div><div>I'm sure this must have been discussed=
 but why can't&nbsp;we generate calls to the heap&nbsp;instead if&nbsp;the =
stack is exhausted or usage exceeds certain&nbsp;system defined&nbsp;parame=
ters?</div><div><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_2528_577743105.1415225381625--

.

2014-11-05 23:09 GMT+01:00  <gmisocpp@gmail.com>:
> I'm sure this must have been discussed but why can't we generate calls to
> the heap instead if the stack is exhausted or usage exceeds certain system
> defined parameters?

I believe the reason for this drastic rule is that there is no uniform
implementation guarantess that stack exhaustion can be detected
*before* the harm has already been done.

- Daniel

--

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

.

------=_Part_4858_1728226738.1415226337738
Content-Type: text/plain; charset=UTF-8

On Monday, November 3, 2014 7:00:48 AM UTC-5, Douglas Boffey wrote:
>
> I was thinking about the possibility of
>
>
>  void* operator new (std::size_t size, const std::stack_t& stack_value);
>
>
I actually like this idea in principle; it would be nice to be able to do:

unique_ptr<T> foo(new (stack) T(args)); or the like, and have it Just Work
(have the memory be invalidated after all the destructors in the local
scope are done executing... that bit's easy).

The issue I have with this is that there would then be no way to implement
idioms around this, like:

unique_ptr<T> foo= make_stack_unique<T>(args);

which is a problem.

Sean

--

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

<div dir=3D"ltr">On Monday, November 3, 2014 7:00:48 AM UTC-5, Douglas Boff=
ey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>I was thinking about the possibility of</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div style=3D"BORDER-BOTTOM:#bbb 1px solid;BORDER-LEFT:#bbb 1px solid;BACKG=
ROUND-COLOR:#fafafa;WORD-WRAP:break-word;BORDER-TOP:#bbb 1px solid;BORDER-R=
IGHT:#bbb 1px solid"><code>
<div><span style=3D"COLOR:#008">void</span><span style=3D"COLOR:#660">*</sp=
an><span style=3D"COLOR:#000"> </span><span style=3D"COLOR:#008">operator</=
span><span style=3D"COLOR:#000"> </span><span style=3D"COLOR:#008">new</spa=
n><span style=3D"COLOR:#000"> </span><span style=3D"COLOR:#660">(</span><sp=
an style=3D"COLOR:#000">std</span><span style=3D"COLOR:#660">::</span><span=
 style=3D"COLOR:#000">size_t size</span><span style=3D"COLOR:#660">,</span>=
<span style=3D"COLOR:#000"> </span><span style=3D"COLOR:#008">const</span><=
span style=3D"COLOR:#000"> std</span><span style=3D"COLOR:#660">::</span><s=
pan style=3D"COLOR:#000">stack_t</span><span style=3D"COLOR:#660">&amp;</sp=
an><span style=3D"COLOR:#000"> stack_value</span><span style=3D"COLOR:#660"=
>);</span></div></code></div><br></div></blockquote><div><br></div><div>I a=
ctually like this idea in principle; it would be nice to be able to do:</di=
v><div><br></div><div>unique_ptr&lt;T&gt; foo(new (stack) T(args)); or the =
like, and have it Just Work (have the memory be invalidated after all the d=
estructors in the local scope are done executing... that bit's easy).</div>=
<div><br></div><div>The issue I have with this is that there would then be =
no way to implement idioms around this, like:</div><div><br></div><div>uniq=
ue_ptr&lt;T&gt; foo=3D make_stack_unique&lt;T&gt;(args);</div><div><br></di=
v><div>which is a problem.</div><div><br></div><div>Sean</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_4858_1728226738.1415226337738--

.

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



On Thursday, November 6, 2014 11:13:41 AM UTC+13, Daniel Kr=C3=BCgler wrote=
:
>
> 2014-11-05 23:09 GMT+01:00  <gmis...@gmail.com <javascript:>>:=20
> > I'm sure this must have been discussed but why can't we generate calls=
=20
> to=20
> > the heap instead if the stack is exhausted or usage exceeds certain=20
> system=20
> > defined parameters?=20
>
> I believe the reason for this drastic rule is that there is no uniform=20
> implementation guarantess that stack exhaustion can be detected=20
> *before* the harm has already been done.=20
>

That is really sad. But then doesn't that suggest that alloca for example,=
=20
isn't "safe" at all, ever.=20
Maybe the answer is just simply to say then that on those platforms where=
=20
the guarantee can't be met, stack always =3D=3D heap.
That puts the pressure on that platform to fix the problem and makes it=20
fast and standard where it can be and slow where it probably already is=20
slow since on those platforms if we can't rely on the stack or any=20
implementation then surely we are going to resort to the heap anyway.

Another thought is to play with/evolve the idea where we specify regular a=
=20
'restricted' pointer type from how that promises never to outlast the=20
frame, then say the compiler is free to use heap or stack as it feels is=20
safe.

>
> - Daniel=20
>

--=20

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

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

<div dir=3D"ltr"><br><br>On Thursday, November 6, 2014 11:13:41 AM UTC+13, =
Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;">2014-11-05 23:09 GMT=
+01:00 &nbsp;&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"cLq-7YkGRp4J">gmis...@gmail.com</a>=
&gt;:
<br>&gt; I'm sure this must have been discussed but why can't we generate c=
alls to
<br>&gt; the heap instead if the stack is exhausted or usage exceeds certai=
n system
<br>&gt; defined parameters?
<br>
<br>I believe the reason for this drastic rule is that there is no uniform
<br>implementation guarantess that stack exhaustion can be detected
<br>*before* the harm has already been done.
<br></blockquote><div><br></div><div>That is&nbsp;really sad.&nbsp;But then=
 doesn't that suggest that alloca for example, isn't&nbsp;"safe" at all, ev=
er.&nbsp;</div><div>Maybe the answer is just simply to say then that on tho=
se platforms where the guarantee can't be met, stack always =3D=3D heap.</d=
iv><div>That puts the pressure on that platform to fix the problem and make=
s it fast and standard where it can be and slow where it probably already i=
s slow since on those platforms if we can't rely on the stack or any implem=
entation then surely we are going to resort to the heap anyway.</div><div><=
br></div><div>Another&nbsp;thought is to play with/evolve the idea where&nb=
sp;we specify regular a 'restricted' pointer type from how that promises ne=
ver to&nbsp;outlast the frame,&nbsp;then say the compiler is free to use he=
ap or stack as it feels is safe.</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>- Daniel
<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_393_1334180324.1415228091666--

.

2014-11-05 23:54 GMT+01:00  <gmisocpp@gmail.com>:
>
>
> On Thursday, November 6, 2014 11:13:41 AM UTC+13, Daniel Kr=C3=BCgler wro=
te:
>>
>> 2014-11-05 23:09 GMT+01:00  <gmis...@gmail.com>:
>> > I'm sure this must have been discussed but why can't we generate calls
>> > to
>> > the heap instead if the stack is exhausted or usage exceeds certain
>> > system
>> > defined parameters?
>>
>> I believe the reason for this drastic rule is that there is no uniform
>> implementation guarantess that stack exhaustion can be detected
>> *before* the harm has already been done.
>
>
> That is really sad. But then doesn't that suggest that alloca for example=
,
> isn't "safe" at all, ever.

Define "safe". Irrespective of the clear specification of alloca, such as i=
n

http://man7.org/linux/man-pages/man3/alloca.3.html

"If the allocation causes stack overflow, program behavior is undefined."

people still use this function.

A good source to check with is Jens' paper series about "runtime-sized arra=
ys",

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html

And again, this paper specifies existing practice:

"If the size of the array exceeds the size of the memory available for
objects with automatic storage duration, the behavior is undefined [
Footnote: Implementations that detect this case are encouraged to
throw an exception that would match a handler (15.3 except.handle) of
type std::bad_array_length (18.6.2.2 xxx). ]"

> Maybe the answer is just simply to say then that on those platforms where
> the guarantee can't be met, stack always =3D=3D heap.

Ideally yes, but that was not the last state in this paper, which only
suggests the possibility to use malloc instead:

" [ Footnote: Alternatively, an implementation could allocate such an
array on the usual stack or obtain storage via malloc (20.6.13
c.malloc). ] "

- Daniel

--=20

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

.

> On 05 Nov 2014, at 23:54 , gmisocpp@gmail.com wrote:
>=20
> That is really sad. But then doesn't that suggest that alloca for example=
, isn't "safe" at all, ever.=20
> Maybe the answer is just simply to say then that on those platforms where=
 the guarantee can't be met, stack always =3D=3D heap.
> That puts the pressure on that platform to fix the problem and makes it f=
ast and standard where it can be and slow where it probably already is slow=
 since on those platforms if we can't rely on the stack or any implementati=
on then surely we are going to resort to the heap anyway.
>=20
> Another thought is to play with/evolve the idea where we specify regular =
a 'restricted' pointer type from how that promises never to outlast the fra=
me, then say the compiler is free to use heap or stack as it feels is safe.

What made you think it is safe in the first place?
Quote from the manpage:

> The alloca() function returns a pointer to the beginning of the
> allocated space.  If the allocation causes stack overflow, program
> behavior is undefined.
> (...)
> There is no error indication if the stack frame cannot be extended.
> (However, after a failed allocation, the program is likely to receive
> a SIGSEGV signal if it attempts to access the unallocated space.)


And MSDN:

> A stack overflow exception is generated if the space cannot be allocated.=
 The stack overflow exception is not a C++ exception; it is a structured ex=
ception.

Basically alloca() isn't "safe" and never was and whatever happens on stack=
 overflow is platform dependent behavior.

--=20

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

.

On Wednesday 05 November 2014 14:25:37 Sean Hunt wrote:
> On Monday, November 3, 2014 7:00:48 AM UTC-5, Douglas Boffey wrote:
> > I was thinking about the possibility of
> >
> >  void* operator new (std::size_t size, const std::stack_t& stack_value);
>
> I actually like this idea in principle; it would be nice to be able to do:
>
> unique_ptr<T> foo(new (stack) T(args)); or the like, and have it Just Work
> (have the memory be invalidated after all the destructors in the local
> scope are done executing... that bit's easy).
>
> The issue I have with this is that there would then be no way to implement
> idioms around this, like:
>
> unique_ptr<T> foo= make_stack_unique<T>(args);
>
> which is a problem.

I don't agree it is a problem. I don't see why you'd want to use a unique_ptr
to something that already has a local scope. You don't need the unique_ptr to
delete the object and you cannot move it to another scope anyway.

A naked pointer would be enough.

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

--

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

.

------=_Part_2127_1818573369.1415230954416
Content-Type: text/plain; charset=UTF-8

On Wednesday, November 5, 2014 6:28:09 PM UTC-5, Thiago Macieira wrote:
>
> I don't agree it is a problem. I don't see why you'd want to use a
> unique_ptr
> to something that already has a local scope. You don't need the unique_ptr
> to
> delete the object and you cannot move it to another scope anyway.
>
> A naked pointer would be enough.
>

You could, yes, but that's even less idiomatic. Modern C++ wants to push
the average user as far from memory management as possible. Granted,
perhaps that's not so much of an issue for someone explicitly using the
stack, but still, I'd prefer we pushed away from that.

One option might be a library stack_ptr class. The only way to construct it
would be from a make_stack<T>() function which actually performs the stack
allocation under the hood, and all the stack_ptr does is call the
destructor when it goes out of scope.

I also don't understand all the costernation about stack overflows. It's
already UB to overflow the stack, so why do we care if we add another
mechanism to do so?

Sean

--

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

<div dir=3D"ltr">On Wednesday, November 5, 2014 6:28:09 PM UTC-5, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't agree it =
is a problem. I don't see why you'd want to use a unique_ptr=20
<br>to something that already has a local scope. You don't need the unique_=
ptr to=20
<br>delete the object and you cannot move it to another scope anyway.=20
<br>
<br>A naked pointer would be enough.
<br></blockquote><div><br></div><div>You could, yes, but that's even less i=
diomatic. Modern C++ wants to push the average user as far from memory mana=
gement as possible. Granted, perhaps that's not so much of an issue for som=
eone explicitly using the stack, but still, I'd prefer we pushed away from =
that.</div><div><br></div><div>One option might be a library stack_ptr clas=
s. The only way to construct it would be from a make_stack&lt;T&gt;() funct=
ion which actually performs the stack allocation under the hood, and all th=
e stack_ptr does is call the destructor when it goes out of scope.</div><di=
v><br></div><div>I also don't understand all the costernation about stack o=
verflows. It's already UB to overflow the stack, so why do we care if we ad=
d another mechanism to do so?</div><div><br></div><div>Sean</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_2127_1818573369.1415230954416--

.

------=_Part_17_719710333.1415297756741
Content-Type: text/plain; charset=UTF-8

Thanks Daniel


> Define "safe". Irrespective of the clear specification of alloca, such as
> in
>

Perhaps we don't use the real stack where it's not safe, see below.

>
> http://man7.org/linux/man-pages/man3/alloca.3.html


> "If the allocation causes stack overflow, program behavior is undefined."
>
> people still use this function.
>

Yes we need to stop/reduce the use then.


> A good source to check with is Jens' paper series about "runtime-sized
> arrays",
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html
>
> And again, this paper specifies existing practice:
>
>
>
How about introducing VLA's into C++ like this:
* Goals of C++ VLA's:
- aid C to C++ migration - but not at any cost, may not be fully compatible
- be useful in own right as a safer and Standard replacement for alloca for
most / many cases.
- purpose is be safer than alloca (safe period) and usually faster than
malloc/new or worst case no slower.
- if all goals aren't possible, don't introduce any of this.

* C++ VLA's:
- pointers to restricted use memory, limited use cases
- education is not a replacement for new.
- use the real stack, vla stack, or general heap as whatever as necessary
to be safe and offer better performance than new
- compiler / runtime managed - i.e. individual allocations not explicitly
controlled by the developer beyond declarations.
- allocation throws bad_alloc when they fail.

* vla stack(s)
- special heap (presumably).

So the thought is that VLA's are introduced into C++ to make a lot C code
compatible with C++ and replace a lot of alloca uses with something safer.

The assumption is, by being compiler managed and limited use things; C++
VLA's could therefore offer (usually) better performance and easier use
than explicit C++'s new's and deletes.

And therefore by virtue of that performance gain VLA's could also be
acceptable as a replacement for alloca's for many/most cases.

And by promising to be safer than alloca's, people would use VLA's instead
of alloca's where possible.

Do people think such a facility with this rationale and goals is possible
and worthwhile?

--

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

<div dir=3D"ltr"><div>Thanks Daniel</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">Define "safe". Irrespective of the clear specification of alloc=
a, such as in
<br></blockquote><div><br></div><div>Perhaps we don't use the real stack wh=
ere it's not safe, see below.&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fman7.org%2Flinux%2Fman-pages%2Fman3%2Falloca.3.html\46sa\75D\46sntz\0751=
\46usg\75AFQjCNFeUDXvBKt8umgtdAV8iOUBtyX9WQ';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fman7.org%2Flinux%2Fman-p=
ages%2Fman3%2Falloca.3.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFeUDXvBKt8um=
gtdAV8iOUBtyX9WQ';return true;" href=3D"http://man7.org/linux/man-pages/man=
3/alloca.3.html" target=3D"_blank">http://man7.org/linux/man-<wbr>pages/man=
3/alloca.3.html</a>
&nbsp;</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">
<br>"If the allocation causes stack overflow, program behavior is undefined=
.."
<br>
<br>people still use this function.
<br></blockquote><div><br></div><div>Yes we need to stop/reduce the use the=
n.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;">
<br>A good source to check with is Jens' paper series about "runtime-sized =
arrays",
<br>
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3639.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNE7PD2pqaLyI6rTtCKPsr_ZimufAQ';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3639.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNE7PD2pqaLyI6rTtCKPsr_ZimufAQ';return true;"=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html=
" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers=
/2013/<wbr>n3639.html</a>
<br>
<br>And again, this paper specifies existing practice:
<br>
<br><br></blockquote><div><br></div><div>How about introducing VLA's into C=
++ like this:</div><div>* Goals of C++ VLA's:<br>- aid C to C++ migration -=
 but not at any cost, may not be fully compatible<br>- be useful in own rig=
ht as a safer and Standard replacement for alloca for most / many cases.<br=
>- purpose is be safer than alloca (safe period) and usually faster than ma=
lloc/new or worst case no slower.<br>- if all goals aren't possible, don't =
introduce any of this.</div><div><br></div><div>* C++ VLA's:<br>- pointers =
to&nbsp;restricted use&nbsp;memory,&nbsp;limited use cases</div><div>- educ=
ation is&nbsp;not a replacement for new.<br>- use the real stack, vla stack=
, or general heap&nbsp;as whatever as necessary to be safe&nbsp;and offer&n=
bsp;better performance than new</div><div>- compiler / runtime managed - i.=
e. individual allocations not explicitly controlled by the developer beyond=
 declarations.</div><div>- allocation throws bad_alloc when they fail.</div=
><div><br></div><div>* vla stack(s)<br>- special heap&nbsp;(presumably).<br=
></div><div><br></div><div>So the&nbsp;thought is that VLA's are introduced=
 into C++&nbsp;to make a lot C code compatible with C++ and replace a lot o=
f alloca uses with something safer.</div><div><br></div><div>The assumption=
 is,&nbsp;by being&nbsp;compiler managed and limited use things; C++ VLA's&=
nbsp;could&nbsp;therefore&nbsp;offer (usually)&nbsp;better performance&nbsp=
;and easier use than explicit C++'s new's and deletes.</div><div><br></div>=
<div>And therefore by virtue of that performance gain&nbsp;VLA's could also=
 be acceptable as&nbsp;a replacement for&nbsp;alloca's for many/most cases.=
 </div><div><br></div><div>And by promising to be safer than alloca's, peop=
le would use VLA's instead of alloca's where possible.</div><div><br></div>=
<div>Do people think such&nbsp;a facility with this rationale and goals&nbs=
p;is possible and worthwhile?</div><div><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_17_719710333.1415297756741--

.

2014-11-06 19:15 GMT+01:00  <gmisocpp@gmail.com>:
> How about introducing VLA's into C++ like this:
> * Goals of C++ VLA's:
> - aid C to C++ migration - but not at any cost, may not be fully compatible
> - be useful in own right as a safer and Standard replacement for alloca for
> most / many cases.
> - purpose is be safer than alloca (safe period) and usually faster than
> malloc/new or worst case no slower.
> - if all goals aren't possible, don't introduce any of this.
>
> * C++ VLA's:
> - pointers to restricted use memory, limited use cases
> - education is not a replacement for new.
> - use the real stack, vla stack, or general heap as whatever as necessary to
> be safe and offer better performance than new
> - compiler / runtime managed - i.e. individual allocations not explicitly
> controlled by the developer beyond declarations.
> - allocation throws bad_alloc when they fail.
>
> * vla stack(s)
> - special heap (presumably).
>
> So the thought is that VLA's are introduced into C++ to make a lot C code
> compatible with C++ and replace a lot of alloca uses with something safer.
>
> The assumption is, by being compiler managed and limited use things; C++
> VLA's could therefore offer (usually) better performance and easier use than
> explicit C++'s new's and deletes.
>
> And therefore by virtue of that performance gain VLA's could also be
> acceptable as a replacement for alloca's for many/most cases.
>
> And by promising to be safer than alloca's, people would use VLA's instead
> of alloca's where possible.
>
> Do people think such a facility with this rationale and goals is possible
> and worthwhile?

I don't think that rationale alone is sufficient here. Let me point
out that we had shortly std::dynamic_array as suggested by

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html

within the working draft. This template provides the guarantees you
would like to see (as I understand it) and does guarantee that there
is no undefined behaviour because of resource restrictions, instead a
well-defined exception would be thrown. But the proposal has been
moved into a separate arrays extensions technical specification, see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html

which hosts now arrays of runtime bounds and dynarray as library component.

One of the issues of dynarray actually is, whether it can be
non-trivially implemented in the way as specified. With non-trivial I
mean that such an implementation would really take advantage of alloca
and friends under the covers where this would be ideally possible.

Given this existing proposal, I don't think that another proposal
would really help us, unless this proposal would show that it solves
the unclear points of dynarray. Or put it in the other way: I would
like to invite you to attempt to implement dynarray and demonstrate
that it works and can be give advantages beyond heap allocation.

I think such additional data would be quite helpful for the committee
to make progress here.

Thanks,

- Daniel

--

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

.

------=_Part_60_500755309.1415303678482
Content-Type: text/plain; charset=UTF-8


>
> I don't think that rationale alone is sufficient here. Let me point
> out that we had shortly std::dynamic_array as suggested by
>

What additional / less goals would satisfy then?


>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html
>
> within the working draft. This template provides the guarantees you
> would like to see (as I understand it) and does guarantee that there
> is no undefined behaviour because of resource restrictions, instead a
> well-defined exception would be thrown. But the proposal has been
> moved into a separate arrays extensions technical specification, see
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html
>
> which hosts now arrays of runtime bounds and dynarray as library
> component.
>
> One of the issues of dynarray actually is, whether it can be
> non-trivially implemented in the way as specified. With non-trivial I
> mean that such an implementation would really take advantage of alloca
> and friends under the covers where this would be ideally possible.


Yes, it seems non trivial (at least to me). But is it possible is what I'm
wondering.
But what I'm thinking of wouldn't use alloca - i.e. the real stack - unless
it can.


> Given this existing proposal, I don't think that another proposal
> would really help us, unless this proposal would show that it solves
> the unclear points of dynarray. Or put it in the other way: I would
> like to invite you to attempt to implement dynarray and demonstrate
> that it works and can be give advantages beyond heap allocation.
>
> I think such additional data would be quite helpful for the committee
> to make progress here.
>
> Yes I can see it requires more thought than certainly I am likely to put
into it.

My hope was that a dedicated memory pool for vla's would allow for improved
performance over the regular new/delete heap because we could make more
guarantees about the usage patterns on that heap than regular
new'd/malloc'd memory, i.e. typically small allocations (i.e. people aim to
use vla where they'd typically use alloca), deterministic compiler known
lifetime, etc. non storage of pointers etc. so that would allow the heap to
be managed more efficiently than the regular heap.

If people think that's not likely a reasonable expectation, I can't argue
with that as I haven't put sufficient thought into it.

--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;">I don't think that rationale =
alone is sufficient here. Let me point
<br>out that we had shortly std::dynamic_array as suggested by
<br></blockquote><div><br></div><div>What additional / less goals would sat=
isfy then?</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;">
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3662.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNGKKAUKEqRRvEIIT8-F3dS7BQ6u4A';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3662.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNGKKAUKEqRRvEIIT8-F3dS7BQ6u4A';return true;"=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html=
" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers=
/2013/<wbr>n3662.html</a>
<br>
<br>within the working draft. This template provides the guarantees you
<br>would like to see (as I understand it) and does guarantee that there
<br>is no undefined behaviour because of resource restrictions, instead a
<br>well-defined exception would be thrown. But the proposal has been
<br>moved into a separate arrays extensions technical specification, see
<br>
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3820.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNETkg5mCxNY8jn9TJFQo3-anelb3A';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3820.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNETkg5mCxNY8jn9TJFQo3-anelb3A';return true;"=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html=
" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers=
/2013/<wbr>n3820.html</a>
<br>
<br>which hosts now arrays of runtime bounds and dynarray as library compon=
ent.
<br>
<br>One of the issues of dynarray actually is, whether it can be
<br>non-trivially implemented in the way as specified. With non-trivial I
<br>mean that such an implementation would really take advantage of alloca
<br>and friends under the covers where this would be ideally possible.
&nbsp;</blockquote><div><br></div><div>Yes, it seems&nbsp;non trivial (at l=
east to me). But is it possible is what I'm wondering.</div><div>But what I=
'm thinking of wouldn't use alloca - i.e. the real stack - unless it can.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">
<br>Given this existing proposal, I don't think that another proposal
<br>would really help us, unless this proposal would show that it solves
<br>the unclear points of dynarray. Or put it in the other way: I would
<br>like to invite you to attempt to implement dynarray and demonstrate
<br>that it works and can be give advantages beyond heap allocation.
<br>
<br>I think such additional data would be quite helpful for the committee
<br>to make progress here.
<br>
<br></blockquote><div>Yes I can see it requires more thought than certainly=
 I am likely to put into it.&nbsp;</div><div><br></div><div>My hope&nbsp;wa=
s that a dedicated&nbsp;memory pool for vla's would allow for improved perf=
ormance over the regular new/delete&nbsp;heap because we could make more gu=
arantees about the usage patterns on that heap than regular new'd/malloc'd =
memory, i.e. typically small allocations (i.e. people aim to use vla where =
they'd typically use alloca), deterministic compiler known lifetime, etc. n=
on storage of pointers etc. so that would allow the heap to be managed more=
 efficiently than the regular heap.</div><div><br></div><div>If people thin=
k that's not&nbsp;likely a reasonable expectation, I can't argue with that =
as I haven't put sufficient thought into it.</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_60_500755309.1415303678482--

.

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

2014-11-06 1:01 GMT+03:30 Thiago Macieira <thiago@macieira.org>:

> On Wednesday 05 November 2014 22:00:07 Farid Mehrabi wrote:
> > No wonder; assume n==10000 and sizeof(X)==100 what would happen to the
> > stack by this statement:
> >
> > X x[n];
>
> The same that would happen to the stack if you had:
>
>         X x[10000];
>
> It may or may not run. It's not the compiler's fault if you abuse the
> stack in
> your application.
>
>
At least the compiler can generate diagnostics at compile time rather than
an actual run-time crash with fixed sized arrays. If the size is not known
at compile-time, a silent hard-to-detect error can be produced that varies
with program config. Stack errors are very tricky and diverse based on the
platform we should not add another source to them. Its not about abuse, Its
about code maintenance and error-detection.

best,
FM.

--

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

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

<div dir=3D"rtl"><div style=3D"text-align:left"><br></div><div class=3D"gma=
il_extra"><div style=3D"text-align:left"><br></div><div class=3D"gmail_quot=
e"><div dir=3D"ltr">2014-11-06 1:01 GMT+03:30 Thiago Macieira <span dir=3D"=
ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@ma=
cieira.org</a>&gt;</span>:</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=
=3D"text-align:left">On Wednesday 05 November 2014 22:00:07 Farid Mehrabi w=
rote:</div><span class=3D""><div style=3D"text-align:left">&gt; No wonder; =
assume n=3D=3D10000 and sizeof(X)=3D=3D100 what would happen to the</div><d=
iv style=3D"text-align:left">&gt; stack by this statement:</div><div style=
=3D"text-align:left">&gt;</div><div style=3D"text-align:left">&gt; X x[n];<=
/div>
<div style=3D"text-align:left"><br></div>
</span><div style=3D"text-align:left">The same that would happen to the sta=
ck if you had:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 X x[10000];</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">It =
may or may not run. It&#39;s not the compiler&#39;s fault if you abuse the =
stack in</div><div style=3D"text-align:left">your application.</div>
<div class=3D"HOEnZb"><div class=3D"h5"><div style=3D"text-align:left"><br>=
</div></div></div></blockquote><div style=3D"text-align:left">=C2=A0</div><=
div style=3D"text-align:left" dir=3D"ltr">At least the compiler can generat=
e diagnostics at compile time rather than an actual run-time crash with fix=
ed sized arrays. If the size is not known at compile-time, a silent hard-to=
-detect error can be produced that varies with program config. Stack errors=
 are very tricky and diverse based on the platform we should not add anothe=
r source to them. Its not about abuse, Its about code maintenance and error=
-detection.=C2=A0</div><div style=3D"text-align:left" dir=3D"ltr"><br></div=
><div style=3D"text-align:left" dir=3D"ltr">best,</div><div style=3D"text-a=
lign:left" dir=3D"ltr">FM.</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 />

--089e014941440d38200507718275--

.

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

2014-11-06 3:12 GMT+03:30 Sean Hunt <scshunt@csclub.uwaterloo.ca>:

> On Wednesday, November 5, 2014 6:28:09 PM UTC-5, Thiago Macieira wrote:
>>
>> I don't agree it is a problem. I don't see why you'd want to use a
>> unique_ptr
>> to something that already has a local scope. You don't need the
>> unique_ptr to
>> delete the object and you cannot move it to another scope anyway.
>>
>> A naked pointer would be enough.
>>
>
> You could, yes, but that's even less idiomatic. Modern C++ wants to push
> the average user as far from memory management as possible. Granted,
> perhaps that's not so much of an issue for someone explicitly using the
> stack, but still, I'd prefer we pushed away from that.
>
> One option might be a library stack_ptr class. The only way to construct
> it would be from a make_stack<T>() function which actually performs the
> stack allocation under the hood, and all the stack_ptr does is call the
> destructor when it goes out of scope.
>
> I also don't understand all the costernation about stack overflows. It's
> already UB to overflow the stack, so why do we care if we add another
> mechanism to do so?
>
>
>
So are you proposing not worry about the development cycle? Anybody with
minimum experience of embedded environments should be aware of subtlety of
stack-overflow. A random crash with no obvious reason. IMHO, Let the
compiler at list warn when possible.

regards,
FM.

--

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

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

<div dir=3D"rtl"><br><div class=3D"gmail_extra"><div dir=3D"ltr"><br><div c=
lass=3D"gmail_quote">2014-11-06 3:12 GMT+03:30 Sean Hunt <span dir=3D"ltr">=
&lt;<a href=3D"mailto:scshunt@csclub.uwaterloo.ca" target=3D"_blank">scshun=
t@csclub.uwaterloo.ca</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an class=3D"">On Wednesday, November 5, 2014 6:28:09 PM UTC-5, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">I don&#39;t agree it is a=
 problem. I don&#39;t see why you&#39;d want to use a unique_ptr=20
<br>to something that already has a local scope. You don&#39;t need the uni=
que_ptr to=20
<br>delete the object and you cannot move it to another scope anyway.=20
<br>
<br>A naked pointer would be enough.
<br></blockquote><div><br></div></span><div>You could, yes, but that&#39;s =
even less idiomatic. Modern C++ wants to push the average user as far from =
memory management as possible. Granted, perhaps that&#39;s not so much of a=
n issue for someone explicitly using the stack, but still, I&#39;d prefer w=
e pushed away from that.</div><div><br></div><div>One option might be a lib=
rary stack_ptr class. The only way to construct it would be from a make_sta=
ck&lt;T&gt;() function which actually performs the stack allocation under t=
he hood, and all the stack_ptr does is call the destructor when it goes out=
 of scope.</div><div><br></div><div>I also don&#39;t understand all the cos=
ternation about stack overflows. It&#39;s already UB to overflow the stack,=
 so why do we care if we add another mechanism to do so?</div><span class=
=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div><br></div></font></=
span></blockquote><div><br></div><div>So are you proposing not worry about =
the development cycle? Anybody with minimum experience of embedded environm=
ents should be aware of subtlety of stack-overflow. A random crash with no =
obvious reason. IMHO, Let the compiler at list warn when possible.</div><di=
v><br></div><div>regards,</div><div>FM.=C2=A0</div></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 />

--001a11c2406c260436050771b024--

.

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

On Sun, Nov 9, 2014 at 1:49 PM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

> At least the compiler can generate diagnostics at compile time rather than
> an actual run-time crash with fixed sized arrays. I
>

Unlikely. While the size of an array is known at compile time, neither the
size of the stack nor the state of the program are known at compile time.
How many functions deep and how much memory is each function using from the
stack are unknowns for the compiler.

David

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Nov 9, 2014 at 1:49 PM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=3D"=
mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><di=
v style=3D"text-align:left">At least the compiler can generate diagnostics =
at compile time rather than an actual run-time crash with fixed sized array=
s. I</div></div></blockquote><div><br></div><div>Unlikely. While the size o=
f an array is known at compile time, neither the size of the stack nor the =
state of the program are known at compile time. How many functions deep and=
 how much memory is each function using from the stack are unknowns for the=
 compiler.<br><br>David</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 />

--e89a8f502982eba9570507824373--

.