------=_Part_611_273649653.1433962822026
Content-Type: multipart/alternative;
 boundary="----=_Part_612_1467229744.1433962822027"

------=_Part_612_1467229744.1433962822027
Content-Type: text/plain; charset=UTF-8

This proposal presents a minimal solution that would allow the
implementation of library facilities for automatic (stack-allocated)
storage, such as Stroustrup's proposed 'bs_array' [N3810]. Compared to
other more elaborate proposals [N4025, N4294], this proposal does not
suffer any of the controversial language implications, such as overloaded
syntax and irregular additions to the type system. As a consequence of its
simplicity, it should also be trivial to implement.

Full paper and demo code can be viewed and downloaded at my OneDrive space:

http://1drv.ms/1GarTte

The demo code is also provided at the online compiler site Coliru:

http://coliru.stacked-crooked.com/a/3ca19b99972df45d

Regards,
Vidar Hasfjord

--

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

<div dir=3D"ltr"><div>This proposal presents a minimal solution that would =
allow the implementation of library facilities for automatic (stack-allocat=
ed) storage, such as Stroustrup's proposed 'bs_array' [N3810]. Compared to =
other more elaborate proposals [N4025, N4294], this proposal does not suffe=
r any of the controversial language implications, such as overloaded syntax=
 and irregular additions to the type system. As a consequence of its simpli=
city, it should also be trivial to implement.</div><div><br></div><div>Full=
 paper and demo code can be viewed and downloaded at my OneDrive
      space:<br>
      <br>
      <font color=3D"#0066cc"><a href=3D"http://1drv.ms/1GarTte">http://1dr=
v.ms/1GarTte</a></font><br>
      </div><div><br></div><div>The demo code is&nbsp;also provided at the =
online compiler site Coliru:</div><div><br></div><div><a href=3D"http://col=
iru.stacked-crooked.com/a/3ca19b99972df45d">http://coliru.stacked-crooked.c=
om/a/3ca19b99972df45d</a></div><div><br>
      Regards,<br>
      Vidar Hasfjord</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_612_1467229744.1433962822027--
------=_Part_611_273649653.1433962822026--

.

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

Small point, but __auto_storage needs an argument to control alignment.

On Wed, Jun 10, 2015 at 2:00 PM, 'Vidar Hasfjord' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> This proposal presents a minimal solution that would allow the
> implementation of library facilities for automatic (stack-allocated)
> storage, such as Stroustrup's proposed 'bs_array' [N3810]. Compared to
> other more elaborate proposals [N4025, N4294], this proposal does not
> suffer any of the controversial language implications, such as overloaded
> syntax and irregular additions to the type system. As a consequence of its
> simplicity, it should also be trivial to implement.
>
> Full paper and demo code can be viewed and downloaded at my OneDrive space:
>
> http://1drv.ms/1GarTte
>
> The demo code is also provided at the online compiler site Coliru:
>
> http://coliru.stacked-crooked.com/a/3ca19b99972df45d
>
> Regards,
> Vidar Hasfjord
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">Small point, but __auto_storage needs an argument to contr=
ol alignment.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Wed, Jun 10, 2015 at 2:00 PM, &#39;Vidar Hasfjord&#39; via ISO C++ Sta=
ndard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-propos=
als@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This proposal=
 presents a minimal solution that would allow the implementation of library=
 facilities for automatic (stack-allocated) storage, such as Stroustrup&#39=
;s proposed &#39;bs_array&#39; [N3810]. Compared to other more elaborate pr=
oposals [N4025, N4294], this proposal does not suffer any of the controvers=
ial language implications, such as overloaded syntax and irregular addition=
s to the type system. As a consequence of its simplicity, it should also be=
 trivial to implement.</div><div><br></div><div>Full paper and demo code ca=
n be viewed and downloaded at my OneDrive
      space:<br>
      <br>
      <font color=3D"#0066cc"><a href=3D"http://1drv.ms/1GarTte" target=3D"=
_blank">http://1drv.ms/1GarTte</a></font><br>
      </div><div><br></div><div>The demo code is=C2=A0also provided at the =
online compiler site Coliru:</div><div><br></div><div><a href=3D"http://col=
iru.stacked-crooked.com/a/3ca19b99972df45d" target=3D"_blank">http://coliru=
..stacked-crooked.com/a/3ca19b99972df45d</a></div><div><br>
      Regards,<br>
      Vidar Hasfjord</div><span class=3D"HOEnZb"><font color=3D"#888888"><d=
iv><br>
</div></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

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

--089e015374f8ff91c8051866f044--

.

------=_Part_2369_970535158.1434236436127
Content-Type: multipart/alternative;
 boundary="----=_Part_2370_1646101541.1434236436127"

------=_Part_2370_1646101541.1434236436127
Content-Type: text/plain; charset=UTF-8

On Saturday, 13 June 2015 15:21:35 UTC+1, Brent Friedman wrote:
>
> Small point, but __auto_storage needs an argument to control alignment.
>

Thanks for the feedback. I have added two new sections to the proposal:


*What about alignment?*

The proposal is framed as an encapsulation of 'alloca', which is commonly
implemented as
returning storage suitably aligned for any scalar type, similar to
'std::malloc'. However, the
design of the feature could include more fine-grained control over
alignment. In this regard,
there is an argument for using a pointer-to-T instead of a void-pointer for
the storage.

*What about life-time?*

While memory allocated by 'alloca' has function-level scope in common
implementations, the
life-time of storage for ASACs should end at the end of the current scope,
similar to VLAs in C.
The exact rules for ASAFs need to be worked out.


I have also updated the code, adding proper destruction for 'bs_array'.

Full paper and demo code: http://1drv.ms/1GarTte
Demo code at Coliru: http://coliru.stacked-crooked.com/a/071f766dd603c4dd

Regards,
Vidar Hasfjord

--

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

<div dir=3D"ltr">On Saturday, 13 June 2015 15:21:35 UTC+1, Brent Friedman  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr">Small point, but __auto=
_storage needs an argument to control alignment.</div></blockquote><div><di=
v>&nbsp;</div></div><div>Thanks for the feedback. I have added two new sect=
ions to the proposal:</div><div><div>&nbsp;</div></div><blockquote style=3D=
"margin-right: 0px;" dir=3D"ltr"><div><strong>What about alignment?</strong=
></div><div><div>&nbsp;</div></div><div>The proposal is framed as an encaps=
ulation of 'alloca', which is commonly implemented as<div>returning storage=
 suitably aligned for any scalar type, similar to 'std::malloc'. However, t=
he</div><div>design of the feature could include more fine-grained control =
over alignment. In this regard,</div><div>there is an argument for using a =
pointer-to-T instead of a void-pointer for the storage.</div></div><div><di=
v>&nbsp;</div></div><div><strong>What about life-time?</strong></div><div><=
div>&nbsp;</div></div><div>While memory allocated by 'alloca' has function-=
level scope in common implementations, the<div>life-time of storage for ASA=
Cs should end at the end of the current scope, similar to VLAs in C.</div><=
div>The exact rules for ASAFs need to be worked out.</div></div></blockquot=
e><div>&nbsp;</div><div>I have also updated the code, adding proper destruc=
tion for 'bs_array'.</div><div><div>&nbsp;</div></div><div><div>Full paper =
and demo code: <font color=3D"#0066cc"><a onmousedown=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2F1drv.ms%2F1GarTte\46sa\75D\46sntz\075=
1\46usg\75AFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2F1drv.ms%2F1GarTte\46sa\=
75D\46sntz\0751\46usg\75AFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA';return true;" h=
ref=3D"http://1drv.ms/1GarTte" target=3D"_blank" rel=3D"nofollow">http://1d=
rv.ms/1GarTte</a></font><div>Demo code at&nbsp;Coliru: <a href=3D"http://co=
liru.stacked-crooked.com/a/071f766dd603c4dd">http://coliru.stacked-crooked.=
com/a/071f766dd603c4dd</a></div></div><div><div>      <br></div><div>Regard=
s,</div><div>      Vidar Hasfjord</div></div><div><div><br></div></div></di=
v>
</div>

<p></p>

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

------=_Part_2370_1646101541.1434236436127--
------=_Part_2369_970535158.1434236436127--

.

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

This suggestion ignores the main problem of stack based array classes: that=
 the stack memory for the ctor parameters can't be released when the ctor r=
eturns, as it is locked in behind the block allocated for the array content=
s. I don't even want to think about what happens if these contain variable =
length arrays themselves.

This said it may still be interesting approach but the rules for how the ca=
ll site has to deal with the lost memory must be clearly defined.

--=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_41_1185482260.1434264205465--

.

------=_Part_2903_323504882.1434332104947
Content-Type: multipart/alternative;
 boundary="----=_Part_2904_1865441217.1434332104947"

------=_Part_2904_1865441217.1434332104947
Content-Type: text/plain; charset=UTF-8



On Wednesday, June 10, 2015 at 3:00:22 PM UTC-4, Vidar Hasfjord wrote:
>
> This proposal presents a minimal solution that would allow the
> implementation of library facilities for automatic (stack-allocated)
> storage, such as Stroustrup's proposed 'bs_array' [N3810]. Compared to
> other more elaborate proposals [N4025, N4294], this proposal does not
> suffer any of the controversial language implications, such as overloaded
> syntax and irregular additions to the type system. As a consequence of its
> simplicity, it should also be trivial to implement.
>
> Full paper and demo code can be viewed and downloaded at my OneDrive space:
>
> http://1drv.ms/1GarTte
>
> The demo code is also provided at the online compiler site Coliru:
>
> http://coliru.stacked-crooked.com/a/3ca19b99972df45d
>
>    As another small point, you should consider changing the name.  In
American English, "bs" is usually understood to mean "bullshit", which is a
very rude word meaning nonsense or a complete lie.

Joe Gottman

--

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

<br><br>On Wednesday, June 10, 2015 at 3:00:22 PM UTC-4, Vidar Hasfjord wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>This =
proposal presents a minimal solution that would allow the implementation of=
 library facilities for automatic (stack-allocated) storage, such as Strous=
trup's proposed 'bs_array' [N3810]. Compared to other more elaborate propos=
als [N4025, N4294], this proposal does not suffer any of the controversial =
language implications, such as overloaded syntax and irregular additions to=
 the type system. As a consequence of its simplicity, it should also be tri=
vial to implement.</div><div><br></div><div>Full paper and demo code can be=
 viewed and downloaded at my OneDrive
      space:<br>
      <br>
      <font color=3D"#0066cc"><a href=3D"http://1drv.ms/1GarTte" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2F1drv.ms%2F1GarTte\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
b1AwTpWDK1mreaqAwrJMMl5hOsA';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2F1drv.ms%2F1GarTte\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA';return true;">http://1drv.ms/1Ga=
rTte</a></font><br>
      </div><div><br></div><div>The demo code is&nbsp;also provided at the =
online compiler site Coliru:</div><div><br></div><div><a href=3D"http://col=
iru.stacked-crooked.com/a/3ca19b99972df45d" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
coliru.stacked-crooked.com%2Fa%2F3ca19b99972df45d\46sa\75D\46sntz\0751\46us=
g\75AFQjCNFtxImv4E6sEhstIGYWDA_ivNgopg';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fcoliru.stacked-crooked.com%2=
Fa%2F3ca19b99972df45d\46sa\75D\46sntz\0751\46usg\75AFQjCNFtxImv4E6sEhstIGYW=
DA_ivNgopg';return true;">http://coliru.stacked-crooked.<wbr>com/a/3ca19b99=
972df45d</a></div><div><br></div></div></blockquote><div>&nbsp;&nbsp; As an=
other small point, you should consider changing the name.&nbsp; In American=
 English, "bs" is usually understood to mean "bullshit", which is a very ru=
de word meaning nonsense or a complete lie.<br><br>Joe Gottman <br></div>

<p></p>

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

------=_Part_2904_1865441217.1434332104947--
------=_Part_2903_323504882.1434332104947--

.

------=_Part_7_380542341.1434887739186
Content-Type: multipart/alternative;
 boundary="----=_Part_8_568824421.1434887739186"

------=_Part_8_568824421.1434887739186
Content-Type: text/plain; charset=UTF-8

On Sunday, 14 June 2015 07:43:25 UTC+1, Bengt Gustafsson wrote:
>
> This suggestion ignores the main problem of stack based array classes:
> that the stack memory for the ctor parameters can't be released when the
> ctor returns, as it is locked in behind the block allocated for the array
> contents.


Thanks for bringing my attention to this issue. Can you point me to a
discussion about the issue, as well as solutions, if any?


Although this proposal does not trap the parameters per se, the
implementation may need to make temporary variables to avoid evaluating
arguments more than once.


It merits some clarification in the paper, so I have added the following
section:

*What about the main problem of stack-based array classes: that the stack
memory for the ctor parameters can't be released when the ctor returns, as
it is locked in behind the block allocated for the array contents?*



This proposal does not trap the parameters per se. Note that, with the
3-phase calling procedure (Snyder/Smith), the actual storage allocation
('alloca') happens at the caller site in-between function calls to
*auto_size_fun* and the ASAF (which may be an ASAC constructor call). This
means that parameter clean-up for *auto_size_fun* happens before the
allocation, and the parameter setup and clean-up for the ASAF call happens
after the allocation. However, since the solution mandates that the
function arguments shall only be evaluated once, the compiler may need to
use extra stack space to store the results. Note that such temporaries are
only required when argument evaluation has side-effects. And note that such
temporaries would be required even if you did the storage allocation
manually, so the proposed solution introduces no overhead in this regard.



For example, consider the following declaration:


  bs_array<int> a(n);


With the prescribed 3-phase calling procedure it is equivalent to:


  size_t __size = bs_array<int>::auto_size(n);
  void* __storage = alloca(__size);
  bs_array<int> a(n, __storage);


The temporary variables *__size* and *__storage *are only for exposition,
and in practice they can be elided, simplifying the code to the following
nested calls:


  bs_array<int> a(n, alloca(bs_array<int>::auto_size(n)));


Now consider an argument with side-effects, for example:


  bs_array<int> a(read_count(cin));


In this case, the compiler needs to create a temporary for the argument:


  size_t __n = read_count(cin);
  bs_array<int> a(__n, alloca(bs_array<int>::auto_size(__n)));


This is similar to how the compiler may need to create temporaries to
implement the range-based for-loop
<http://en.cppreference.com/w/cpp/language/range-for>.

Note that temporaries can often be held in registers, needing no extra
stack space at all. And, even if there needs to be stack space allocated
for temporaries, I would expect the amount of extra stack space to be
insignificant in practice.

Updated paper at my OneDrive space: http://1drv.ms/1GarTte
<http://www.google.com/url?q=http%3A%2F%2F1drv.ms%2F1GarTte&sa=D&sntz=1&usg=AFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA>

Regards,
Vidar Hasfjord

--

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

<div dir=3D"ltr">On Sunday, 14 June 2015 07:43:25 UTC+1, Bengt Gustafsson  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">This suggestion ignores =
the main problem of stack based array classes: that the stack memory for th=
e ctor parameters can't be released when the ctor returns, as it is locked =
in behind the block allocated for the array contents.</blockquote><div><br>=
</div><p class=3D"western">Thanks for bringing my attention to this issue.
Can you point me to a discussion about the issue, as well as
solutions, if any?</p>
<p class=3D"western"><br></p><p class=3D"western">Although this proposal do=
es not trap the
parameters per se, the implementation may need to make temporary
variables to avoid evaluating arguments more than once.</p>
<p class=3D"western"><br></p><p class=3D"western">It merits some clarificat=
ion in the paper, so I
have added the following section:</p>
<dl>
 <dt class=3D"western"><br></dt></dl><blockquote style=3D"margin: 0 0 0 40p=
x; border: none; padding: 0px;"><dl><dt class=3D"western"><b>What about the=
 main problem of stack-based array
 classes: that the stack memory for the ctor parameters can't be
 released when the ctor returns, as it is locked in behind the block
 allocated for the array contents?</b></dt></dl></blockquote><div>&nbsp;</d=
iv><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><d=
l><dt class=3D"western">This proposal does not trap the parameters per se. =
Note that, with
 the 3-phase calling procedure (Snyder/Smith), the actual storage
 allocation ('alloca') happens at the caller site in-between function calls=
 to
 <i>auto_size_fun</i> and the ASAF (which may be an ASAC constructor
 call). This means that parameter clean-up for <i>auto_size_fun</i>
 happens before the allocation, and the parameter setup and clean-up
 for the ASAF call happens after the allocation. However, since the
 solution mandates that the function arguments shall only be
 evaluated once, the compiler may need to use extra stack space to
 store the results. Note that such temporaries are only required when
 argument evaluation has side-effects. And
 note that such temporaries would be required even if you did the
 storage allocation manually, so the proposed solution introduces no
 overhead in this regard.</dt></dl></blockquote><div>&nbsp;</div>
<p class=3D"western">
For example, consider the  following declaration:</p>
<p class=3D"western"><br></p><p class=3D"western"><font face=3D"courier new=
, monospace">&nbsp; bs_array&lt;int&gt; a(n);</font></p>
<p class=3D"western"><br></p><p class=3D"western">With the prescribed 3-pha=
se calling procedure it
is equivalent to:</p>
<p class=3D"western"><br></p><p class=3D"western"><font face=3D"courier new=
, monospace">&nbsp; size_t __size =3D bs_array&lt;int&gt;::auto_size(n);<br=
>&nbsp; void* __storage =3D alloca(__size);<br>&nbsp; bs_array&lt;int&gt; a=
(n,
__storage);</font></p>
<p class=3D"western"><br></p><p class=3D"western">The temporary variables <=
i>__size</i> and <i>__storage </i>are
only for exposition, and in practice they can be elided, simplifying
the code to the following nested calls:</p>
<p class=3D"western"><br></p><p class=3D"western"><font face=3D"courier new=
, monospace">&nbsp; bs_array&lt;int&gt; a(n,
alloca(bs_array&lt;int&gt;::auto_size(n)));</font></p>
<p class=3D"western"><br></p><p class=3D"western">Now consider an argument =
with side-effects, for
example:</p>
<p class=3D"western"><br></p><p class=3D"western"><font face=3D"courier new=
, monospace">&nbsp; bs_array&lt;int&gt; a(read_count(cin));</font></p>
<p class=3D"western"><br></p><p class=3D"western">In this case, the compile=
r needs to create a
temporary for the argument:</p>
<p class=3D"western"><br></p><p class=3D"western"><font face=3D"courier new=
, monospace">&nbsp; size_t __n =3D read_count(cin);<br>&nbsp; bs_array&lt;i=
nt&gt;
a(__n, alloca(bs_array&lt;int&gt;::auto_size(__n)));</font></p>
<p class=3D"western"><br></p><p class=3D"western">This is similar to how th=
e compiler may need to
create temporaries to implement the <a href=3D"http://en.cppreference.com/w=
/cpp/language/range-for">range-based for-loop</a>.</p>
<div><br></div><div>Note that temporaries can often be held in
registers, needing no extra stack space at all. And, even if there
needs to be stack space allocated for temporaries, I would expect the
amount of extra stack space to be insignificant in practice.</div><div><br>=
</div><div>Updated paper at my OneDrive space:&nbsp;<a href=3D"http://www.g=
oogle.com/url?q=3Dhttp%3A%2F%2F1drv.ms%2F1GarTte&amp;sa=3DD&amp;sntz=3D1&am=
p;usg=3DAFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA" target=3D"_blank" rel=3D"nofoll=
ow" style=3D"cursor: pointer;">http://1drv.ms/1GarTte</a></div><div><br></d=
iv><div>Regards,</div><div>Vidar Hasfjord</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_8_568824421.1434887739186--
------=_Part_7_380542341.1434887739186--

.

------=_Part_177_859797063.1434888510660
Content-Type: multipart/alternative;
 boundary="----=_Part_178_191777178.1434888510660"

------=_Part_178_191777178.1434888510660
Content-Type: text/plain; charset=UTF-8

On Monday, 15 June 2015 02:35:05 UTC+1, jgot...@gmail.com wrote:

> you should consider changing the name. In American English, "bs" is
> usually understood to mean "bullshit".
>

I am aware of this. However, my proposal is in response to Bjarne
Stroustrup's paper, "Alternatives for Array Extensions" [N3810
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf>], in
which he introduces 'bs_array' as a *basic stack-allocated array*. This
name may also be a word play on "bike-shed", referring to the often
drawn-out and heated process of choosing a simple name.


Anyway, to clarify that this is not a name proposed for standardisation, I
have now included Stroustrup's comment on the name in the paper (page 2,
code comment).


My suggestions for a standard name: 'auto_array' or 'asac_array'.


Updated paper at my OneDrive space: http://1drv.ms/1GarTte
<http://www.google.com/url?q=http%3A%2F%2F1drv.ms%2F1GarTte&sa=D&sntz=1&usg=AFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA>


PS. I would hope that the initials B.S. have more positive associations in
this community. :-)

Regards,
Vidar Hasfjord

--

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

<div dir=3D"ltr">On Monday, 15 June 2015 02:35:05 UTC+1, jgot...@gmail.com =
 wrote:<div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><p class=3D"w=
estern">you should consider
changing the name. In American English, "bs" is usually
understood to mean "bullshit".</p></div></blockquote><div><br></div><div><p=
 class=3D"western">I am aware of this. However, my proposal is in
response to Bjarne Stroustrup's paper, "Alternatives for Array
Extensions" [<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2013/n3810.pdf">N3810</a>], in which he introduces '<font face=3D"courier n=
ew, monospace">bs_array</font>' as a
<i>basic stack-allocated array</i>. This name may also be a word play
on "bike-shed", referring to the often drawn-out and heated
process of choosing a simple name.<br></p><p class=3D"western"><br></p>
<p class=3D"western">Anyway, to clarify that this is not a name
proposed for standardisation, I have now included Stroustrup's
comment on the name in the paper (page 2, code comment).</p><p class=3D"wes=
tern"><br></p><p class=3D"western">My suggestions for a standard name: '<fo=
nt face=3D"courier new, monospace">auto_array</font>' or '<font face=3D"cou=
rier new, monospace">asac_array</font>'.<br></p><p class=3D"western"><br></=
p><p class=3D"western">Updated paper at my OneDrive space:&nbsp;<a href=3D"=
http://www.google.com/url?q=3Dhttp%3A%2F%2F1drv.ms%2F1GarTte&amp;sa=3DD&amp=
;sntz=3D1&amp;usg=3DAFQjCNHb1AwTpWDK1mreaqAwrJMMl5hOsA" rel=3D"nofollow" ta=
rget=3D"_blank" style=3D"cursor: pointer;">http://1drv.ms/1GarTte</a><br></=
p><p class=3D"western"><br></p>
<p class=3D"western">PS. I would hope that the initials B.S. have more
positive associations in this community. :-)</p></div></div><div><br></div>=
<div>Regards,</div><div>Vidar Hasfjord</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_178_191777178.1434888510660--
------=_Part_177_859797063.1434888510660--

.