------=_Part_45_33144747.1364952753857
Content-Type: text/plain; charset=ISO-8859-1

N3532 lays out a proposal<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3532.html>for including a dynamic array type in C++ called `dynarray`. A "dynamic
array" is an array who's length is fixed, but is only provided at runtime,
rather than static arrays that have compile-time array lengths.

The big selling point of `dynarray`, and the reason it exists, is so that
we can have stack-based arrays with runtime-determined sizes. Instead of
taking the C99 approach of allowing this:

int size = 5;
Type arr[size];

We would instead allow this:

int size = 5;
dynarray<Type> arr(size);

The dynamic array proposal allows (but does not require) that `arr` in the
above case be allocated on the stack. The dynamic array is only allowed to
be allocated on the stack when the array itself is on the stack; if you
were to do `new dynarray<Type>`, you would have a heap-allocated array.

I do have some concerns about this though. One is purely functional and
easily resolved: `dynarray` should have a constructor that can use
default-initialization of its array elements instead of
value-initialization. But this should be true of *all standard library
containers* and warrants a full proposal. Another is the lack of allocator
support when not using stack memory; again, relatively easily resolved.

The main issue is this:

dynarray<Type> GetArray(int size)
{
  dynarray<Type> arr(size);
  //Fill in arr with stuff.
  return arr;
}

unique_ptr<dynarray<Type>> arrPtr = new dynarray<Type>(GetArray(12));

So... what happens here? Assuming that elision works in this case,
`dynarray`, we have a non-trivial problem. The `dynarray` being
heap-allocated is going to have to heap-allocate its own memory. But the
`dynarray` being stack allocated, the return value from `GetArray`, will
stack-allocate its memory. Which means that it's contents will have to be *
copied* into the heap-allocated `dynarray`.

And there is nothing that we can do about that. That's the problem.

It should be possible to create a `dynarray` on the stack which is *required
* to use heap-allocated memory. Therefore, we can be certain that any such
`dynarray` instance can be cheaply moved into another `dynarray` instance.

It should be the user's choice to use `dynarray` as a fixed-size `vector`,
with all of the move characteristics of that class. Sometimes the user
wants stack allocation for a fixed-size array; and sometimes they don't. We
shouldn't leave that to chance; we should have some way of enforcing it.

Alternatively, if the user can't have that choice, then we need a
fixed-size `vector` class that *does* have the move characteristics of
`vector`, but without the resizing. In that case, `dynarray` should only be
able to be used on the stack, not as class members or with `new` and such.
The user should be able to choose; this choice can either come from
`dynarray` itself, or it can come from picking which class to use.

But the current half-state, where you can't explicitly choose for an
automatic variable to be heap-allocated, is not good.

--

---
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/?hl=en.



------=_Part_45_33144747.1364952753857
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3532.ht=
ml">N3532 lays out a proposal</a> for including a dynamic array type in C++=
 called `dynarray`. A "dynamic array" is an array who's length is fixed, bu=
t is only provided at runtime, rather than static arrays that have compile-=
time array lengths.<br><br>The big selling point of `dynarray`, and the rea=
son it exists, is so that we can have stack-based arrays with runtime-deter=
mined sizes. Instead of taking the C99 approach of allowing this:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> size </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Type</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> arr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">size</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">];</span></div></=
code></div><br>We would instead allow this:<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> size </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>dy=
narray</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> arr</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>The dynamic array=
 proposal allows (but does not require) that `arr` in the above case be all=
ocated on the stack. The dynamic array is only allowed to be allocated on t=
he stack when the array itself is on the stack; if you were to do `new dyna=
rray&lt;Type&gt;`, you would have a heap-allocated array.<br><br>I do have =
some concerns about this though. One is purely functional and easily resolv=
ed: `dynarray` should have a constructor that can use default-initializatio=
n of its array elements instead of value-initialization. But this should be=
 true of <i>all standard library containers</i> and warrants a full proposa=
l. Another is the lack of allocator support when not using stack memory; ag=
ain, relatively easily resolved.<br><br>The main issue is this:<br><br><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">dynarray</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Type</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">GetArray</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> size</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; dyna=
rray</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> arr</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">//Fill in arr with stuff.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> arr</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br>unique_ptr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">dynarray</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arrP=
tr </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> dynarray</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Type</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">GetArray</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">12</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></div></code></div><br>So... what happens here? Assuming tha=
t elision works in this case, `dynarray`, we have a non-trivial problem. Th=
e `dynarray` being heap-allocated is going to have to heap-allocate its own=
 memory. But the `dynarray` being stack allocated, the return value from `G=
etArray`, will stack-allocate its memory. Which means that it's contents wi=
ll have to be <i>copied</i> into the heap-allocated `dynarray`.<br><br>And =
there is nothing that we can do about that. That's the problem.<br><br>It s=
hould be possible to create a `dynarray` on the stack which is <i>required<=
/i> to use heap-allocated memory. Therefore, we can be certain that any suc=
h `dynarray` instance can be cheaply moved into another `dynarray` instance=
..<br><br>It should be the user's choice to use `dynarray` as a fixed-size `=
vector`, with all of the move characteristics of that class. Sometimes the =
user wants stack allocation for a fixed-size array; and sometimes they don'=
t. We shouldn't leave that to chance; we should have some way of enforcing =
it.<br><br>Alternatively, if the user can't have that choice, then we need =
a fixed-size `vector` class that <i>does</i> have the move characteristics =
of `vector`, but without the resizing. In that case, `dynarray` should only=
 be able to be used on the stack, not as class members or with `new` and su=
ch. The user should be able to choose; this choice can either come from `dy=
narray` itself, or it can come from picking which class to use.<br><br>But =
the current half-state, where you can't explicitly choose for an automatic =
variable to be heap-allocated, is not good.<br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_45_33144747.1364952753857--

.

------=_Part_4089_16231764.1364971987978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mercredi 3 avril 2013 03:32:33 UTC+2, Nicol Bolas a =E9crit :
>
> The main issue is this:
>
> dynarray<Type> GetArray(int size)
> {
>   dynarray<Type> arr(size);
>   //Fill in arr with stuff.
>   return arr;
> }
>
> unique_ptr<dynarray<Type>> arrPtr =3D new dynarray<Type>(GetArray(12));
>
> So... what happens here? Assuming that elision works in this case,=20
> `dynarray`, we have a non-trivial problem. The `dynarray` being=20
> heap-allocated is going to have to heap-allocate its own memory. But the=
=20
> `dynarray` being stack allocated, the return value from `GetArray`, will=
=20
> stack-allocate its memory. Which means that it's contents will have to be=
=20
> *copied* into the heap-allocated `dynarray`.
>

Could you clarify your example? As far as I understand, with copy elision,=
=20
there is no stack dynarray here. arr is constructed in the return value,=20
which can't be on the stack.
(it would help to have an implementation to play with)

--=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/?hl=3Den.



------=_Part_4089_16231764.1364971987978
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mercredi 3 avril 2013 03:32:33 UTC+2, Nicol Bolas a =E9crit&nbsp;:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">The main issue is this:<br><br><div =
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code><div><span st=
yle=3D"color:#000">dynarray</span><span style=3D"color:#660">&lt;</span><sp=
an style=3D"color:#606">Type</span><span style=3D"color:#660">&gt;</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#606">GetArray</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><sp=
an style=3D"color:#000"> size</span><span style=3D"color:#660">)</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>&nbsp; dynarray</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#606">Type</span><span style=3D"color:#660">=
&gt;</span><span style=3D"color:#000"> arr</span><span style=3D"color:#660"=
>(</span><span style=3D"color:#000">size</span><span style=3D"color:#660">)=
;</span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#=
800">//Fill in arr with stuff.</span><span style=3D"color:#000"><br>&nbsp; =
</span><span style=3D"color:#008">return</span><span style=3D"color:#000"> =
arr</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><=
br>unique_ptr</span><span style=3D"color:#660">&lt;</span><span style=3D"co=
lor:#000">dynarray</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#606">Type</span><span style=3D"color:#660">&gt;&gt;</span><span =
style=3D"color:#000"> arrPtr </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">new</span><span=
 style=3D"color:#000"> dynarray</span><span style=3D"color:#660">&lt;</span=
><span style=3D"color:#606">Type</span><span style=3D"color:#660">&gt;(</sp=
an><span style=3D"color:#606">GetArray</span><span style=3D"color:#660">(</=
span><span style=3D"color:#066">12</span><span style=3D"color:#660">));</sp=
an><span style=3D"color:#000"><br></span></div></code></div><br>So... what =
happens here? Assuming that elision works in this case, `dynarray`, we have=
 a non-trivial problem. The `dynarray` being heap-allocated is going to hav=
e to heap-allocate its own memory. But the `dynarray` being stack allocated=
, the return value from `GetArray`, will stack-allocate its memory. Which m=
eans that it's contents will have to be <i>copied</i> into the heap-allocat=
ed `dynarray`.<br></blockquote><div><br>Could you clarify your example? As =
far as I understand, with copy elision, there is no stack dynarray here. ar=
r is constructed in the return value, which can't be on the stack.<br>(it w=
ould help to have an implementation to play with)<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4089_16231764.1364971987978--

.

------=_Part_2210_32069283.1364984435151
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tuesday, April 2, 2013 11:53:07 PM UTC-7, Marc wrote:
>
> Le mercredi 3 avril 2013 03:32:33 UTC+2, Nicol Bolas a =E9crit :
>>
>> The main issue is this:
>>
>> dynarray<Type> GetArray(int size)
>> {
>>   dynarray<Type> arr(size);
>>   //Fill in arr with stuff.
>>   return arr;
>> }
>>
>> unique_ptr<dynarray<Type>> arrPtr =3D new dynarray<Type>(GetArray(12));
>>
>> So... what happens here? Assuming that elision works in this case,=20
>> `dynarray`, we have a non-trivial problem. The `dynarray` being=20
>> heap-allocated is going to have to heap-allocate its own memory. But the=
=20
>> `dynarray` being stack allocated, the return value from `GetArray`, will=
=20
>> stack-allocate its memory. Which means that it's contents will have to b=
e=20
>> *copied* into the heap-allocated `dynarray`.
>>
>
> Could you clarify your example? As far as I understand, with copy elision=
,=20
> there is no stack dynarray here. arr is constructed in the return value,=
=20
> which can't be on the stack.
> (it would help to have an implementation to play with)
>

Well, there's the question of whether copy elision can even work with=20
`dynarray`. But beyond that, how is this not a stack object? You can elide=
=20
the copy from `arr` into the return value, but you can't elide the copy=20
construction from the return value into the `new` expression.

And if the `new` construction is somehow elided, then feel free to turn it=
=20
into this:

dynarray<Type> arr =3D GetArray(12);
unique_ptr<dynarray<Type>> arrPtr =3D new dynarray<Type>(std::move(arr));

The point is that I want to be able to have some way of ensuring that no=20
copying happens in this case. If that were a `vector<Type>`, I would know=
=20
that there would be no copying.

--=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/?hl=3Den.



------=_Part_2210_32069283.1364984435151
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 2, 2013 11:53:07 PM UTC-7, Marc wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">Le mercredi 3 avril 2013 03:32:33 UTC+2, =
Nicol Bolas a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The mai=
n issue is this:<br><br><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:br=
eak-word"><code><div><span style=3D"color:#000">dynarray</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#606">Type</span><span styl=
e=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">GetArray</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#008">int</span><span style=3D"color:#000"> size</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; dynarray</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Type</s=
pan><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> arr</=
span><span style=3D"color:#660">(</span><span style=3D"color:#000">size</sp=
an><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>&nbsp=
; </span><span style=3D"color:#800">//Fill in arr with stuff.</span><span s=
tyle=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">return</sp=
an><span style=3D"color:#000"> arr</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><=
span style=3D"color:#000"><br><br>unique_ptr</span><span style=3D"color:#66=
0">&lt;</span><span style=3D"color:#000">dynarray</span><span style=3D"colo=
r:#660">&lt;</span><span style=3D"color:#606">Type</span><span style=3D"col=
or:#660">&gt;&gt;</span><span style=3D"color:#000"> arrPtr </span><span sty=
le=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">new</span><span style=3D"color:#000"> dynarray</span><span =
style=3D"color:#660">&lt;</span><span style=3D"color:#606">Type</span><span=
 style=3D"color:#660">&gt;(</span><span style=3D"color:#606">GetArray</span=
><span style=3D"color:#660">(</span><span style=3D"color:#066">12</span><sp=
an style=3D"color:#660">));</span><span style=3D"color:#000"><br></span></d=
iv></code></div><br>So... what happens here? Assuming that elision works in=
 this case, `dynarray`, we have a non-trivial problem. The `dynarray` being=
 heap-allocated is going to have to heap-allocate its own memory. But the `=
dynarray` being stack allocated, the return value from `GetArray`, will sta=
ck-allocate its memory. Which means that it's contents will have to be <i>c=
opied</i> into the heap-allocated `dynarray`.<br></blockquote><div><br>Coul=
d you clarify your example? As far as I understand, with copy elision, ther=
e is no stack dynarray here. arr is constructed in the return value, which =
can't be on the stack.<br>(it would help to have an implementation to play =
with)<br></div></blockquote><div><br>Well, there's the question of whether =
copy elision can even work with `dynarray`. But beyond that, how is this no=
t a stack object? You can elide the copy from `arr` into the return value, =
but you can't elide the copy construction from the return value into the `n=
ew` expression.<br><br>And if the `new` construction is somehow elided, the=
n feel free to turn it into this:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">dynarray</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Type</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> arr </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">GetArray<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">12</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>unique_ptr</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">dynarray</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Type</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> arrPtr </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">new</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> dynarray</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">move</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">arr</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">));</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></div><br>The point is that I want to=
 be able to have some way of ensuring that no copying happens in this case.=
 If that were a `vector&lt;Type&gt;`, I would know that there would be no c=
opying.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2210_32069283.1364984435151--

.

------=_Part_121_22446078.1364985665847
Content-Type: text/plain; charset=ISO-8859-1

Op woensdag 3 april 2013 12:20:35 UTC+2 schreef Nicol Bolas het volgende:

> Well, there's the question of whether copy elision can even work with
> `dynarray`. But beyond that, how is this not a stack object? You can elide
> the copy from `arr` into the return value, but you can't elide the copy
> construction from the return value into the `new` expression.
>
> And if the `new` construction is somehow elided, then feel free to turn it
> into this:
>
> dynarray<Type> arr = GetArray(12);
> unique_ptr<dynarray<Type>> arrPtr = new dynarray<Type>(std::move(arr));
>
> The point is that I want to be able to have some way of ensuring that no
> copying happens in this case. If that were a `vector<Type>`, I would know
> that there would be no copying.
>

 Sounds like a unique_array<> or shared_array<> would be a better match for
your use case.

--

---
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/?hl=en.



------=_Part_121_22446078.1364985665847
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op woensdag 3 april 2013 12:20:35 UTC+2 schreef Nicol Bolas het volgende:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Well, there's the question o=
f whether copy elision can even work with `dynarray`. But beyond that, how =
is this not a stack object? You can elide the copy from `arr` into the retu=
rn value, but you can't elide the copy construction from the return value i=
nto the `new` expression.<br><div><br>And if the `new` construction is some=
how elided, then feel free to turn it into this:<br><br><div style=3D"backg=
round-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:sol=
id;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#=
000">dynarray</span><span style=3D"color:#660">&lt;</span><span style=3D"co=
lor:#606">Type</span><span style=3D"color:#660">&gt;</span><span style=3D"c=
olor:#000"> arr </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> </span><span style=3D"color:#606">GetArray</span><span style=
=3D"color:#660">(</span><span style=3D"color:#066">12</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"><br>unique_ptr</span><span =
style=3D"color:#660">&lt;</span><span style=3D"color:#000">dynarray</span><=
span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Type</span>=
<span style=3D"color:#660">&gt;&gt;</span><span style=3D"color:#000"> arrPt=
r </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">new</span><span style=3D"color:#000"> dyna=
rray</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#606"=
>Type</span><span style=3D"color:#660">&gt;(</span><span style=3D"color:#00=
0">std</span><span style=3D"color:#660">::</span><span style=3D"color:#000"=
>move</span><span style=3D"color:#660">(</span><span style=3D"color:#000">a=
rr</span><span style=3D"color:#660">))<wbr>;</span><span style=3D"color:#00=
0"><br></span></div></code></div><br>The point is that I want to be able to=
 have some way of ensuring that no copying happens in this case. If that we=
re a `vector&lt;Type&gt;`, I would know that there would be no copying.<br>=
</div></blockquote><div><br></div><div>&nbsp;Sounds like a unique_array&lt;=
&gt; or shared_array&lt;&gt; would be a better match for your use case.&nbs=
p;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_121_22446078.1364985665847--

.

------=_Part_338_18453682.1365035372337
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, April 3, 2013 3:41:05 AM UTC-7, Olaf van der Spek wrote:
>
> Op woensdag 3 april 2013 12:20:35 UTC+2 schreef Nicol Bolas het volgende:
>
>> Well, there's the question of whether copy elision can even work with
>> `dynarray`. But beyond that, how is this not a stack object? You can elide
>> the copy from `arr` into the return value, but you can't elide the copy
>> construction from the return value into the `new` expression.
>>
>> And if the `new` construction is somehow elided, then feel free to turn
>> it into this:
>>
>> dynarray<Type> arr = GetArray(12);
>> unique_ptr<dynarray<Type>> arrPtr = new dynarray<Type>(std::move(arr));
>>
>> The point is that I want to be able to have some way of ensuring that no
>> copying happens in this case. If that were a `vector<Type>`, I would know
>> that there would be no copying.
>>
>
>  Sounds like a unique_array<> or shared_array<> would be a better match
> for your use case.
>

Considering that those classes don't exist, and there are no proposals to
add them, no they wouldn't. More importantly, there's no reason why we need
such things if we're going to get a `dynarray` type that can be used
anywhere.

--

---
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/?hl=en.



------=_Part_338_18453682.1365035372337
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, April 3, 2013 3:41:05 AM UTC-7, Olaf van der Spek wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">Op woensdag 3 april 2013 12:20:35 U=
TC+2 schreef Nicol Bolas het volgende:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">Well, there's the question of whether copy elision can even work wit=
h `dynarray`. But beyond that, how is this not a stack object? You can elid=
e the copy from `arr` into the return value, but you can't elide the copy c=
onstruction from the return value into the `new` expression.<br><div><br>An=
d if the `new` construction is somehow elided, then feel free to turn it in=
to this:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#000">dynarray</span><span style=3D"color=
:#660">&lt;</span><span style=3D"color:#606">Type</span><span style=3D"colo=
r:#660">&gt;</span><span style=3D"color:#000"> arr </span><span style=3D"co=
lor:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color=
:#606">GetArray</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#066">12</span><span style=3D"color:#660">);</span><span style=3D"color:=
#000"><br>unique_ptr</span><span style=3D"color:#660">&lt;</span><span styl=
e=3D"color:#000">dynarray</span><span style=3D"color:#660">&lt;</span><span=
 style=3D"color:#606">Type</span><span style=3D"color:#660">&gt;&gt;</span>=
<span style=3D"color:#000"> arrPtr </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">new</span=
><span style=3D"color:#000"> dynarray</span><span style=3D"color:#660">&lt;=
</span><span style=3D"color:#606">Type</span><span style=3D"color:#660">&gt=
;(</span><span style=3D"color:#000">std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">move</span><span style=3D"color:#660">(</=
span><span style=3D"color:#000">arr</span><span style=3D"color:#660">))<wbr=
>;</span><span style=3D"color:#000"><br></span></div></code></div><br>The p=
oint is that I want to be able to have some way of ensuring that no copying=
 happens in this case. If that were a `vector&lt;Type&gt;`, I would know th=
at there would be no copying.<br></div></blockquote><div><br></div><div>&nb=
sp;Sounds like a unique_array&lt;&gt; or shared_array&lt;&gt; would be a be=
tter match for your use case.&nbsp;</div></blockquote><div><br>Considering =
that those classes don't exist, and there are no proposals to add them, no =
they wouldn't. More importantly, there's no reason why we need such things =
if we're going to get a `dynarray` type that can be used anywhere. <br></di=
v>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_338_18453682.1365035372337--

.

------=_Part_592_33463809.1365058427542
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mercredi 3 avril 2013 12:20:35 UTC+2, Nicol Bolas a =E9crit :

>
> On Tuesday, April 2, 2013 11:53:07 PM UTC-7, Marc wrote:
>>
>> Le mercredi 3 avril 2013 03:32:33 UTC+2, Nicol Bolas a =E9crit :
>>>
>>> The main issue is this:
>>>
>>> dynarray<Type> GetArray(int size)
>>> {
>>>   dynarray<Type> arr(size);
>>>   //Fill in arr with stuff.
>>>   return arr;
>>> }
>>>
>>> unique_ptr<dynarray<Type>> arrPtr =3D new dynarray<Type>(GetArray(12));
>>>
>>> So... what happens here? Assuming that elision works in this case,=20
>>> `dynarray`, we have a non-trivial problem. The `dynarray` being=20
>>> heap-allocated is going to have to heap-allocate its own memory. But th=
e=20
>>> `dynarray` being stack allocated, the return value from `GetArray`, wil=
l=20
>>> stack-allocate its memory. Which means that it's contents will have to =
be=20
>>> *copied* into the heap-allocated `dynarray`.
>>>
>>
>> Could you clarify your example? As far as I understand, with copy=20
>> elision, there is no stack dynarray here. arr is constructed in the retu=
rn=20
>> value, which can't be on the stack.
>> (it would help to have an implementation to play with)
>>
>
> Well, there's the question of whether copy elision can even work with=20
> `dynarray`.
>

I think an implementation would help decide that.
=20

> But beyond that, how is this not a stack object? You can elide the copy=
=20
> from `arr` into the return value,
>

Note that when you elide this copy, the object that remains is the return=
=20
value, not the local variable, so it would be conceivable that it uses the=
=20
dynamic allocation and not the stack allocation.
=20

> but you can't elide the copy construction from the return value into the=
=20
> `new` expression.
>

move construction, no?

The point is that I want to be able to have some way of ensuring that no=20
> copying happens in this case. If that were a `vector<Type>`, I would know=
=20
> that there would be no copying.
>

Then use vector<Type>? If there was a perfect solution, we could modify=20
vector. Since there are compromises to make, we end up with vector and=20
dynarray that make some different choices.

Having a constructor dynarray(vector&&) might help with what you want to=20
achieve (modulo some allocator issues). But it looks like you would be=20
happy with simply duplicating some constructors (or giving them an extra=20
parameter) so the user can influence the compiler's choice? Seems easy=20
enough.

Note that I am not saying dynarray is a good or bad way to get=20
alloca/VLA-like memory, I didn't think long enough about it.

--=20

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



------=_Part_592_33463809.1365058427542
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mercredi 3 avril 2013 12:20:35 UTC+2, Nicol Bolas a =E9crit&nbsp;:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br>On Tuesday, April 2, 2013 11=
:53:07 PM UTC-7, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le merc=
redi 3 avril 2013 03:32:33 UTC+2, Nicol Bolas a =E9crit&nbsp;:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">The main issue is this:<br><br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color=
:#000">dynarray</span><span style=3D"color:#660">&lt;</span><span style=3D"=
color:#606">Type</span><span style=3D"color:#660">&gt;</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">GetArray</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">int</span><span style=3D=
"color:#000"> size</span><span style=3D"color:#660">)</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"co=
lor:#000"><br>&nbsp; dynarray</span><span style=3D"color:#660">&lt;</span><=
span style=3D"color:#606">Type</span><span style=3D"color:#660">&gt;</span>=
<span style=3D"color:#000"> arr</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#000">size</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#800">//Fill=
 in arr with stuff.</span><span style=3D"color:#000"><br>&nbsp; </span><spa=
n style=3D"color:#008">return</span><span style=3D"color:#000"> arr</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#660">}</span><span style=3D"color:#000"><br><br>unique_p=
tr</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">d=
ynarray</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#6=
06">Type</span><span style=3D"color:#660">&gt;&gt;</span><span style=3D"col=
or:#000"> arrPtr </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">new</span><span style=3D"co=
lor:#000"> dynarray</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#606">Type</span><span style=3D"color:#660">&gt;(</span><span sty=
le=3D"color:#606">GetArray</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#066">12</span><span style=3D"color:#660">));</span><span sty=
le=3D"color:#000"><br></span></div></code></div><br>So... what happens here=
? Assuming that elision works in this case, `dynarray`, we have a non-trivi=
al problem. The `dynarray` being heap-allocated is going to have to heap-al=
locate its own memory. But the `dynarray` being stack allocated, the return=
 value from `GetArray`, will stack-allocate its memory. Which means that it=
's contents will have to be <i>copied</i> into the heap-allocated `dynarray=
`.<br></blockquote><div><br>Could you clarify your example? As far as I und=
erstand, with copy elision, there is no stack dynarray here. arr is constru=
cted in the return value, which can't be on the stack.<br>(it would help to=
 have an implementation to play with)<br></div></blockquote><div><br>Well, =
there's the question of whether copy elision can even work with `dynarray`.=
</div></blockquote><div><br>I think an implementation would help decide tha=
t.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0p=
t 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=
><div> But beyond that, how is this not a stack object? You can elide the c=
opy from `arr` into the return value,</div></blockquote><div><br>Note that =
when you elide this copy, the object that remains is the return value, not =
the local variable, so it would be conceivable that it uses the dynamic all=
ocation and not the stack allocation.<br>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;"><div> but you can't elide the copy cons=
truction from the return value into the `new` expression.<br></div></blockq=
uote><div><br>move construction, no?<br><br><blockquote style=3D"margin: 0p=
t 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;" class=3D"gmail_quote"><code></code><code></code>The point is that I wa=
nt to be able to have some way of ensuring that no copying happens in this =
case. If that were a `vector&lt;Type&gt;`, I would know that there would be=
 no copying.<br></blockquote><br>Then use vector&lt;Type&gt;? If there was =
a perfect solution, we could modify vector. Since there are compromises to =
make, we end up with vector and dynarray that make some different choices.<=
br><br>Having a constructor dynarray(vector&amp;&amp;) might help with what=
 you want to achieve (modulo some allocator issues). But it looks like you =
would be happy with simply duplicating some constructors (or giving them an=
 extra parameter) so the user can influence the compiler's choice? Seems ea=
sy enough.<br><br>Note that I am not saying dynarray is a good or bad way t=
o get alloca/VLA-like memory, I didn't think long enough about it.<br></div=
>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_592_33463809.1365058427542--

.

On Thu, Apr 4, 2013 at 2:29 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>  Sounds like a unique_array<> or shared_array<> would be a better match
>> for your use case.
>
>
> Considering that those classes don't exist, and there are no proposals to
> add them, no they wouldn't. More importantly, there's no reason why we need
> such things if we're going to get a `dynarray` type that can be used
> anywhere.

T read_file(str_ref);

What should T be if read_file returns the memory mapped data of a file?
My vote would be for shared_data / shared_array<unsigned char>



--
Olaf

--

---
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/?hl=en.



.

On Thu, Apr 4, 2013 at 8:53 AM, Marc <marc.glisse@gmail.com> wrote:
>> But beyond that, how is this not a stack object? You can elide the copy
>> from `arr` into the return value,
>
>
> Note that when you elide this copy, the object that remains is the return
> value, not the local variable, so it would be conceivable that it uses the
> dynamic allocation and not the stack allocation.

The return value is passed as an argument to the constructor, it's not
put directly on the heap.



--
Olaf

--

---
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/?hl=en.



.

On Thu, Apr 4, 2013 at 10:53 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Apr 4, 2013 at 8:53 AM, Marc <marc.glisse@gmail.com> wrote:
>>> But beyond that, how is this not a stack object? You can elide the copy
>>> from `arr` into the return value,
>>
>>
>> Note that when you elide this copy, the object that remains is the return
>> value, not the local variable, so it would be conceivable that it uses the
>> dynamic allocation and not the stack allocation.
>
> The return value is passed as an argument to the constructor, it's not
> put directly on the heap.

The *address* of the return value is passed as an argument to the
function, and if you look at the assembly generated for, say

std::vector<int> foo();
void* bar() {
  return new std::vector<int>(foo());
}

you won't see a call to any vector copy or move constructors.

--

---
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/?hl=en.



.

On Thu, Apr 4, 2013 at 11:57 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Thu, Apr 4, 2013 at 10:53 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> On Thu, Apr 4, 2013 at 8:53 AM, Marc <marc.glisse@gmail.com> wrote:
>>>> But beyond that, how is this not a stack object? You can elide the copy
>>>> from `arr` into the return value,
>>>
>>>
>>> Note that when you elide this copy, the object that remains is the return
>>> value, not the local variable, so it would be conceivable that it uses the
>>> dynamic allocation and not the stack allocation.
>>
>> The return value is passed as an argument to the constructor, it's not
>> put directly on the heap.
>
> The *address* of the return value is passed as an argument to the
> function, and if you look at the assembly generated for, say
>
> std::vector<int> foo();
> void* bar() {
>   return new std::vector<int>(foo());
> }
>
> you won't see a call to any vector copy or move constructors.

So this first does the new (allocation) and then passes the address on
the heap to foo() (for return value optimization)?
If it doesn't, how does it construct the vector on the heap without
moving or copying?

--
Olaf

--

---
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/?hl=en.



.

On Thu, Apr 4, 2013 at 12:14 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Apr 4, 2013 at 11:57 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>> On Thu, Apr 4, 2013 at 10:53 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> On Thu, Apr 4, 2013 at 8:53 AM, Marc <marc.glisse@gmail.com> wrote:
>>>>> But beyond that, how is this not a stack object? You can elide the copy
>>>>> from `arr` into the return value,
>>>>
>>>>
>>>> Note that when you elide this copy, the object that remains is the return
>>>> value, not the local variable, so it would be conceivable that it uses the
>>>> dynamic allocation and not the stack allocation.
>>>
>>> The return value is passed as an argument to the constructor, it's not
>>> put directly on the heap.
>>
>> The *address* of the return value is passed as an argument to the
>> function, and if you look at the assembly generated for, say
>>
>> std::vector<int> foo();
>> void* bar() {
>>   return new std::vector<int>(foo());
>> }
>>
>> you won't see a call to any vector copy or move constructors.
>
> So this first does the new (allocation) and then passes the address on
> the heap to foo() (for return value optimization)?

Exactly. And it calls a matching operator delete if an exception's thrown.

> If it doesn't, how does it construct the vector on the heap without
> moving or copying?
>
> --
> Olaf
>
> --
>
> ---
> 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/?hl=en.
>
>

--

---
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/?hl=en.



.

------=_Part_418_20814510.1365093032918
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, April 4, 2013 11:14:52 AM UTC+1, Olaf van der Spek wrote:
>
> On Thu, Apr 4, 2013 at 11:57 AM, Jeffrey Yasskin <jyas...@google.com<javascript:>>
> wrote:
> > On Thu, Apr 4, 2013 at 10:53 AM, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> >> On Thu, Apr 4, 2013 at 8:53 AM, Marc <marc....@gmail.com <javascript:>>
> wrote:
> >>>> But beyond that, how is this not a stack object? You can elide the
> copy
> >>>> from `arr` into the return value,
> >>>
> >>>
> >>> Note that when you elide this copy, the object that remains is the
> return
> >>> value, not the local variable, so it would be conceivable that it uses
> the
> >>> dynamic allocation and not the stack allocation.
> >>
> >> The return value is passed as an argument to the constructor, it's not
> >> put directly on the heap.
> >
> > The *address* of the return value is passed as an argument to the
> > function, and if you look at the assembly generated for, say
> >
> > std::vector<int> foo();
> > void* bar() {
> >   return new std::vector<int>(foo());
> > }
> >
> > you won't see a call to any vector copy or move constructors.
>
> So this first does the new (allocation) and then passes the address on
> the heap to foo() (for return value optimization)?
> If it doesn't, how does it construct the vector on the heap without
> moving or copying?
>
> --
> Olaf
>

I don't believe that would be legal under the current elision rules.

--

---
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/?hl=en.



------=_Part_418_20814510.1365093032918
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, April 4, 2013 11:14:52 AM UTC+1, Olaf van der Spek wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Apr 4, 2013 at 11:5=
7 AM, Jeffrey Yasskin &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"SmOr-MpFUo0J">jyas...@google.com</a>&gt; wrote:
<br>&gt; On Thu, Apr 4, 2013 at 10:53 AM, Olaf van der Spek &lt;<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"SmOr-MpFUo0J">olafv=
....@gmail.com</a>&gt; wrote:
<br>&gt;&gt; On Thu, Apr 4, 2013 at 8:53 AM, Marc &lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"SmOr-MpFUo0J">marc....@gmail.=
com</a>&gt; wrote:
<br>&gt;&gt;&gt;&gt; But beyond that, how is this not a stack object? You c=
an elide the copy
<br>&gt;&gt;&gt;&gt; from `arr` into the return value,
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Note that when you elide this copy, the object that remain=
s is the return
<br>&gt;&gt;&gt; value, not the local variable, so it would be conceivable =
that it uses the
<br>&gt;&gt;&gt; dynamic allocation and not the stack allocation.
<br>&gt;&gt;
<br>&gt;&gt; The return value is passed as an argument to the constructor, =
it's not
<br>&gt;&gt; put directly on the heap.
<br>&gt;
<br>&gt; The *address* of the return value is passed as an argument to the
<br>&gt; function, and if you look at the assembly generated for, say
<br>&gt;
<br>&gt; std::vector&lt;int&gt; foo();
<br>&gt; void* bar() {
<br>&gt; &nbsp; return new std::vector&lt;int&gt;(foo());
<br>&gt; }
<br>&gt;
<br>&gt; you won't see a call to any vector copy or move constructors.
<br>
<br>So this first does the new (allocation) and then passes the address on
<br>the heap to foo() (for return value optimization)?
<br>If it doesn't, how does it construct the vector on the heap without
<br>moving or copying?
<br>
<br>--=20
<br>Olaf
<br></blockquote><div><br></div><div>I don't believe that would be legal un=
der the current elision rules.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_418_20814510.1365093032918--

.

On 4/3/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, April 2, 2013 11:53:07 PM UTC-7, Marc wrote:
> > Le mercredi 3 avril 2013 03:32:33 UTC+2, Nicol Bolas a =E9crit :
> > > The main issue is this:
> > >
> > > dynarray<Type> GetArray(int size)
> > > {
> > >   dynarray<Type> arr(size);
> > >   //Fill in arr with stuff.
> > >   return arr;
> > > }
> > >
> > > unique_ptr<dynarray<Type>> arrPtr =3D new dynarray<Type>(GetArray(12)=
);
> > >
> > > So... what happens here? Assuming that elision works in this
> > > case, `dynarray`, we have a non-trivial problem. The `dynarray`
> > > being heap-allocated is going to have to heap-allocate its own
> > > memory. But the `dynarray` being stack allocated, the return
> > > value from `GetArray`, will stack-allocate its memory. Which
> > > means that it's contents will have to be *copied* into the
> > > heap-allocated `dynarray`.
> >
> > Could you clarify your example? As far as I understand,
> > with copy elision, there is no stack dynarray here. arr is
> > constructed in the return value, which can't be on the stack.
> > (it would help to have an implementation to play with)
>
> Well, there's the question of whether copy elision can even
> work with `dynarray`. But beyond that, how is this not a stack
> object? You can elide the copy from `arr` into the return value,
> but you can't elide the copy construction from the return value
> into the `new` expression.
>
> And if the `new` construction is somehow elided, then feel free
> to turn it into this:
>
> dynarray<Type> arr =3D GetArray(12);
> unique_ptr<dynarray<Type>> arrPtr =3D new dynarray<Type>(std::move(arr));
>
> The point is that I want to be able to have some way of
> ensuring that no copying happens in this case. If that were a
> `vector<Type>`, I would know that there would be no copying.

The problem here is that you cannot just 'move the pointer' when
the contents are on the stack.  If you want the capability to move
the contents only when they are in the heap, you need to deal with
two effects.

First, you need to make the move operations detect when the
contents are on the stack.  This makes the implementation of the
move system-dependent, something the current proposal does not
require.  Indeed, the current proposal can be implemented with a
simple library and a small pattern-match on constructor calls in
the compiler.  Adding a move of a different flavor would complicate
the implementation considerably.

Second, in the stack case, the move operation would still need to do
an element by element copy or move.  That is, you are guaranteed to
at least have an O(n) iteration.  If the element operation throws,
then the dynarray move may potentially throw, which is not good.
We could conditionally implement the move operations, but then you
would never 'know' that there would be no copying in your example.
(Presuming your example is Type as template parameter.)

Is there any lasting harm in not providing move in the initial
release?

--=20
Lawrence Crowl

--=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/?hl=3Den.



.

On 4/5/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, April 4, 2013 7:10:36 PM UTC-7, Lawrence Crowl wrote:
> > Is there any lasting harm in not providing move in the initial
> > release?
>
> Yes. I need a fixed, runtime-sized array that has guaranteed
> reasonable move behavior (and moving each element is not
> "reasonable move behavior").  If `dynarray` cannot provide that,
> then we need an alternative that *can*.

For data structures like this, and for concurrent data structures,
we get into the situation where small changes in interface can have
significant effects on implementation performance.  I'm wondering how
we are going to manage the consequential complexity.  Ideas welcome.

> And more to the point, if `dynarray` can't provide that... why
> would you * ever* use `dynarray` for anything other than a
> stack-based array that you will never move? At which point, we
> can then have errors for when you try to make it a global or a
> class member or allocate it on the heap.

Move semantics only helps when your abstraction is implemented as
a handle and separately allocated data chunk.  If the dynarray is
in the data chunk, it need never be moved directly.  As for why
you would use it for anything else, well sometimes you want type
compatibility.

> So if what you're saying is true, then we need two classes:
> one for stack-based fixed-sized arrays, and one for heap-based
> fixed-sized arrays.

Sounds reasonable.

--
Lawrence Crowl

--

---
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/?hl=en.



.

------=_Part_373_9316946.1366471299010
Content-Type: text/plain; charset=ISO-8859-1

Why don't we introduce simple dynamic arrays in objects, which can be
allocated in the same place as the objects (stack or heap) they belong to?
For example, like this:
class A
{
   double x[];
public:
    A(std::size_t n):x(n) {}
   ...
};

--

---
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/?hl=en.



------=_Part_373_9316946.1366471299010
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Why don't we introduce simple dynamic arrays in objects, which can be =
allocated in the same place as the objects (stack or heap) they belong to?<=
/div><div>For example, like this:</div><div>class A<br>{<br>&nbsp;&nbsp; do=
uble x[];<br>public:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; A=
(std::size_t n):x(n) {}<br>&nbsp;&nbsp; ...&nbsp;&nbsp; <br>};<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_373_9316946.1366471299010--

.

On Apr 20, 2013, at 4:21 PM, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> Why don't we introduce simple dynamic arrays in objects, which can be allocated in the same place as the objects (stack or heap) they belong to?
> For example, like this:
> class A
> {
>    double x[];
> public:
>     A(std::size_t n):x(n) {}
>    ...
> };

What is sizeof(A) ?

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

--

---
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/?hl=en.



.

------=_Part_622_25509157.1366472979317
Content-Type: text/plain; charset=ISO-8859-1

To be honest, I don't care what sizeof(a) will be for a dynamically
allocated array. But if you want a formal definition, then the same
as in
void f(double a[]);

which will be the size of the pointer (in most cases 4 or 8 depending on
the system).

-- Mikhail.


On Saturday, April 20, 2013 4:23:49 PM UTC+1, Marshall wrote:

> On Apr 20, 2013, at 4:21 PM, Mikhail Semenov <mikhailse...@gmail.com<javascript:>>
> wrote:
>
> > Why don't we introduce simple dynamic arrays in objects, which can be
> allocated in the same place as the objects (stack or heap) they belong to?
> > For example, like this:
> > class A
> > {
> >    double x[];
> > public:
> >     A(std::size_t n):x(n) {}
> >    ...
> > };
>
> What is sizeof(A) ?
>
> -- Marshall
>
> Marshall Clow     Idio Software   <mailto:mclow...@gmail.com <javascript:>>
>
>
> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is
> promptly moderated down to (-1, Flamebait).
>         -- Yu Suzuki
>
>

--

---
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/?hl=en.



------=_Part_622_25509157.1366472979317
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>To be honest, I don't care what sizeof(a) will be for a dynamically al=
located array. But if you want a formal definition, then the same</div><div=
>as in</div><div>void f(double a[]);</div><div>&nbsp;</div><div>which will =
be the size of the pointer (in most cases 4 or 8 depending on the system).<=
/div><div>&nbsp;</div><div>-- Mikhail.</div><div>&nbsp;</div><div><br>On Sa=
turday, April 20, 2013 4:23:49 PM UTC+1, Marshall wrote:</div><blockquote c=
lass=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 Apr 20, 2013, at 4:21 PM, Mikhail Semenov &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-WXTksgGztAJ">mikh=
ailse...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Why don't we introduce simple dynamic arrays in objects, which can=
 be allocated in the same place as the objects (stack or heap) they belong =
to?
<br>&gt; For example, like this:
<br>&gt; class A
<br>&gt; {
<br>&gt; &nbsp; &nbsp;double x[];
<br>&gt; public: &nbsp; &nbsp; &nbsp;
<br>&gt; &nbsp; &nbsp; A(std::size_t n):x(n) {}
<br>&gt; &nbsp; &nbsp;... &nbsp;=20
<br>&gt; };
<br>
<br>What is sizeof(A) ?
<br>
<br>-- Marshall
<br>
<br>Marshall Clow &nbsp; &nbsp; Idio Software &nbsp; &lt;mailto:<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-WXTksgGztAJ">mclow=
....@gmail.com</a>&gt;
<br>
<br>A.D. 1517: Martin Luther nails his 95 Theses to the church door and is =
promptly moderated down to (-1, Flamebait).
<br>&nbsp; &nbsp; &nbsp; &nbsp; -- Yu Suzuki
<br>
<br></blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_622_25509157.1366472979317--

.

--Apple-Mail=_C335F4B3-5C5B-4781-BB92-90A043C90341
Content-Type: text/plain; charset=ISO-8859-1

On Apr 20, 2013, at 8:49 AM, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:
> On Saturday, April 20, 2013 4:23:49 PM UTC+1, Marshall wrote:
> On Apr 20, 2013, at 4:21 PM, Mikhail Semenov <mikhailse...@gmail.com> wrote:
>
> > Why don't we introduce simple dynamic arrays in objects, which can be allocated in the same place as the objects (stack or heap) they belong to?
> > For example, like this:
> > class A
> > {
> >    double x[];
> > public:
> >     A(std::size_t n):x(n) {}
> >    ...
> > };
>
> What is sizeof(A) ?
>
> To be honest, I don't care what sizeof(a) will be for a dynamically allocated array. But if you want a formal definition, then the same
> as in
> void f(double a[]);
>
> which will be the size of the pointer (in most cases 4 or 8 depending on the system).


Let me try again.

If I write:
 A foo[10];

How big is foo?   How would the compiler allocate space on the stack/globals/wherever for foo?
How many elements are there in foo[3] ? Is that what you want? How would you change that?

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

--

---
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/?hl=en.



--Apple-Mail=_C335F4B3-5C5B-4781-BB92-90A043C90341
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><div><div>On Apr 20, 20=
13, at 8:49 AM, Mikhail Semenov &lt;<a href=3D"mailto:mikhailsemenov1957@gm=
ail.com">mikhailsemenov1957@gmail.com</a>&gt; wrote:</div><blockquote type=
=3D"cite"><div>On Saturday, April 20, 2013 4:23:49 PM UTC+1, Marshall wrote=
:</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-wid=
th: 1px; border-left-style: solid; position: static; z-index: auto; ">On Ap=
r 20, 2013, at 4:21 PM, Mikhail Semenov &lt;<a href=3D"" target=3D"_blank" =
gdf-obfuscated-mailto=3D"-WXTksgGztAJ">mikhailse...@gmail.com</a>&gt; wrote=
:&nbsp;<br><br>&gt; Why don't we introduce simple dynamic arrays in objects=
, which can be allocated in the same place as the objects (stack or heap) t=
hey belong to?&nbsp;<br>&gt; For example, like this:&nbsp;<br>&gt; class A&=
nbsp;<br>&gt; {&nbsp;<br>&gt; &nbsp; &nbsp;double x[];&nbsp;<br>&gt; public=
: &nbsp; &nbsp; &nbsp;&nbsp;<br>&gt; &nbsp; &nbsp; A(std::size_t n):x(n) {}=
&nbsp;<br>&gt; &nbsp; &nbsp;... &nbsp;&nbsp;<br>&gt; };&nbsp;<br><br>What i=
s sizeof(A) ?&nbsp;<br></blockquote></blockquote><blockquote type=3D"cite">=
<br></blockquote><blockquote type=3D"cite"><div>To be honest, I don't care =
what sizeof(a) will be for a dynamically allocated array. But if you want a=
 formal definition, then the same</div><div>as in</div><div>void f(double a=
[]);</div><div>&nbsp;</div><div>which will be the size of the pointer (in m=
ost cases 4 or 8 depending on the system).</div></blockquote></div><div><di=
v><br></div></div><div>Let me try again.</div><div><br></div><div>If I writ=
e:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>A foo[10];</div><div><br></div><div>How big is foo?<span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>&nbsp; How would the compiler a=
llocate space on the stack/globals/wherever for foo?</div><div>How many ele=
ments are there in foo[3] ? Is that what you want? How would you change tha=
t?</div><div><br></div><div>-- Marshall</div><div apple-content-edited=3D"t=
rue"><span class=3D"Apple-style-span" style=3D"border-collapse: separate; b=
order-spacing: 0px; "><br>Marshall Clow &nbsp; &nbsp; Idio Software &nbsp; =
&lt;<a href=3D"mailto:mclow.lists@gmail.com">mailto:mclow.lists@gmail.com</=
a>&gt;<br><br>A.D. 1517: Martin Luther nails his 95 Theses to the church do=
or and is promptly moderated down to (-1, Flamebait).<br>&nbsp;&nbsp; &nbsp=
; &nbsp; &nbsp;-- Yu Suzuki</span>

</div>
<br></body></html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--Apple-Mail=_C335F4B3-5C5B-4781-BB92-90A043C90341--

.

------=_Part_4071_29371438.1366826078863
Content-Type: text/plain; charset=ISO-8859-1

By default, in this case the default constructor would be undefined. The
used has to provide it if they want:

 class A
{
    double x[];
public:
     A():x(50) {}
     A(std::size_t n):x(n) {}
    ...
};



On Wednesday, April 24, 2013 5:51:52 AM UTC+1, Marshall wrote:

> On Apr 20, 2013, at 8:49 AM, Mikhail Semenov <mikhailse...@gmail.com<javascript:>>
> wrote:
>
> On Saturday, April 20, 2013 4:23:49 PM UTC+1, Marshall wrote:
>
>> On Apr 20, 2013, at 4:21 PM, Mikhail Semenov <mikhailse...@gmail.com>
>> wrote:
>>
>> > Why don't we introduce simple dynamic arrays in objects, which can be
>> allocated in the same place as the objects (stack or heap) they belong to?
>> > For example, like this:
>> > class A
>> > {
>> >    double x[];
>> > public:
>> >     A(std::size_t n):x(n) {}
>> >    ...
>> > };
>>
>> What is sizeof(A) ?
>>
>
> To be honest, I don't care what sizeof(a) will be for a dynamically
> allocated array. But if you want a formal definition, then the same
> as in
> void f(double a[]);
>
> which will be the size of the pointer (in most cases 4 or 8 depending on
> the system).
>
>
> Let me try again.
>
> If I write:
> A foo[10];
>
> How big is foo?   How would the compiler allocate space on the
> stack/globals/wherever for foo?
> How many elements are there in foo[3] ? Is that what you want? How would
> you change that?
>
> -- Marshall
>
> Marshall Clow     Idio Software   <mailto:mc...@gmail.com <javascript:>>
>
> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is
> promptly moderated down to (-1, Flamebait).
>         -- Yu Suzuki
>
>

--

---
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/?hl=en.



------=_Part_4071_29371438.1366826078863
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>By default, in this case the default constructor would be undefined. T=
he used has to provide it if they want:</div><div>&nbsp;</div><div>&nbsp;cl=
ass A&nbsp;<br>{&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp;double x[];&nbsp;<br> pub=
lic:</div><div>&nbsp;&nbsp;&nbsp;&nbsp; A():x(50) {}&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp; A(std::size_t n):x(n) {}&nb=
sp;<br>&nbsp;&nbsp;&nbsp;&nbsp;...&nbsp;&nbsp;&nbsp;<br> };&nbsp;<br></div>=
<div><br>&nbsp;</div><div>&nbsp;</div><div>On Wednesday, April 24, 2013 5:5=
1:52 AM UTC+1, Marshall wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div style=
=3D"word-wrap: break-word;"><div><div>On Apr 20, 2013, at 8:49 AM, Mikhail =
Semenov &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"pyX95k7EAkcJ">mikhailse...@gmail.com</a>&gt; wrote:</div><blockquote ty=
pe=3D"cite"><div>On Saturday, April 20, 2013 4:23:49 PM UTC+1, Marshall wro=
te:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;">On Apr 20, 2013, at 4:21 PM, Mikhail =
Semenov &lt;<a>mikhailse...@gmail.com</a>&gt; wrote:&nbsp;<br><br>&gt; Why =
don't we introduce simple dynamic arrays in objects, which can be allocated=
 in the same place as the objects (stack or heap) they belong to?&nbsp;<br>=
&gt; For example, like this:&nbsp;<br>&gt; class A&nbsp;<br>&gt; {&nbsp;<br=
>&gt; &nbsp; &nbsp;double x[];&nbsp;<br>&gt; public: &nbsp; &nbsp; &nbsp;&n=
bsp;<br>&gt; &nbsp; &nbsp; A(std::size_t n):x(n) {}&nbsp;<br>&gt; &nbsp; &n=
bsp;... &nbsp;&nbsp;<br>&gt; };&nbsp;<br><br>What is sizeof(A) ?&nbsp;<br><=
/blockquote></blockquote><blockquote type=3D"cite"><br></blockquote><blockq=
uote type=3D"cite"><div>To be honest, I don't care what sizeof(a) will be f=
or a dynamically allocated array. But if you want a formal definition, then=
 the same</div><div>as in</div><div>void f(double a[]);</div><div>&nbsp;</d=
iv><div>which will be the size of the pointer (in most cases 4 or 8 dependi=
ng on the system).</div></blockquote></div><div><div><br></div></div><div>L=
et me try again.</div><div><br></div><div>If I write:</div><div><span style=
=3D"white-space: pre;"> </span>A foo[10];</div><div><br></div><div>How big =
is foo?<span style=3D"white-space: pre;"> </span>&nbsp; How would the compi=
ler allocate space on the stack/globals/wherever for foo?</div><div>How man=
y elements are there in foo[3] ? Is that what you want? How would you chang=
e that?</div><div><br></div><div>-- Marshall</div><div><span style=3D"borde=
r-collapse: separate; border-spacing: 0px;"><br>Marshall Clow &nbsp; &nbsp;=
 Idio Software &nbsp; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"pyX95k7EAkcJ">mailto:mc...@gmail.com</a>&gt;<br><br>A.D. =
1517: Martin Luther nails his 95 Theses to the church door and is promptly =
moderated down to (-1, Flamebait).<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;-- Y=
u Suzuki</span>

</div>
<br></div></blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4071_29371438.1366826078863--

.

------=_Part_351_26465895.1366880966900
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, April 24, 2013 6:54:38 PM UTC+1, Mikhail Semenov wrote:
>
> By default, in this case the default constructor would be undefined. The
> used has to provide it if they want:
>
>  class A
> {
>     double x[];
> public:
>      A():x(50) {}
>      A(std::size_t n):x(n) {}
>     ...
> };
>
>
>
That doesn't answer the question, you're missing the point.  In C++
sizeof(A) must be a compile-time constant, so it cannot depend on
constructor parameters.

Array access depends on all objects of the same type having the same
fixed-size, for pointer arithmetic to work.

--

---
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/?hl=en.



------=_Part_351_26465895.1366880966900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, April 24, 2013 6:54:38 PM UTC+1, Mikhail Semenov wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div>By default, in this cas=
e the default constructor would be undefined. The used has to provide it if=
 they want:</div><div>&nbsp;</div><div>&nbsp;class A&nbsp;<br>{&nbsp;<br>&n=
bsp;&nbsp;&nbsp;&nbsp;double x[];&nbsp;<br> public:</div><div>&nbsp;&nbsp;&=
nbsp;&nbsp; A():x(50) {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>&nbsp=
;&nbsp;&nbsp;&nbsp; A(std::size_t n):x(n) {}&nbsp;<br>&nbsp;&nbsp;&nbsp;&nb=
sp;...&nbsp;&nbsp;&nbsp;<br> };&nbsp;<br></div><div><br><br></div></blockqu=
ote><div><br>That doesn't answer the question, you're missing the point.&nb=
sp; In C++ sizeof(A) must be a compile-time constant, so it cannot depend o=
n constructor parameters.<br><br>Array access depends on all objects of the=
 same type having the same fixed-size, for pointer arithmetic to work.<br><=
/div><br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_351_26465895.1366880966900--

.

--089e01294802fd3fe704db2c9d6f
Content-Type: text/plain; charset=ISO-8859-1

Jonathan,

I repeat my point: the value is the same as in
void f(double x[]);
which is the size of the pointer.

x[] works a bit similar to a constant reference to memory space which is
allocated on the stack during construction.
It's not really part of the class. If yoy ask about sizeof(A): it will be
always the same. The allocated array is not part of it.
There should be a difference between x[] and x[100]: the first is a
refrence to memory; the second is an array itself. But both
can be converted to pointers.

Regards,
Mikhail.



On 25 April 2013 10:09, Jonathan Wakely <cxx@kayari.org> wrote:

>
>
> On Wednesday, April 24, 2013 6:54:38 PM UTC+1, Mikhail Semenov wrote:
>>
>> By default, in this case the default constructor would be undefined. The
>> used has to provide it if they want:
>>
>>  class A
>> {
>>     double x[];
>> public:
>>      A():x(50) {}
>>      A(std::size_t n):x(n) {}
>>     ...
>> };
>>
>>
>>
> That doesn't answer the question, you're missing the point.  In C++
> sizeof(A) must be a compile-time constant, so it cannot depend on
> constructor parameters.
>
> Array access depends on all objects of the same type having the same
> fixed-size, for pointer arithmetic to work.
>
> --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--089e01294802fd3fe704db2c9d6f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Jonathan,</div>
<div>=A0</div>
<div>I repeat my point: the value is the same as in </div>
<div>void f(double x[]);</div>
<div>which is the size of the pointer.</div>
<div>=A0</div>
<div>x[] works a bit similar to a constant reference to memory space which =
is allocated on the stack during construction.</div>
<div>It&#39;s not really part of the class. If yoy ask about sizeof(A): it =
will be always the same. The allocated array is not part of it.</div>
<div>There should be a difference between x[] and x[100]: the first is a re=
frence to memory; the second is an array itself. But both</div>
<div>can be converted to pointers. </div>
<div>=A0</div>
<div>Regards,</div>
<div>Mikhail.</div>
<div><br><br>=A0</div>
<div class=3D"gmail_quote">On 25 April 2013 10:09, Jonathan Wakely <span di=
r=3D"ltr">&lt;<a href=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayar=
i.org</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div class=3D"im"><br><br>On Wednesday, April 24, 2013 6:54:38 PM UTC+1, Mi=
khail Semenov wrote:=20
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div>By default, in this case the default constructor would be undefined. T=
he used has to provide it if they want:</div>
<div>=A0</div>
<div>=A0class A=A0<br>{=A0<br>=A0=A0=A0=A0double x[];=A0<br>public:</div>
<div>=A0=A0=A0=A0 A():x(50) {}=A0=A0=A0=A0=A0=A0=A0<br>=A0=A0=A0=A0 A(std::=
size_t n):x(n) {}=A0<br>=A0=A0=A0=A0...=A0=A0=A0<br>};=A0<br></div>
<div><br><br></div></blockquote></div>
<div><br>That doesn&#39;t answer the question, you&#39;re missing the point=
..=A0 In C++ sizeof(A) must be a compile-time constant, so it cannot depend =
on constructor parameters.<br><br>Array access depends on all objects of th=
e same type having the same fixed-size, for pointer arithmetic to work.<br>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5"><br>
<p></p>-- <br>=A0<br>--- <br>You received this message because you are subs=
cribed 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=3D"mailto:std-proposals%2Bunsubscribe@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 a=
t <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=
=3Den" target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-pr=
oposals/?hl=3Den</a>.<br>
=A0<br>=A0<br></div></div></blockquote></div><br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e01294802fd3fe704db2c9d6f--

.

------=_Part_17_17193452.1366969289274
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, April 25, 2013 12:09:42 PM UTC+2, Mikhail Semenov wrote:
>
> Jonathan,
>
> I repeat my point: the value is the same as in
> void f(double x[]);
> which is the size of the pointer.
>

But here, x *is* a pointer. But if you have a class A containing a VLA, and
you write

A a(arguments, to, determine, stack, size);

should a be a pointer? Or just that sizeof should report it as one?

--

---
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/?hl=en.



------=_Part_17_17193452.1366969289274
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, April 25, 2013 12:09:42 PM UTC+2, Mikhail Semenov wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div>Jonathan,</div>
<div>&nbsp;</div>
<div>I repeat my point: the value is the same as in </div>
<div>void f(double x[]);</div>
<div>which is the size of the pointer.</div></blockquote><div><br></div><di=
v>But here, x *is* a pointer. But if you have a class A containing a VLA, a=
nd you write</div><div><br></div><div>A a(arguments, to, determine, stack, =
size);</div><div><br></div><div>should a be a pointer? Or just that sizeof =
should report it as one?&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_17_17193452.1366969289274--

.

--089e013a010a9eace104db49c918
Content-Type: text/plain; charset=ISO-8859-1

To clarify, I think I have to explain it formally. The following definition
*class A
{ *
*public:
    double x[]; *
*     A():x(50) {}
     A(std::size_t n):x(n) {}
    ...
};*

is functionally equivalent to
*class A
{
public:
    double *const x;
    A():x(new double[50]) {}
    A(unsigned n):x(new double[n]) {}
    ~A() { delete [] x;}
 };*

The only difference is that double x[] can be allocated on the stack of the
object of class A is allocated on the stack.




On 26 April 2013 10:41, <cornedbee@google.com> wrote:

>
>
> On Thursday, April 25, 2013 12:09:42 PM UTC+2, Mikhail Semenov wrote:
>>
>> Jonathan,
>>
>> I repeat my point: the value is the same as in
>> void f(double x[]);
>> which is the size of the pointer.
>>
>
> But here, x *is* a pointer. But if you have a class A containing a VLA,
> and you write
>
> A a(arguments, to, determine, stack, size);
>
> should a be a pointer? Or just that sizeof should report it as one?
>
> --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--089e013a010a9eace104db49c918
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>To clarify, I think I have to explain it formally. Th=
e following definition</div><div><strong>class A=A0<br>{=A0</strong></div><=
div><strong>public:<br>=A0=A0=A0=A0double x[];=A0</strong></div><div><stron=
g>=A0=A0=A0=A0 A():x(50) {}=A0=A0=A0=A0=A0=A0=A0<br>
=A0=A0=A0=A0 A(std::size_t n):x(n) {}=A0<br>=A0=A0=A0=A0...=A0=A0=A0<br> };=
</strong>=A0</div><div>=A0</div><div>is=A0functionally equivalent to</div><=
div><strong>class A<br>{<br>public:<br>=A0=A0=A0 double *const x;<br>=A0=A0=
=A0 A():x(new double[50]) {}<br>=A0=A0=A0 A(unsigned n):x(new double[n]) {}=
<br>
=A0=A0=A0 ~A() { delete [] x;}<br>=A0};</strong></div><div>=A0</div><div>Th=
e only difference is that double x[] can be allocated on the stack of the o=
bject of class A is allocated on the stack.</div><div>=A0</div><div>=A0</di=
v></div><div class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On 26 April 2013 10:41,  <span dir=3D"lt=
r">&lt;<a href=3D"mailto:cornedbee@google.com" target=3D"_blank">cornedbee@=
google.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 class=3D"im"><br><br>On Thursday, April 25, 2013 12:09:42 PM UTC+2, Mi=
khail Semenov 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);border-lef=
t-width:1px;border-left-style:solid">
<div>Jonathan,</div>
<div>=A0</div>
<div>I repeat my point: the value is the same as in </div>
<div>void f(double x[]);</div>
<div>which is the size of the pointer.</div></blockquote><div><br></div></d=
iv><div>But here, x *is* a pointer. But if you have a class A containing a =
VLA, and you write</div><div><br></div><div>A a(arguments, to, determine, s=
tack, size);</div>
<div><br></div><div>should a be a pointer? Or just that sizeof should repor=
t it as one?=A0</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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" 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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e013a010a9eace104db49c918--

.

On 4/26/13, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:
> To clarify, I think I have to explain it formally. The following
> definition
>
> class A
> {
> public:
>     double x[];
>     A():x(50) {}
>     A(std::size_t n):x(n) {}
>     ...
> };

The declaration of x is illegal.  Quoting from N3497, "An array of
runtime bound shall only be used as the type of a local object with
automatic storage duration."

You can use dynarray instead.

class A
{
public:
    std::dynarray<double> x;
    A():x(50) {}
    A(std::size_t n):x(n) {}
    ...
};

> is functionally equivalent to
>
> class A
> {
> public:
>     double * const x;
>     A():x(new double[50]) {}
>     A(unsigned n):x(new double[n]) {}
>     ~A() { delete [] x;}
> };

With dynarray, it would be something more like

class A
{
public:
    std::pair<double *, size_t> x;
    A():x(new double[50], 50) {}
    A(unsigned n):x(new double[n], n) {}
    ~A() { delete [] x.first;}
};

> The only difference is that double x[] can be allocated on the
> stack of the object of class A is allocated on the stack.

That much is true of dynarray, though pragmatically, the constructor
of A will likely need to be inlined.

--
Lawrence Crowl

--

---
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/?hl=en.



.

--089e01294802a9a32804db5347aa
Content-Type: text/plain; charset=ISO-8859-1

Hello Lawrence,

Thank you for this. I was just trying to suggest a simpler syntax for
"dynamic arrays".
I am aware that x[] is illegal in classes.

Regards,
Mikhail.





On 27 April 2013 02:07, Lawrence Crowl <crowl@googlers.com> wrote:

> On 4/26/13, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:
> > To clarify, I think I have to explain it formally. The following
> > definition
> >
> > class A
> > {
> > public:
> >     double x[];
> >     A():x(50) {}
> >     A(std::size_t n):x(n) {}
> >     ...
> > };
>
> The declaration of x is illegal.  Quoting from N3497, "An array of
> runtime bound shall only be used as the type of a local object with
> automatic storage duration."
>
> You can use dynarray instead.
>
> class A
> {
> public:
>     std::dynarray<double> x;
>     A():x(50) {}
>     A(std::size_t n):x(n) {}
>     ...
> };
>
> > is functionally equivalent to
> >
> > class A
> > {
> > public:
> >     double * const x;
> >     A():x(new double[50]) {}
> >     A(unsigned n):x(new double[n]) {}
> >     ~A() { delete [] x;}
> > };
>
> With dynarray, it would be something more like
>
> class A
> {
> public:
>     std::pair<double *, size_t> x;
>     A():x(new double[50], 50) {}
>     A(unsigned n):x(new double[n], n) {}
>     ~A() { delete [] x.first;}
> };
>
> > The only difference is that double x[] can be allocated on the
> > stack of the object of class A is allocated on the stack.
>
> That much is true of dynarray, though pragmatically, the constructor
> of A will likely need to be inlined.
>
> --
> Lawrence Crowl
>
> --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--089e01294802a9a32804db5347aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hello Lawrence,</div>
<div>=A0</div>
<div>Thank you for this. I was just trying to suggest a simpler syntax for =
&quot;dynamic arrays&quot;.</div>
<div>I am aware that x[] is illegal in classes.</div>
<div>=A0</div>
<div>Regards,</div>
<div>Mikhail.</div>
<div>=A0</div>
<div>=A0</div>
<div><br><br>=A0</div>
<div class=3D"gmail_quote">On 27 April 2013 02:07, Lawrence Crowl <span dir=
=3D"ltr">&lt;<a href=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@=
googlers.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div class=3D"im">On 4/26/13, Mikhail Semenov &lt;<a href=3D"mailto:mikhail=
semenov1957@gmail.com">mikhailsemenov1957@gmail.com</a>&gt; wrote:<br>&gt; =
To clarify, I think I have to explain it formally. The following<br>&gt; de=
finition<br>
&gt;<br>&gt; class A<br>&gt; {<br>&gt; public:<br>&gt; =A0 =A0 double x[];<=
br>&gt; =A0 =A0 A():x(50) {}<br>&gt; =A0 =A0 A(std::size_t n):x(n) {}<br>&g=
t; =A0 =A0 ...<br>&gt; };<br><br></div>The declaration of x is illegal. =A0=
Quoting from N3497, &quot;An array of<br>
runtime bound shall only be used as the type of a local object with<br>auto=
matic storage duration.&quot;<br><br>You can use dynarray instead.<br><br>c=
lass A<br>{<br>public:<br>=A0 =A0 std::dynarray&lt;double&gt; x;<br>
<div class=3D"im">=A0 =A0 A():x(50) {}<br>=A0 =A0 A(std::size_t n):x(n) {}<=
br>=A0 =A0 ...<br>};<br><br>&gt; is functionally equivalent to<br>&gt;<br>&=
gt; class A<br>&gt; {<br>&gt; public:<br></div>&gt; =A0 =A0 double * const =
x;<br>
<div class=3D"im">&gt; =A0 =A0 A():x(new double[50]) {}<br>&gt; =A0 =A0 A(u=
nsigned n):x(new double[n]) {}<br>&gt; =A0 =A0 ~A() { delete [] x;}<br>&gt;=
 };<br><br></div>With dynarray, it would be something more like<br><br>clas=
s A<br>{<br>
public:<br>=A0 =A0 std::pair&lt;double *, size_t&gt; x;<br>=A0 =A0 A():x(ne=
w double[50], 50) {}<br>=A0 =A0 A(unsigned n):x(new double[n], n) {}<br>=A0=
 =A0 ~A() { delete [] x.first;}<br>
<div class=3D"im">};<br><br>&gt; The only difference is that double x[] can=
 be allocated on the<br>&gt; stack of the object of class A is allocated on=
 the stack.<br><br></div>That much is true of dynarray, though pragmaticall=
y, the constructor<br>
of A will likely need to be inlined.<br><span class=3D"HOEnZb"><font color=
=3D"#888888"><br>--<br>Lawrence Crowl<br></font></span>
<div class=3D"HOEnZb">
<div class=3D"h5"><br>--<br><br>---<br>You received this message because yo=
u are subscribed to the Google Groups &quot;ISO C++ Standard - Future Propo=
sals&quot; group.<br>To unsubscribe from this group and stop receiving emai=
ls from it, send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@=
isocpp.org">std-proposals+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/?hl=3Den" target=3D"_b=
lank">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den</a=
>.<br>
<br><br></div></div></blockquote></div><br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e01294802a9a32804db5347aa--

.

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

Your "simpler syntax":
1) is more confusing than dynarray - x is a pointer, not an array!
2) is not searchable in most web search engines (while dynarray is)
3) does not carry information about size (while dynarray does)

Cheers,
Micha=C5=82 Dominiak

On Saturday, 27 April 2013 10:17:17 UTC+2, Mikhail Semenov wrote:
>
> Hello Lawrence,
> =20
> Thank you for this. I was just trying to suggest a simpler syntax for=20
> "dynamic arrays".
> I am aware that x[] is illegal in classes.
> =20
> Regards,
> Mikhail.
> =20
> =20
>
>
> =20
> On 27 April 2013 02:07, Lawrence Crowl <cr...@googlers.com <javascript:>>=
wrote:
>
>> On 4/26/13, Mikhail Semenov <mikhailse...@gmail.com <javascript:>> wrote=
:
>> > To clarify, I think I have to explain it formally. The following
>> > definition
>> >
>> > class A
>> > {
>> > public:
>> >     double x[];
>> >     A():x(50) {}
>> >     A(std::size_t n):x(n) {}
>> >     ...
>> > };
>>
>> The declaration of x is illegal.  Quoting from N3497, "An array of
>> runtime bound shall only be used as the type of a local object with
>> automatic storage duration."
>>
>> You can use dynarray instead.
>>
>> class A
>> {
>> public:
>>     std::dynarray<double> x;
>>     A():x(50) {}
>>     A(std::size_t n):x(n) {}
>>     ...
>> };
>>
>> > is functionally equivalent to
>> >
>> > class A
>> > {
>> > public:
>> >     double * const x;
>> >     A():x(new double[50]) {}
>> >     A(unsigned n):x(new double[n]) {}
>> >     ~A() { delete [] x;}
>> > };
>>
>> With dynarray, it would be something more like
>>
>> class A
>> {
>> public:
>>     std::pair<double *, size_t> x;
>>     A():x(new double[50], 50) {}
>>     A(unsigned n):x(new double[n], n) {}
>>     ~A() { delete [] x.first;}
>> };
>>
>> > The only difference is that double x[] can be allocated on the
>> > stack of the object of class A is allocated on the stack.
>>
>> That much is true of dynarray, though pragmatically, the constructor
>> of A will likely need to be inlined.
>>
>> --
>> Lawrence Crowl
>> =20
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>>
>>
>>
>

--=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/?hl=3Den.



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

Your "simpler syntax":<div>1) is more confusing than dynarray - x is a poin=
ter, not an array!</div><div>2) is not searchable in most web search engine=
s (while dynarray is)</div><div>3) does not carry information about size (w=
hile dynarray does)</div><div><br></div><div>Cheers,</div><div>Micha=C5=82 =
Dominiak</div><div><br>On Saturday, 27 April 2013 10:17:17 UTC+2, Mikhail S=
emenov  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Hello Lawre=
nce,</div>
<div>&nbsp;</div>
<div>Thank you for this. I was just trying to suggest a simpler syntax for =
"dynamic arrays".</div>
<div>I am aware that x[] is illegal in classes.</div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>Mikhail.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><br><br>&nbsp;</div>
<div class=3D"gmail_quote">On 27 April 2013 02:07, Lawrence Crowl <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"o7wYJHpCnrkJ">cr...@googlers.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div>On 4/26/13, Mikhail Semenov &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"o7wYJHpCnrkJ">mikhailse...@gmail.com</a>&gt; w=
rote:<br>&gt; To clarify, I think I have to explain it formally. The follow=
ing<br>&gt; definition<br>
&gt;<br>&gt; class A<br>&gt; {<br>&gt; public:<br>&gt; &nbsp; &nbsp; double=
 x[];<br>&gt; &nbsp; &nbsp; A():x(50) {}<br>&gt; &nbsp; &nbsp; A(std::size_=
t n):x(n) {}<br>&gt; &nbsp; &nbsp; ...<br>&gt; };<br><br></div>The declarat=
ion of x is illegal. &nbsp;Quoting from N3497, "An array of<br>
runtime bound shall only be used as the type of a local object with<br>auto=
matic storage duration."<br><br>You can use dynarray instead.<br><br>class =
A<br>{<br>public:<br>&nbsp; &nbsp; std::dynarray&lt;double&gt; x;<br>
<div>&nbsp; &nbsp; A():x(50) {}<br>&nbsp; &nbsp; A(std::size_t n):x(n) {}<b=
r>&nbsp; &nbsp; ...<br>};<br><br>&gt; is functionally equivalent to<br>&gt;=
<br>&gt; class A<br>&gt; {<br>&gt; public:<br></div>&gt; &nbsp; &nbsp; doub=
le * const x;<br>
<div>&gt; &nbsp; &nbsp; A():x(new double[50]) {}<br>&gt; &nbsp; &nbsp; A(un=
signed n):x(new double[n]) {}<br>&gt; &nbsp; &nbsp; ~A() { delete [] x;}<br=
>&gt; };<br><br></div>With dynarray, it would be something more like<br><br=
>class A<br>{<br>
public:<br>&nbsp; &nbsp; std::pair&lt;double *, size_t&gt; x;<br>&nbsp; &nb=
sp; A():x(new double[50], 50) {}<br>&nbsp; &nbsp; A(unsigned n):x(new doubl=
e[n], n) {}<br>&nbsp; &nbsp; ~A() { delete [] x.first;}<br>
<div>};<br><br>&gt; The only difference is that double x[] can be allocated=
 on the<br>&gt; stack of the object of class A is allocated on the stack.<b=
r><br></div>That much is true of dynarray, though pragmatically, the constr=
uctor<br>
of A will likely need to be inlined.<br><span><font color=3D"#888888"><br>-=
-<br>Lawrence Crowl<br></font></span>
<div>
<div><br>--<br><br>---<br>You received this message because you are subscri=
bed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br>To=
 unsubscribe from this group and stop receiving emails from it, send an ema=
il to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"o7=
wYJHpCnrkJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"o7wYJHpCnrkJ">std-pr...@isocpp.org</a>.<br>Vis=
it this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/std=
-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/<wbr>isoc=
pp.org/group/std-<wbr>proposals/?hl=3Den</a>.<br>
<br><br></div></div></blockquote></div><br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_115_6571635.1367058484719--

.

------=_Part_4173_3602878.1367153899499
Content-Type: multipart/alternative;
 boundary="----=_Part_4174_21377872.1367153899499"

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

Will I have the same "efficiency" in debug mode as for the STL vectors?
Here are some benchmarks for the code that reverses an array of 10,000,000=
=20
elements:
=20
test              | Microsoft VS2012 | GCC 4.8.1 (g++)
vector (indexed)  |  1.112 sec.      | 0.126 sec.
vector+iterators  |  21.878 sec.     | 0.363 sec.
standard pointers |  0.042  sec.     | 0.046 sec.
=20
The file is attached.=20
Most of the code people run during development is in debug mode.
=20
Enjoy!
=20
Mikhail

On Saturday, April 27, 2013 11:28:04 AM UTC+1, Micha=C5=82 Dominiak wrote:

> Your "simpler syntax":
> 1) is more confusing than dynarray - x is a pointer, not an array!
> 2) is not searchable in most web search engines (while dynarray is)
> 3) does not carry information about size (while dynarray does)
>
> Cheers,
> Micha=C5=82 Dominiak
>
>
>

--=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/?hl=3Den.



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

<div>Will I have the same "efficiency" in debug mode as for the STL vectors=
?</div><div>Here are some benchmarks for the code that reverses an array of=
 10,000,000 elements:</div><div><font face=3D"courier new,monospace"></font=
>&nbsp;</div><div><font face=3D"courier new,monospace">test&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Microsoft =
VS2012 | GCC 4.8.1 (g++)<br>vector (indexed)&nbsp; |&nbsp; 1.112 sec.&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; | 0.126 sec.<br>vector+iterators&nbsp; |&nbsp; <fo=
nt color=3D"#ff0000">21.878 sec.</font>&nbsp;&nbsp;&nbsp;&nbsp; | <font col=
or=3D"#ff0000">0.363 sec.</font><br>standard pointers |&nbsp; 0.042&nbsp; s=
ec.&nbsp;&nbsp;&nbsp;&nbsp; | 0.046 sec.</font></div><div><font face=3D"Cou=
rier New"></font>&nbsp;</div><div><font face=3D"arial,sans-serif">The file =
is attached. </font></div><div><font face=3D"arial,sans-serif">Most of the =
code&nbsp;people run during development is in debug mode.</font></div><div>=
&nbsp;</div><div>Enjoy!</div><div>&nbsp;</div><div>Mikhail</div><div><br>On=
 Saturday, April 27, 2013 11:28:04 AM UTC+1, Micha=C5=82 Dominiak wrote:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;">Your "simpler syntax":<div>1) is more confu=
sing than dynarray - x is a pointer, not an array!</div><div>2) is not sear=
chable in most web search engines (while dynarray is)</div><div>3) does not=
 carry information about size (while dynarray does)</div><div><br></div><di=
v>Cheers,</div><div>Micha=C5=82 Dominiak</div><div><br><br>
</div></blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4174_21377872.1367153899499--
------=_Part_4173_3602878.1367153899499
Content-Type: text/plain; charset=US-ASCII; name=VectorEfficiency2.cpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=VectorEfficiency2.cpp
X-Attachment-Id: 44eea553-64a3-4cde-9e6b-fd0f0450aea6
Content-ID: <44eea553-64a3-4cde-9e6b-fd0f0450aea6>

// VectorEfficiency2.cpp : Defines the entry point for the console application.

#include <iostream>
#include <vector>
#include <ctime>
#include <chrono>

const std::size_t N = 10000000;

std::vector<double> v(N);

double *a = new double[N];

int main()
{

    for (int i = 0; i < N; i++)
    {
        v[i] = i+0.5;
        a[i] = i+0.5;
    }


    // VECTOR TEST
    auto tm1 = std::chrono::high_resolution_clock::now();
    size_t N2 = N/2;

    for (std::size_t i = 0, i2=N-1; i < N2; i++, i2--)
    {
        double x = v[i];
        v[i] = v[i2];
        v[i2] = x;
    }
    auto tm2 = std::chrono::high_resolution_clock::now();
    //auto s = tm2-tm1;
    //s.count() / std::chrono::system_clock::
    double seconds = std::chrono::duration_cast<std::chrono::milliseconds>(tm2-tm1).count() * 0.001;

    std::cout << "vector swap. time taken: " << seconds << std::endl;

    // VECTOR + ITERATORS
    tm1 = std::chrono::high_resolution_clock::now();

    std::vector<double>::iterator it;
    std::vector<double>::iterator it_stop = v.begin()+N2;
    std::vector<double>::reverse_iterator it_rev;

    for (it = v.begin(), it_rev = v.rbegin(); it != it_stop; it++, it_rev++)
    {
        double x = *it;
        *it = *it_rev;
        *it_rev = x;
    }
    tm2 = std::chrono::high_resolution_clock::now();
    seconds = std::chrono::duration_cast<std::chrono::milliseconds>(tm2-tm1).count() * 0.001;

    std::cout << "vector swap with iterators. time taken: " << seconds << std::endl;

    // STANDARD POINTERS
    tm1 = std::chrono::high_resolution_clock::now();

    for (std::size_t i = 0, i2=N-1; i < N2; i++, i2--)
    {
        double x = a[i];
        a[i] = a[i2];
        a[i2] = x;
    }
    tm2 = std::chrono::high_resolution_clock::now();
    seconds = std::chrono::duration_cast<std::chrono::milliseconds>(tm2-tm1).count() * 0.001;

    std::cout << "standard pointers swap. time taken: " << seconds << std::endl;

    delete [] a;
    return 0;
}



------=_Part_4173_3602878.1367153899499--

.

2013/4/28 Mikhail Semenov <mikhailsemenov1957@gmail.com>:
> Will I have the same "efficiency" in debug mode as for the STL vectors?

This depends on a concrete implementation, of-course. The standard
does not mandate any such modes.

> Here are some benchmarks for the code that reverses an array of 10,000,000
> elements:
>
> test              | Microsoft VS2012 | GCC 4.8.1 (g++)
> vector (indexed)  |  1.112 sec.      | 0.126 sec.
> vector+iterators  |  21.878 sec.     | 0.363 sec.
> standard pointers |  0.042  sec.     | 0.046 sec.
>
> The file is attached.
> Most of the code people run during development is in debug mode.

Maybe, but keep in mind that a Standard specification doesn't prevent
an implementation to add such debug modes also to the built-in runtime
arrays, so this example really doesn't demonstrate a weakness of the
providing std::dynarray via a Library implementation versus a built-in
technique. Furthermore, existing implementations can typically be
controlled to not perform any such checking even in debug mode at all.

These are really no arguments against Library-provided features, this
is all about quality of implementation. You should discuss such things
in vendor-specific newsgroups.

- 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/?hl=en.



.

------=_Part_36_15891904.1367160216497
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, April 28, 2013 5:58:19 AM UTC-7, Mikhail Semenov wrote:
>
> Will I have the same "efficiency" in debug mode as for the STL vectors?
> Here are some benchmarks for the code that reverses an array of 10,000,000
> elements:
>
> test              | Microsoft VS2012 | GCC 4.8.1 (g++)
> vector (indexed)  |  1.112 sec.      | 0.126 sec.
> vector+iterators  |  21.878 sec.     | 0.363 sec.
> standard pointers |  0.042  sec.     | 0.046 sec.
>
> The file is attached.
> Most of the code people run during development is in debug mode.
>

You know, you can turn off all of the debugging stuff in Microsoft's
standard library with #defines, right?

--

---
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/?hl=en.



------=_Part_36_15891904.1367160216497
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, April 28, 2013 5:58:19 AM UTC-7, Mikhail Semenov wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div>Will I have the same "effi=
ciency" in debug mode as for the STL vectors?</div><div>Here are some bench=
marks for the code that reverses an array of 10,000,000 elements:</div><div=
><font face=3D"courier new,monospace"></font>&nbsp;</div><div><font face=3D=
"courier new,monospace">test&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Microsoft VS2012 | GCC 4.8.1 (g++)<br>vec=
tor (indexed)&nbsp; |&nbsp; 1.112 sec.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 0.12=
6 sec.<br>vector+iterators&nbsp; |&nbsp; <font color=3D"#ff0000">21.878 sec=
..</font>&nbsp;&nbsp;&nbsp;&nbsp; | <font color=3D"#ff0000">0.363 sec.</font=
><br>standard pointers |&nbsp; 0.042&nbsp; sec.&nbsp;&nbsp;&nbsp;&nbsp; | 0=
..046 sec.</font></div><div><font face=3D"Courier New"></font>&nbsp;</div><d=
iv><font face=3D"arial,sans-serif">The file is attached. </font></div><div>=
<font face=3D"arial,sans-serif">Most of the code&nbsp;people run during dev=
elopment is in debug mode.</font><br></div></blockquote><div><br>You know, =
you can turn off all of the debugging stuff in Microsoft's standard library=
 with #defines, right?<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_36_15891904.1367160216497--

.

------=_Part_2708_18366030.1367169594297
Content-Type: text/plain; charset=ISO-8859-1

Nicol,

Yes if I use the following options for Microsoft VC++:

*(1) Use option "program database" /Z7 instead of /ZI "edit and continue".*

*(2) All options -> SDL -> NO /-sdl*

*(3) #define _ITERATOR_DEBUG_LEVEL 0*
I will get much better figures:
*vector (indexed) 0.121 sec.
vector+iterators 0.717
standard pointers 0.041
*
My point is that it is still slower than pointers.  If I run a system
simulator in a debug mode (which I often do), it runs not as fast as I
would like.
Another issue (maybe small issue) is that in VS2012  a vector's element
v[i] is not displayed during debugging:
you have to write v.operator[](i).

Anyway, since the dynamic arrays have been approved by the Committee we
have to live with it.

Regards,
Mikhail

P.S. By the way, similar issues applies to some other STL features.
Although *bind* is fast in the release mode, it's rather slow
in the debug mode.


On Sunday, April 28, 2013 3:43:36 PM UTC+1, Nicol Bolas wrote:

>
>
> On Sunday, April 28, 2013 5:58:19 AM UTC-7, Mikhail Semenov wrote:
>>
>> Will I have the same "efficiency" in debug mode as for the STL vectors?
>> Here are some benchmarks for the code that reverses an array of
>> 10,000,000 elements:
>>
>> test              | Microsoft VS2012 | GCC 4.8.1 (g++)
>> vector (indexed)  |  1.112 sec.      | 0.126 sec.
>> vector+iterators  |  21.878 sec.     | 0.363 sec.
>> standard pointers |  0.042  sec.     | 0.046 sec.
>>
>> The file is attached.
>> Most of the code people run during development is in debug mode.
>>
>
> You know, you can turn off all of the debugging stuff in Microsoft's
> standard library with #defines, right?
>

--

---
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/?hl=en.



------=_Part_2708_18366030.1367169594297
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Nicol,</div><div>&nbsp;</div><div>Yes if I use the following options f=
or Microsoft VC++:</div><p><strong>(1) Use option "program database" /Z7 in=
stead of /ZI "edit and continue".</strong></p><p><strong>(2) All options -&=
gt; SDL -&gt; NO /-sdl</strong></p><p><strong>(3) #define _ITERATOR_DEBUG_L=
EVEL 0</strong></p><div>I will get much better figures:</div><div><strong>v=
ector (indexed) 0.121 sec.<br>vector+iterators 0.717<br>standard pointers 0=
..041<br></strong></div><div>My point is that it is still slower than pointe=
rs.&nbsp; If I run a system simulator in a debug mode (which I often do), i=
t runs not as fast as I would like.</div><div>Another issue (maybe small is=
sue) is that in VS2012&nbsp; a vector's element v[i] is not displayed durin=
g debugging:</div><div>you have to write v.operator[](i).&nbsp;</div><div>&=
nbsp;</div><div>Anyway, since the dynamic arrays have been approved by the =
Committee we have to live with it.</div><div>&nbsp;</div><div>Regards,</div=
><div>Mikhail</div><div>&nbsp;</div><div>P.S. By the way, similar issues ap=
plies to some other STL features. Although <strong>bind</strong> is fast in=
 the release mode, it's rather slow </div><div>in the debug mode.</div><div=
>&nbsp;</div><div>&nbsp;</div><div>On Sunday, April 28, 2013 3:43:36 PM UTC=
+1, Nicol Bolas wrote:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><br><br>On Sunday,=
 April 28, 2013 5:58:19 AM UTC-7, Mikhail Semenov wrote:<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;"><div>Will I have the same "efficiency" in debug mode as for the=
 STL vectors?</div><div>Here are some benchmarks for the code that reverses=
 an array of 10,000,000 elements:</div><div><font face=3D"courier new,monos=
pace"></font>&nbsp;</div><div><font face=3D"courier new,monospace">test&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| Microsoft VS2012 | GCC 4.8.1 (g++)<br>vector (indexed)&nbsp; |&nbsp; 1.11=
2 sec.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 0.126 sec.<br>vector+iterators&nbsp;=
 |&nbsp; <font color=3D"#ff0000">21.878 sec.</font>&nbsp;&nbsp;&nbsp;&nbsp;=
 | <font color=3D"#ff0000">0.363 sec.</font><br>standard pointers |&nbsp; 0=
..042&nbsp; sec.&nbsp;&nbsp;&nbsp;&nbsp; | 0.046 sec.</font></div><div><font=
 face=3D"Courier New"></font>&nbsp;</div><div><font face=3D"arial,sans-seri=
f">The file is attached. </font></div><div><font face=3D"arial,sans-serif">=
Most of the code&nbsp;people run during development is in debug mode.</font=
><br></div></blockquote><div><br>You know, you can turn off all of the debu=
gging stuff in Microsoft's standard library with #defines, right?<br></div>=
</blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2708_18366030.1367169594297--

.

------=_Part_870_30377776.1370027350735
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, April 3, 2013 2:32:33 AM UTC+1, Nicol Bolas wrote:
>
> N3532 lays out a proposal<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3532.html>for including a dynamic array type in C++ called `dynarray`. A "dynamic
> array" is an array who's length is fixed, but is only provided at runtime,
> rather than static arrays that have compile-time array lengths.
>
> The big selling point of `dynarray`, and the reason it exists, is so that
> we can have stack-based arrays with runtime-determined sizes. Instead of
> taking the C99 approach of allowing this:
>
> int size = 5;
> Type arr[size];
>
> We would instead allow this:
>
> int size = 5;
> dynarray<Type> arr(size);
>
> The dynamic array proposal allows (but does not require) that `arr` in the
> above case be allocated on the stack. The dynamic array is only allowed to
> be allocated on the stack when the array itself is on the stack; if you
> were to do `new dynarray<Type>`, you would have a heap-allocated array. for
> me. But it isn't mandated by the standard (for fear of causing complex a
> lot of work for compiler implementers it seems - given that in the proposal
> it mentions implementation as a separate library rather than deeper
> integration to provide for stack allocation).
>

I'm looking at the runtime-sized array proposals & I really want to use
dynarray in my code base, but proposing to rely on QoI seems is way to
wishy-washy & indeterminate to go ahead and do so. If there is no
guaranteed benefit to dynarray users when dynarray utilises heap
allocation, as opposed to just controlling a vector during usage, then the
big stack-usage selling point is really what a run-time sized array is all
about.

If there are requirements satisfied by a heap using dynarray that can't be
satisfied by a vector, then there could legitimately be 2 separate types as
suggested (one guaranteed to utilise the underlying stack and the other
utilising the heap & movable). It's the stack-utilising runtime-sized
arrays that considerably offer what vector can't.

std::dynarray to language runtime arrays shouldbe what std::array is to raw
("C-style") arrays - a wrapper exposing an API providing better safety,
convenience of use, & consistent integration with the rest of the library
(iterators, algorithms, etc.). Just standardised arrays whose elements have
automatic storage duration, sized at runtime, integrating well with the
rest of the library. Guaranteed so to be relied upon.

--

---
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/?hl=en.



------=_Part_870_30377776.1370027350735
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, April 3, 2013 2:32:33 AM UTC+1, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><a href=3D"http://www.open-std.or=
g/JTC1/SC22/WG21/docs/papers/2013/n3532.html" target=3D"_blank">N3532 lays =
out a proposal</a> for including a dynamic array type in C++ called `dynarr=
ay`. A "dynamic array" is an array who's length is fixed, but is only provi=
ded at runtime, rather than static arrays that have compile-time array leng=
ths.<br><br>The big selling point of `dynarray`, and the reason it exists, =
is so that we can have stack-based arrays with runtime-determined sizes. In=
stead of taking the C99 approach of allowing this:<br><br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color=
:#008">int</span><span style=3D"color:#000"> size </span><span style=3D"col=
or:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:=
#066">5</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#606">Type</span><span style=3D"color:#000=
"> arr</span><span style=3D"color:#660">[</span><span style=3D"color:#000">=
size</span><span style=3D"color:#660">];</span></div></code></div><br>We wo=
uld instead allow this:<br><br><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-=
wrap:break-word"><code><div><span style=3D"color:#008">int</span><span styl=
e=3D"color:#000"> size </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#066">5</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>dynarray</span><span=
 style=3D"color:#660">&lt;</span><span style=3D"color:#606">Type</span><spa=
n style=3D"color:#660">&gt;</span><span style=3D"color:#000"> arr</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">size</span><span=
 style=3D"color:#660">);</span><span style=3D"color:#000"><br></span></div>=
</code></div><br>The dynamic array proposal allows (but does not require) t=
hat `arr` in the above case be allocated on the stack. The dynamic array is=
 only allowed to be allocated on the stack when the array itself is on the =
stack; if you were to do `new dynarray&lt;Type&gt;`, you would have a heap-=
allocated array. for me. But it isn't mandated by the standard (for fear of=
 causing complex a lot of work for compiler implementers it seems - given t=
hat in the proposal it mentions implementation as a separate library rather=
 than deeper integration to provide for stack allocation).<br></blockquote>=
<div><br>I'm looking at the runtime-sized array proposals &amp; I really wa=
nt to use dynarray in my code base, but proposing to rely on QoI seems is w=
ay to wishy-washy &amp; indeterminate to go ahead and do so. If there is no=
 guaranteed benefit to dynarray users when dynarray utilises heap allocatio=
n, as opposed to just controlling a vector during usage, then the big stack=
-usage selling point is really what a run-time sized array is all about.<br=
><br>If there are requirements satisfied by a heap using dynarray that can'=
t be satisfied by a vector, then there could legitimately be 2 separate typ=
es as suggested (one guaranteed to utilise the underlying stack and the oth=
er utilising the heap &amp; movable). It's the stack-utilising runtime-size=
d arrays that considerably offer what vector can't.<br><br>std::dynarray to=
 language runtime arrays shouldbe what std::array is to raw ("C-style") arr=
ays - a wrapper exposing an API providing better safety, convenience of use=
, &amp; consistent integration with the rest of the library (iterators, alg=
orithms, etc.). Just standardised arrays whose elements have automatic stor=
age duration, sized at runtime, integrating well with the rest of the libra=
ry. Guaranteed so to be relied upon.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_870_30377776.1370027350735--

.

------=_Part_268_8907049.1370031375385
Content-Type: text/plain; charset=ISO-8859-1

dynarray will never be a first-class citizen of the rest of the library. It
will forever be endowed with numerous special cases.

--

---
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/?hl=en.



------=_Part_268_8907049.1370031375385
Content-Type: text/html; charset=ISO-8859-1

dynarray will never be a first-class citizen of the rest of the library. It will forever be endowed with numerous special cases.

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_268_8907049.1370031375385--

.

On 5/31/13, Dominic Burghuber <dmb.youcangetme@googlemail.com> wrote:
> I'm looking at the runtime-sized array proposals & I really
> want to use dynarray in my code base, but proposing to rely on
> QoI seems is way to wishy-washy & indeterminate to go ahead and
> do so. If there is no guaranteed benefit to dynarray users when
> dynarray utilises heap allocation, as opposed to just controlling
> a vector during usage, then the big stack-usage selling point is
> really what a run-time sized array is all about.

It is also about knowing that the size will not change.  If you
want to create a shadow array, then it is very handy to know that
the size cannot change because if you do not know that, then you
need an additional communcation channel.

> If there are requirements satisfied by a heap using dynarray that
> can't be satisfied by a vector, then there could legitimately
> be 2 separate types as suggested (one guaranteed to utilise the
> underlying stack and the other utilising the heap & movable). It's
> the stack-utilising runtime-sized arrays that considerably offer
> what vector can't.

As above.  But also, if the dynarray is allocated on the heap,
then its storage cannot be allocated on the stack.  So the choice
of implementation must be present.  Prohibiting dynarray from being
heap allocated has some undesireable consequences.

> std::dynarray to language runtime arrays shouldbe what std::array
> is to raw ("C-style") arrays - a wrapper exposing an API providing
> better safety, convenience of use, & consistent integration with
> the rest of the library (iterators, algorithms, etc.). Just
> standardised arrays whose elements have automatic storage
> duration, sized at runtime, integrating well with the rest of
> the library. Guaranteed so to be relied upon.

A guarantee here would be counter-productive.  First, it delays
the time until the feature is available.  Second, in multi-threaded
environments, stack size is often heavily constrained and defined
by the "high water mark" in any thread.  You want the permission
to shift the occasional extra-large allocation to the heap in order
to get enough threads into the available memory.

If on-stack allocation is important to you, let your vendor know.

--
Lawrence Crowl

--

---
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/?hl=en.



.

------=_Part_802_28787797.1370043242743
Content-Type: text/plain; charset=ISO-8859-1



On Friday, May 31, 2013 9:26:09 PM UTC+1, Lawrence Crowl wrote:
>
>
> It is also about knowing that the size will not change.  If you  want to
> create a shadow array, then it is very handy to know that  the size cannot
> change because if you do not know that, then you  need an additional
> communication channel.
>
>
I don't know what a dynamically allocated dynarray could give me that
std::vector can't. I can manage (constrain usage of) a vector in a way that
I ensure the size will not change. I've also seen it said that it may be
portable to other types (std::vector is also contiguous & just as portable
to other types, including across an ABI). Plus I can also move & copy it
around without worrying it may be on the stack, adjust it's backing store
and reuse it somewhere completely elsewhere, etc., etc. dynarray seems
pretty limited in that respect (due to constraints it may be on the stack).

Are any gains of dynarray when utilising dynamic storage (vs std::vector)
all dependent on the QoI? Is there anything with a std::dynarray that can't
be done in using (including how you manage) a std::vector? Other than you
"may" get an optimisation (i.e. possible stack usage depending on
implementation) when used as an automatic variable.


>
> But also, if the dynarray is allocated on the heap, then its storage
> cannot be allocated on the stack.  So the choice of implementation must be
> present.  Prohibiting dynarray from being heap allocated has some
> undesireable consequences.
>
>
I understand, like new-ing std::array. It's more that an implementation of
dynarray may dynamically allocate its elements underneath the hood, not
that the container itself can reside in dynamic memory. I'm desiring
automatic lifetime allocation of elements, fully understanding that actual
stack memory is implementation defined, but that if I'm ever going to get
it then for that chance I need a guarantee that the container be allocating
its elements with automatic lifetime within the container itself (& as an
aside - probably a new thread off a platform's main app thread).


> > std::dynarray to language runtime arrays shouldbe what std::array
> > is to raw ("C-style") arrays - a wrapper exposing an API providing
> > better safety, convenience of use, & consistent integration with
> > the rest of the library (iterators, algorithms, etc.). Just
> > standardised arrays whose elements have automatic storage
> > duration, sized at runtime, integrating well with the rest of
> > the library. Guaranteed so to be relied upon.
>
> A guarantee here would be counter-productive.  First, it delays
> the time until the feature is available.


 Ok, but as you know, once standardised there is next to no chance of
changing something like this without breaking code. Is this some kind of
phasing in strategy? If so will it be mandatory eventually? I've not seen
that before with C++ standards!


> Second, in multi-threaded environments, stack size is often heavily
> constrained and defined
> by the "high water mark" in any thread.


You would expect users to be sensible in any usage of a stack-allocated
array, & test their code. Just like usage with raw arrays or std::array
when not part of a dynamic allocation.


> You want the permission to shift the occasional extra-large allocation to
> the heap in order to get enough threads into the available memory.
>
>
I was going to do that for my prototype dynarray implementation. In that if
the specified element count on construction * sizeof(T) is a certain size,
switch from a private allocation function utilising alloca /_alloca to a
different private allocation function for new-ing memory. But as yet I
didn't bother because I can just use a vector in such a case (& again I
don't see the benefits that dynarray gives me in that case vs vector).


> If on-stack allocation is important to you, let your vendor know.
>
>
It would be nice and speedy for small arrays in tight spaces. Its the
guaranteed automatic duration of elements to the container that I was
hoping dynarray could give me & also language runtime-sized arrays with
automatic duration.

Am I missing something (i.e. something isn't clicking about what is
proposed yet)? Should the proposal be fully ratified internationally, am I
just wanting something I can't ever know for sure I'm going to get via the
proposed?

Thank you,

--

---
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/?hl=en.



------=_Part_802_28787797.1370043242743
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, May 31, 2013 9:26:09 PM UTC+1, Lawrence Crowl wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><br>It is also about knowing that =
the size will not change. &nbsp;If you&nbsp;
want to create a shadow array, then it is very handy to know that&nbsp;
the size cannot change because if you do not know that, then you&nbsp;
need an additional communication channel.
<br>
<br></blockquote><div><br> I  don't know what a dynamically allocated dynar=
ray could give me that std::vector can't. I can manage (constrain usage of)=
 a vector in a way that I ensure the size will not change. I've also seen i=
t said that it may be portable to other types=20
(std::vector is also contiguous &amp; just as portable to other types,=20
including across an ABI).=20
Plus I can also move &amp; copy it around without worrying it may be on=20
the stack, adjust it's backing store and reuse it somewhere completely=20
elsewhere, etc., etc. dynarray seems pretty limited in that respect (due
 to constraints it may be on the stack). <br><br>Are any gains of dynarray =
when utilising dynamic storage (vs=20
std::vector) all dependent on the QoI? Is there anything with a=20
std::dynarray that can't be done in using (including how you manage) a=20
std::vector? Other than you "may" get an optimisation (i.e. possible stack =
usage depending on implementation)
 when used as an automatic variable.<br>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><br>But also, if the dynarray is allocated on the hea=
p, then its storage cannot be allocated on the stack. &nbsp;So the choice o=
f implementation must be present. &nbsp;Prohibiting dynarray from being hea=
p allocated has some undesireable consequences.
<br>
<br></blockquote><div><br>I understand, like new-ing std::array. It's more =
that an implementation of dynarray may dynamically allocate its elements un=
derneath the hood, not that the container itself can reside in dynamic memo=
ry. I'm desiring automatic lifetime allocation of elements, fully understan=
ding that actual stack memory is implementation defined, but that if I'm ev=
er going to get it then for that chance I need a guarantee that the contain=
er be allocating its elements with automatic lifetime within the container =
itself (&amp; as an aside - probably a new thread off a platform's main app=
 thread).<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; =
std::dynarray to language runtime arrays shouldbe what std::array
<br>&gt; is to raw ("C-style") arrays - a wrapper exposing an API providing
<br>&gt; better safety, convenience of use, &amp; consistent integration wi=
th
<br>&gt; the rest of the library (iterators, algorithms, etc.). Just
<br>&gt; standardised arrays whose elements have automatic storage
<br>&gt; duration, sized at runtime, integrating well with the rest of
<br>&gt; the library. Guaranteed so to be relied upon.
<br>
<br>A guarantee here would be counter-productive. &nbsp;First, it delays
<br>the time until the feature is available. &nbsp;</blockquote><div>&nbsp;=
</div><div>&nbsp;Ok, but as you know, once standardised there is next to no=
 chance of changing something like this without breaking code. Is this some=
 kind of phasing in strategy? If so will it be mandatory eventually? I've n=
ot seen that before with C++ standards!<br></div><div>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">Second, in multi-threaded
environments, stack size is often heavily constrained and defined
<br>by the "high water mark" in any thread.</blockquote><div><br>You would =
expect users to be sensible in any usage of a stack-allocated array, &amp; =
test their code. Just like usage with raw arrays or std::array when not par=
t of a dynamic allocation.<br>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">You want the permission
to shift the occasional extra-large allocation to the heap in order
to get enough threads into the available memory.
<br>
<br></blockquote><div><br>I was going to do that for my prototype dynarray =
implementation. In that if the specified element count on construction * si=
zeof(T) is a certain size, switch from a private allocation function utilis=
ing alloca /_alloca to a different private allocation function for new-ing =
memory. But as yet I didn't bother because I can just use a vector in such =
a case (&amp; again I don't see the benefits that dynarray gives me in that=
 case vs vector).<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">If on-stack allocation is important to you, let your vendor know.
<br>
<br></blockquote><div><br>It would be nice and speedy for small arrays in t=
ight spaces. Its the guaranteed automatic duration of elements to the conta=
iner that I was hoping dynarray could give me &amp; also language runtime-s=
ized arrays with automatic duration. <br><br>Am I missing something (i.e. s=
omething isn't clicking about what is proposed yet)? Should the proposal be=
 fully ratified internationally, am I just wanting something I can't ever k=
now for sure I'm going to get via the proposed?<br><br>Thank you,<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_802_28787797.1370043242743--

.

------=_Part_1071_7363249.1370044663316
Content-Type: text/plain; charset=ISO-8859-1


To clarify, I'm just looking for that real sweet spot between std::array &
std::vector, so I can data-drive my code, read that data & determine at
runtime what size I want my fixed-size, containers to be. For anything that
might grow there's std::vector, or others. And for those fixed size
containers I want them then just like array (elements in a continguous
block, allocated however I choose to allocate the container, whether
automatically or dynamically, not choosen for me by an implementation
allocating the backing store dynamically). I was hoping the standard would
mandate that.

--

---
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/?hl=en.



------=_Part_1071_7363249.1370044663316
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>To clarify, I'm just looking for that real sweet spot between std::arra=
y &amp; std::vector, so I can data-drive my code, read that data &amp; dete=
rmine at runtime what size I want my fixed-size, containers to be. For anyt=
hing that might grow there's std::vector, or others. And for those fixed si=
ze containers I want them then just like array (elements in a continguous b=
lock, allocated however I choose to allocate the container, whether automat=
ically or dynamically, not choosen for me by an implementation allocating t=
he backing store dynamically). I was hoping the standard would mandate that=
..<br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1071_7363249.1370044663316--

.

On May 31, 2013, at 6:34 PM, Dominic Burghuber
<dmb.youcangetme@googlemail.com> wrote:

> Plus I can also move & copy [vector] around without worrying it may be on the stack,

The problem is, you cannot. You have to ensure that the lifetime of
the storage is at least as long as all copies of the vector.  Dynarray
solves this.
 --
 Nevin ":-)" Liber
 <mailto:nevin@eviloverlord.com>
 (847) 691-1404
(sent from my iPad)

--

---
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/?hl=en.



.

------=_Part_1420_22008810.1370077153935
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 31, 2013 4:34:02 PM UTC-7, Dominic Burghuber wrote:
>
> On Friday, May 31, 2013 9:26:09 PM UTC+1, Lawrence Crowl wrote:
>>
>>
>> It is also about knowing that the size will not change.  If you  want to
>> create a shadow array, then it is very handy to know that  the size cannot
>> change because if you do not know that, then you  need an additional
>> communication channel.
>>
>>
> I don't know what a dynamically allocated dynarray could give me that
> std::vector can't. I can manage (constrain usage of) a vector in a way that
> I ensure the size will not change.
>

Only if your code is the *only* code that touches that object. If you hand
a non-const `std::vector` off to code you don't control, there's no way
that you can guarantee that someone won't change the size.

Having a dynamically allocated array who's size guarantee-ably cannot be
changed after construction is a good thing. Someone mentioned that it could
be done as a "container adapter" wrapper over std::vector, which would also
facilitate move support into and out of it.


> Are any gains of dynarray when utilising dynamic storage (vs std::vector)
> all dependent on the QoI? Is there anything with a std::dynarray that can't
> be done in using (including how you manage) a std::vector? Other than you
> "may" get an optimisation (i.e. possible stack usage depending on
> implementation) when used as an automatic variable.
>

Yes; that's the point.

The alternatives are these: a dynarray class which cannot be stack
allocated, a dynarray class which must be stack allocated, or what we have
now. The first one doesn't actually solve the problem of wanting
stack-allocated memory inside other objects.

The second one is terrible, because when a particular system will prevent
stack allocation is implementation-dependent. Some systems might allow you
to stack allocate a 30,000 integers; some might not. You would have to have
two different code-paths for every use of dynarray: one for if it works,
and one for if it doesn't.

So the third one is the only viable alternative: allow the implementation
to define when it will be stack allocated, but design the interface so that
we always assume it is (thus no move support).

--

---
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/?hl=en.



------=_Part_1420_22008810.1370077153935
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 31, 2013 4:34:02 PM UTC-7, Dominic Burghuber wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On Friday, May 31, 2013 9:26:09 PM UTC+=
1, Lawrence Crowl wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>It is a=
lso about knowing that the size will not change. &nbsp;If you&nbsp;
want to create a shadow array, then it is very handy to know that&nbsp;
the size cannot change because if you do not know that, then you&nbsp;
need an additional communication channel.
<br>
<br></blockquote><div><br> I  don't know what a dynamically allocated dynar=
ray could give me that std::vector can't. I can manage (constrain usage of)=
 a vector in a way that I ensure the size will not change.</div></blockquot=
e><div><br>Only if your code is the <i>only</i> code that touches that obje=
ct. If you hand a non-const `std::vector` off to code you don't control, th=
ere's no way that you can guarantee that someone won't change the size.<br>=
<br>Having a dynamically allocated array who's size guarantee-ably cannot b=
e changed after construction is a good thing. Someone mentioned that it cou=
ld be done as a "container adapter" wrapper over std::vector, which would a=
lso facilitate move support into and out of it.<br></div><div>&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>Are any gains of dynarray =
when utilising dynamic storage (vs=20
std::vector) all dependent on the QoI? Is there anything with a=20
std::dynarray that can't be done in using (including how you manage) a=20
std::vector? Other than you "may" get an optimisation (i.e. possible stack =
usage depending on implementation)
 when used as an automatic variable.<br></div></blockquote><div><br>Yes; th=
at's the point.<br><br>The alternatives are these: a dynarray class which c=
annot be stack allocated, a dynarray class which must be stack allocated, o=
r what we have now. The first one doesn't actually solve the problem of wan=
ting stack-allocated memory inside other objects.<br><br>The second one is =
terrible, because when a particular system will prevent stack allocation is=
 implementation-dependent. Some systems might allow you to stack allocate a=
 30,000 integers; some might not. You would have to have two different code=
-paths for every use of dynarray: one for if it works, and one for if it do=
esn't.<br><br>So the third one is the only viable alternative: allow the im=
plementation to define when it will be stack allocated, but design the inte=
rface so that we always assume it is (thus no move support).<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1420_22008810.1370077153935--

.

------=_Part_2090_4407833.1370215934793
Content-Type: text/plain; charset=ISO-8859-1



>
> The second one is terrible, because when a particular system will prevent
> stack allocation is implementation-dependent. Some systems might allow you
> to stack allocate a 30,000 integers; some might not. You would have to have
> two different code-paths for every use of dynarray: one for if it works,
> and one for if it doesn't.
>
>
I'm not sure it is actually that terrible how it sounds to you - it's the
same thing when you want to have a std::array<int, 30000> - some systems
might allow you to do that, some might not, and you will have two different
code-paths..

For me, dynarray<int> arr(n); is to int arr[n]; what array<int, 10> arr; is
to int arr[10]; So dynarray should behave exactly like array, with the
exact same benefits and drawbacks it has - including move support! (meaning
moving elements into the new container). Every dynarray example should
behave exactly how array works, with adding the actual size to the type, so
your example in the first post should work exactly the same as:
template<int size>
array<Type, size> GetArray()
{
  array<Type, size> arr
  //Fill in arr with stuff.
  return arr;
}

unique_ptr<array<Type, 12>> arrPtr = new array<Type, 12>(GetArray<12>());
Everyone knows what is happening here, why should the case with dynarray be
any different. (*khm* make_unique *khm*)

Moving on, the case of runtime-const-size stack-allocated container is a
different beast, dynarray should not try to solve it by its own, but
unique_ptr<dynarray<T>> is what one needs in this case; the same way how
unique_ptr<array<T, n>> works for a compile-time-size stack allocated
arrays. The interface might be a bit wonky due to the pointer semantics
though, but it's not that bad, you just have to use
(*unique_ptr_to_dynarray_of_int)[42]; instead of vector_of_int[42];

Regards, Robert

--

---
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/?hl=en.



------=_Part_2090_4407833.1370215934793
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>The second one is=
 terrible, because when a particular system will prevent stack allocation i=
s implementation-dependent. Some systems might allow you to stack allocate =
a 30,000 integers; some might not. You would have to have two different cod=
e-paths for every use of dynarray: one for if it works, and one for if it d=
oesn't.<br><br></div></blockquote><div><br>I'm not sure it is actually that=
 terrible how it sounds to you - it's the same thing when you want to have =
a std::array&lt;int, 30000&gt; - some systems might allow you to do that, s=
ome might not, and you will have two different code-paths..<br><br>For me, =
dynarray&lt;int&gt; arr(n); is to int arr[n]; what array&lt;int, 10&gt; arr=
; is to int arr[10]; So dynarray should behave exactly like array, with the=
 exact same benefits and drawbacks it has - including move support! (meanin=
g moving elements into the new container). Every dynarray example should be=
have exactly how array works, with adding the actual size to the type, so y=
our example in the first post should work exactly the same as:<br><div styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code><di=
v><span style=3D"color:#000">template&lt;int size&gt;<br>array</span><span =
style=3D"color:#660">&lt;</span><span style=3D"color:#606">Type, size</span=
><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">GetArray</span><span style=3D"color:#660">(</span=
><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><=
span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; arr=
ay</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#606">T=
ype</span><span style=3D"color:#660">, size&gt;</span><span style=3D"color:=
#000"> arr</span><span style=3D"color:#660"><br></span><span style=3D"color=
:#660"></span><span style=3D"color:#000">&nbsp; </span><span style=3D"color=
:#800">//Fill in arr with stuff.</span><span style=3D"color:#000"><br>&nbsp=
; </span><span style=3D"color:#008">return</span><span style=3D"color:#000"=
> arr</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br=
><br>unique_ptr</span><span style=3D"color:#660">&lt;</span><span style=3D"=
color:#000">array</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#606">Type</span><span style=3D"color:#660">, 12&gt;&gt;</span><s=
pan style=3D"color:#000"> arrPtr </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">new</span><=
span style=3D"color:#000"> array</span><span style=3D"color:#660">&lt;</spa=
n><span style=3D"color:#606">Type</span><span style=3D"color:#660">, 12&gt;=
(</span><span style=3D"color:#606">GetArray</span><span style=3D"color:#660=
">&lt;12&gt;(</span><span style=3D"color:#066"></span><span style=3D"color:=
#660">));</span><span style=3D"color:#000"><br></span></div></code></div>Ev=
eryone knows what is happening here, why should the case with dynarray be a=
ny different. (*khm* make_unique *khm*)<br><br>Moving on, the case of runti=
me-const-size stack-allocated container is a different beast, dynarray shou=
ld not try to solve it by its own, but unique_ptr&lt;dynarray&lt;T&gt;&gt; =
is what one needs in this case; the same way how unique_ptr&lt;array&lt;T, =
n&gt;&gt; works for a compile-time-size stack allocated arrays. The interfa=
ce might be a bit wonky due to the pointer semantics though, but it's not t=
hat bad, you just have to use (*unique_ptr_to_dynarray_of_int)[42]; instead=
 of vector_of_int[42];<br><br>Regards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2090_4407833.1370215934793--

.

On 6/2/13, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> > The second one is terrible, because when a particular system
> > will prevent stack allocation is implementation-dependent. Some
> > systems might allow you to stack allocate a 30,000 integers;
> > some might not. You would have to have two different code-paths
> > for every use of dynarray: one for if it works, and one for if
> > it doesn't.
>
> I'm not sure it is actually that terrible how it sounds to you
> - it's the same thing when you want to have a std::array<int,
> 30000> - some systems might allow you to do that, some might not,
> and you will have two different code-paths.

Writing two different code paths in source code is a programming
burden.  If those two paths can be handled by the compiler,
everyone wins.

> For me, dynarray<int> arr(n); is to int arr[n]; what
> array<int, 10> arr; is to int arr[10];

Okay so far.

> So dynarray should behave exactly like array,

But you cannot put int arr[n] inside a struct.  So, there is a
pretty fundamental restriction we would like to avoid with dynarray.

> with the exact same benefits and drawbacks it has - including move
> support! (meaning moving elements into the new container). Every
> dynarray example should behave exactly how array works, with
> adding the actual size to the type, so your example in the first
> post should work exactly the same as:
>
> template<int size>
> array<Type, size> GetArray()
> {
>   array<Type, size> arr
>   //Fill in arr with stuff.
>   return arr;
> }
>
> unique_ptr<array<Type, 12>> arrPtr
>   =3D new array<Type, 12>(GetArray<12>());
>
> Everyone knows what is happening here, why should the case with
> dynarray be any different. (*khm* make_unique *khm*)

We could reasonably add move construction to dynarray, but not move
assignment.  The reason is that move assignment would potentially
change the size, which we do not permit by design.

> Moving on, the case of runtime-const-size stack-allocated
> container is a different beast, dynarray should not try to solve
> it by its own, but unique_ptr<dynarray<T>> is what one needs in
> this case; the same way how unique_ptr<array<T, n>> works for
> a compile-time-size stack allocated arrays. The interface might
> be a bit wonky due to the pointer semantics though, but it's not
> that bad, you just have to use
>
> (*unique_ptr_to_dynarray_of_int)[42]; instead of vector_of_int[42];

I fail to understand how adding unique_ptr in here helps us get
stack allocation.

--=20
Lawrence Crowl

--=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/?hl=3Den.



.

------=_Part_2723_1351331.1370252947521
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, June 2, 2013 4:32:14 PM UTC-7, R=F3bert D=E1vid wrote:
>
>
>> The second one is terrible, because when a particular system will preven=
t=20
>> stack allocation is implementation-dependent. Some systems might allow y=
ou=20
>> to stack allocate a 30,000 integers; some might not. You would have to h=
ave=20
>> two different code-paths for every use of dynarray: one for if it works,=
=20
>> and one for if it doesn't.
>>
>>
> I'm not sure it is actually that terrible how it sounds to you - it's the=
=20
> same thing when you want to have a std::array<int, 30000> - some systems=
=20
> might allow you to do that, some might not, and you will have two differe=
nt=20
> code-paths..
>

There's a really big difference here. If it won't let me do=20
`std::array<int, 30000>`, the *compiler* will tell me. I will know before=
=20
my application *ships*. Therefore, I will not need different code-paths; I=
=20
will simply change my code for the lowest-common-denominator compiler.

That's not the case for `dynarray`. Not unless you can ensure the execution=
=20
of all of your code in every reasonable configuration on every expected=20
system.
=20

> For me, dynarray<int> arr(n); is to int arr[n]; what array<int, 10> arr;=
=20
> is to int arr[10];
>

Well, there's your problem: that's *not* what dynarray is for. It's wrong=
=20
to blame a class for not doing something that it's *not trying to do*.=20
Rather than trying to convert a class into being what you think it ought to=
=20
be, you should be asking for a class that has the particular features you=
=20
want it to have.

Moving on, the case of runtime-const-size stack-allocated container is a=20
> different beast, dynarray should not try to solve it by its own, but=20
> unique_ptr<dynarray<T>> is what one needs in this case; the same way how=
=20
> unique_ptr<array<T, n>> works for a compile-time-size stack allocated=20
> arrays.
>

No it does not. `unqiue_ptr<array<>>` does not allocate *anything* on the=
=20
stack. `array<>` is only allocated on the stack if it is allocated *on the=
=20
stack*, and `unique_ptr` *cannot* store stack-allocated objects. So if you=
=20
want to create a `unique_ptr<array<>>`, you're going to have to heap=20
allocate that `array`.

--=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/?hl=3Den.



------=_Part_2723_1351331.1370252947521
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, June 2, 2013 4:32:14 PM UTC-7, R=F3bert D=E1vid wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div><br>The second one is terrible, because when a particular system will=
 prevent stack allocation is implementation-dependent. Some systems might a=
llow you to stack allocate a 30,000 integers; some might not. You would hav=
e to have two different code-paths for every use of dynarray: one for if it=
 works, and one for if it doesn't.<br><br></div></blockquote><div><br>I'm n=
ot sure it is actually that terrible how it sounds to you - it's the same t=
hing when you want to have a std::array&lt;int, 30000&gt; - some systems mi=
ght allow you to do that, some might not, and you will have two different c=
ode-paths..<br></div></blockquote><div><br>There's a really big difference =
here. If it won't let me do `std::array&lt;int, 30000&gt;`, the <i>compiler=
</i> will tell me. I will know before my application <i>ships</i>. Therefor=
e, I will not need different code-paths; I will simply change my code for t=
he lowest-common-denominator compiler.<br><br>That's not the case for `dyna=
rray`. Not unless you can ensure the execution of all of your code in every=
 reasonable configuration on every expected system.<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>For me, dynarray&lt;int&gt; arr(n=
); is to int arr[n]; what array&lt;int, 10&gt; arr; is to int arr[10];</div=
></blockquote><div><br>Well, there's your problem: that's <i>not</i> what d=
ynarray is for. It's wrong to blame a class for not doing something that it=
's <i>not trying to do</i>. Rather than trying to convert a class into bein=
g what you think it ought to be, you should be asking for a class that has =
the particular features you want it to have.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>Moving on, the case of runtime-const-size =
stack-allocated container is a different beast, dynarray should not try to =
solve it by its own, but unique_ptr&lt;dynarray&lt;T&gt;&gt; is what one ne=
eds in this case; the same way how unique_ptr&lt;array&lt;T, n&gt;&gt; work=
s for a compile-time-size stack allocated arrays.</div></blockquote><div><b=
r>No it does not. `unqiue_ptr&lt;array&lt;&gt;&gt;` does not allocate <i>an=
ything</i> on the stack. `array&lt;&gt;` is only allocated on the stack if =
it is allocated <i>on the stack</i>, and `unique_ptr` <i>cannot</i> store s=
tack-allocated objects. So if you want to create a `unique_ptr&lt;array&lt;=
&gt;&gt;`, you're going to have to heap allocate that `array`.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2723_1351331.1370252947521--

.

------=_Part_300_14483603.1370257547251
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. j=FAnius 3., h=E9tf=F5 11:49:07 UTC+2 id=F5pontban Nicol Bolas a k=F6=
vetkez=F5t=20
=EDrta:
>
> On Sunday, June 2, 2013 4:32:14 PM UTC-7, R=F3bert D=E1vid wrote:
>>
>>
>>> The second one is terrible, because when a particular system will=20
>>> prevent stack allocation is implementation-dependent. Some systems migh=
t=20
>>> allow you to stack allocate a 30,000 integers; some might not. You woul=
d=20
>>> have to have two different code-paths for every use of dynarray: one fo=
r if=20
>>> it works, and one for if it doesn't.
>>>
>>>
>> I'm not sure it is actually that terrible how it sounds to you - it's th=
e=20
>> same thing when you want to have a std::array<int, 30000> - some systems=
=20
>> might allow you to do that, some might not, and you will have two differ=
ent=20
>> code-paths..
>>
>
> There's a really big difference here. If it won't let me do=20
> `std::array<int, 30000>`, the *compiler* will tell me. I will know before=
=20
> my application *ships*. Therefore, I will not need different code-paths;=
=20
> I will simply change my code for the lowest-common-denominator compiler.
>

No it doesn't. I just tested it on MSVC11.3 and ICC 2013.3 on Windows 8 and=
=20
GCC 4.6.1 and on Ubuntu 11.10. None of them told me this is bad, all dies=
=20
only at runtime:
#include <array>
int main()
{
  std::array<int, 100*1000*1000> a;
  return 0;
}
=20

For me, dynarray<int> arr(n); is to int arr[n]; what array<int, 10> arr; is=
=20
>> to int arr[10];
>>
>
> Well, there's your problem: that's *not* what dynarray is for. It's wrong=
=20
> to blame a class for not doing something that it's *not trying to do*.=20
> Rather than trying to convert a class into being what you think it ought =
to=20
> be, you should be asking for a class that has the particular features you=
=20
> want it to have.
>

I beg your pardon, are you saying I cannot use dynarray<int> arr(n) instead=
=20
of int arr[n], unlike how I can use array<int, 10> instead of int[10]??=20
What is the point of dynarray then?
=20

>
> Moving on, the case of runtime-const-size stack-allocated container is a=
=20
>> different beast, dynarray should not try to solve it by its own, but=20
>> unique_ptr<dynarray<T>> is what one needs in this case; the same way how=
=20
>> unique_ptr<array<T, n>> works for a compile-time-size stack allocated=20
>> arrays.
>>
>
> No it does not. `unqiue_ptr<array<>>` does not allocate *anything* on the=
=20
> stack. `array<>` is only allocated on the stack if it is allocated *on=20
> the stack*, and `unique_ptr` *cannot* store stack-allocated objects. So=
=20
> if you want to create a `unique_ptr<array<>>`, you're going to have to he=
ap=20
> allocate that `array`.
>

Oh my god, sorry, this is a big time mistype, I should not write these=20
mails at 1:30 am.. I meant a heap allocated container. Heap heap heap.

Regards, Robert

--=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/?hl=3Den.



------=_Part_300_14483603.1370257547251
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. j=FAnius 3., h=E9tf=F5 11:49:07 UTC+2 id=F5pontban Nicol Bola=
s a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On S=
unday, June 2, 2013 4:32:14 PM UTC-7, R=F3bert D=E1vid wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>=
The second one is terrible, because when a particular system will prevent s=
tack allocation is implementation-dependent. Some systems might allow you t=
o stack allocate a 30,000 integers; some might not. You would have to have =
two different code-paths for every use of dynarray: one for if it works, an=
d one for if it doesn't.<br><br></div></blockquote><div><br>I'm not sure it=
 is actually that terrible how it sounds to you - it's the same thing when =
you want to have a std::array&lt;int, 30000&gt; - some systems might allow =
you to do that, some might not, and you will have two different code-paths.=
..<br></div></blockquote><div><br>There's a really big difference here. If i=
t won't let me do `std::array&lt;int, 30000&gt;`, the <i>compiler</i> will =
tell me. I will know before my application <i>ships</i>. Therefore, I will =
not need different code-paths; I will simply change my code for the lowest-=
common-denominator compiler.</div></blockquote><div><br>No it doesn't. I ju=
st tested it on MSVC11.3 and ICC=20
2013.3 on Windows 8 and GCC 4.6.1 and on Ubuntu 11.10. None of them told me=
 this is=20
bad, all dies only at runtime:<br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&lt;array&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> main</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">array</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">100</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1000=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">1000</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
/div></code></div>&nbsp;<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div>For me, dynarray&lt;in=
t&gt; arr(n); is to int arr[n]; what array&lt;int, 10&gt; arr; is to int ar=
r[10];</div></blockquote><div><br>Well, there's your problem: that's <i>not=
</i> what dynarray is for. It's wrong to blame a class for not doing someth=
ing that it's <i>not trying to do</i>. Rather than trying to convert a clas=
s into being what you think it ought to be, you should be asking for a clas=
s that has the particular features you want it to have.<br></div></blockquo=
te><div><br>I beg your pardon, are you saying I cannot use dynarray&lt;int&=
gt; arr(n) instead of int arr[n], unlike how I can use array&lt;int, 10&gt;=
 instead of int[10]?? What is the point of dynarray then?<br>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div>Moving on, the case of runtime-const-size stack=
-allocated container is a different beast, dynarray should not try to solve=
 it by its own, but unique_ptr&lt;dynarray&lt;T&gt;&gt; is what one needs i=
n this case; the same way how unique_ptr&lt;array&lt;T, n&gt;&gt; works for=
 a compile-time-size stack allocated arrays.</div></blockquote><div><br>No =
it does not. `unqiue_ptr&lt;array&lt;&gt;&gt;` does not allocate <i>anythin=
g</i> on the stack. `array&lt;&gt;` is only allocated on the stack if it is=
 allocated <i>on the stack</i>, and `unique_ptr` <i>cannot</i> store stack-=
allocated objects. So if you want to create a `unique_ptr&lt;array&lt;&gt;&=
gt;`, you're going to have to heap allocate that `array`.<br></div></blockq=
uote><div><br>Oh my god, sorry, this is a big time mistype, I should not wr=
ite these mails at 1:30 am.. I meant a heap allocated container. Heap heap =
heap.<br><br>Regards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_300_14483603.1370257547251--

.

2013/6/3 R=F3bert D=E1vid <lrdxgm@gmail.com>:
>
> No it doesn't. I just tested it on MSVC11.3 and ICC 2013.3 on Windows 8 a=
nd
> GCC 4.6.1 and on Ubuntu 11.10. None of them told me this is bad, all dies
> only at runtime:
> #include <array>
> int main()
> {
>   std::array<int, 100*1000*1000> a;
>   return 0;
> }

That's correct, there is no requirement that this is diagnosed during
compile/link time.

- 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/?hl=3Den.



.

------=_Part_40_9404663.1370265556183
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Monday, June 3, 2013 4:05:47 AM UTC-7, R=F3bert D=E1vid wrote:
>
> 2013. j=FAnius 3., h=E9tf=F5 11:49:07 UTC+2 id=F5pontban Nicol Bolas a k=
=F6vetkez=F5t=20
> =EDrta:
>>
>> On Sunday, June 2, 2013 4:32:14 PM UTC-7, R=F3bert D=E1vid wrote:
>>>
>>>
>>>> The second one is terrible, because when a particular system will=20
>>>> prevent stack allocation is implementation-dependent. Some systems mig=
ht=20
>>>> allow you to stack allocate a 30,000 integers; some might not. You wou=
ld=20
>>>> have to have two different code-paths for every use of dynarray: one f=
or if=20
>>>> it works, and one for if it doesn't.
>>>>
>>>>
>>> I'm not sure it is actually that terrible how it sounds to you - it's=
=20
>>> the same thing when you want to have a std::array<int, 30000> - some=20
>>> systems might allow you to do that, some might not, and you will have t=
wo=20
>>> different code-paths..
>>>
>>
>> There's a really big difference here. If it won't let me do=20
>> `std::array<int, 30000>`, the *compiler* will tell me. I will know=20
>> before my application *ships*. Therefore, I will not need different=20
>> code-paths; I will simply change my code for the lowest-common-denominat=
or=20
>> compiler.
>>
>
> No it doesn't. I just tested it on MSVC11.3 and ICC 2013.3 on Windows 8=
=20
> and GCC 4.6.1 and on Ubuntu 11.10. None of them told me this is bad, all=
=20
> dies only at runtime:
> #include <array>
> int main()
> {
>   std::array<int, 100*1000*1000> a;
>   return 0;
> }
> =20
>

Fair enough.
=20

> For me, dynarray<int> arr(n); is to int arr[n]; what array<int, 10> arr;=
=20
>>> is to int arr[10];
>>>
>>
>> Well, there's your problem: that's *not* what dynarray is for. It's=20
>> wrong to blame a class for not doing something that it's *not trying to=
=20
>> do*. Rather than trying to convert a class into being what you think it=
=20
>> ought to be, you should be asking for a class that has the particular=20
>> features you want it to have.
>>
>
> I beg your pardon, are you saying I cannot use dynarray<int> arr(n)=20
> instead of int arr[n], unlike how I can use array<int, 10> instead of=20
> int[10]?? What is the point of dynarray then?
>

The point of `dynarray` is to be a runtime-fixed-size allocated array of=20
values, which can be allocated on the stack or heap. That this might let=20
you replace any particular use of `int arr[n]` with `dynarray<int> arr(n)`=
=20
is a side issue, and any deficiencies in that regard should not necessarily=
=20
count against it (unless they are unnecessary deficiencies). The main=20
purpose of the class is to be able to have it select stack vs. heap=20
allocation based on non-local factors.

If anything, `dynarray` is for when you *can't* use `int[n]`, such as in=20
struct definitions and such. That it also happens to work when you could=20
use it is a nice bonus, not the reason for its existence.

Moving on, the case of runtime-const-size stack-allocated container is a=20
>>> different beast, dynarray should not try to solve it by its own, but=20
>>> unique_ptr<dynarray<T>> is what one needs in this case; the same way ho=
w=20
>>> unique_ptr<array<T, n>> works for a compile-time-size stack allocated=
=20
>>> arrays.
>>>
>>
>> No it does not. `unqiue_ptr<array<>>` does not allocate *anything* on=20
>> the stack. `array<>` is only allocated on the stack if it is allocated *=
on=20
>> the stack*, and `unique_ptr` *cannot* store stack-allocated objects. So=
=20
>> if you want to create a `unique_ptr<array<>>`, you're going to have to h=
eap=20
>> allocate that `array`.
>>
>
> Oh my god, sorry, this is a big time mistype, I should not write these=20
> mails at 1:30 am.. I meant a heap allocated container. Heap heap heap.
>

OK, so std::vector. We already have that; just don't resize it. Admittedly,=
=20
it would be nice to have a vector-like container that would not allow=20
resizing. But it would just be std::vector without certain members.

--=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/?hl=3Den.



------=_Part_40_9404663.1370265556183
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, June 3, 2013 4:05:47 AM UTC-7, R=F3bert D=E1vid wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">2013. j=FAnius 3., h=E9tf=F5 11:=
49:07 UTC+2 id=F5pontban Nicol Bolas a k=F6vetkez=F5t =EDrta:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">On Sunday, June 2, 2013 4:32:14 PM UTC-7, R=F3ber=
t D=E1vid wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div><br>The second one is terrible, because when a =
particular system will prevent stack allocation is implementation-dependent=
.. Some systems might allow you to stack allocate a 30,000 integers; some mi=
ght not. You would have to have two different code-paths for every use of d=
ynarray: one for if it works, and one for if it doesn't.<br><br></div></blo=
ckquote><div><br>I'm not sure it is actually that terrible how it sounds to=
 you - it's the same thing when you want to have a std::array&lt;int, 30000=
&gt; - some systems might allow you to do that, some might not, and you wil=
l have two different code-paths..<br></div></blockquote><div><br>There's a =
really big difference here. If it won't let me do `std::array&lt;int, 30000=
&gt;`, the <i>compiler</i> will tell me. I will know before my application =
<i>ships</i>. Therefore, I will not need different code-paths; I will simpl=
y change my code for the lowest-common-denominator compiler.</div></blockqu=
ote><div><br>No it doesn't. I just tested it on MSVC11.3 and ICC=20
2013.3 on Windows 8 and GCC 4.6.1 and on Ubuntu 11.10. None of them told me=
 this is=20
bad, all dies only at runtime:<br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word"><code><div><span style=3D"color:#800">#include</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#080">&lt;array&gt;</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">int</=
span><span style=3D"color:#000"> main</span><span style=3D"color:#660">()</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>&nbsp; std</span><span style=3D"color:#66=
0">::</span><span style=3D"color:#000">array</span><span style=3D"color:#66=
0">&lt;</span><span style=3D"color:#008">int</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> </span><span style=3D"color:#066">10=
0</span><span style=3D"color:#660">*</span><span style=3D"color:#066">1000<=
/span><span style=3D"color:#660">*</span><span style=3D"color:#066">1000</s=
pan><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> a</sp=
an><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp;=
 </span><span style=3D"color:#008">return</span><span style=3D"color:#000">=
 </span><span style=3D"color:#066">0</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span=
></div></code></div>&nbsp;<br></div></blockquote><div><br>Fair enough.<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></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v>For me, dynarray&lt;int&gt; arr(n); is to int arr[n]; what array&lt;int, =
10&gt; arr; is to int arr[10];</div></blockquote><div><br>Well, there's you=
r problem: that's <i>not</i> what dynarray is for. It's wrong to blame a cl=
ass for not doing something that it's <i>not trying to do</i>. Rather than =
trying to convert a class into being what you think it ought to be, you sho=
uld be asking for a class that has the particular features you want it to h=
ave.<br></div></blockquote><div><br>I beg your pardon, are you saying I can=
not use dynarray&lt;int&gt; arr(n) instead of int arr[n], unlike how I can =
use array&lt;int, 10&gt; instead of int[10]?? What is the point of dynarray=
 then?</div></blockquote><div><br>The point of `dynarray` is to be a runtim=
e-fixed-size allocated array of values, which can be allocated on the stack=
 or heap. That this might let you replace any particular use of `int arr[n]=
` with `dynarray&lt;int&gt; arr(n)` is a side issue, and any deficiencies i=
n that regard should not necessarily count against it (unless they are unne=
cessary deficiencies). The main purpose of the class is to be able to have =
it select stack vs. heap allocation based on non-local factors.<br><br>If a=
nything, `dynarray` is for when you <i>can't</i> use `int[n]`, such as in s=
truct definitions and such. That it also happens to work when you could use=
 it is a nice bonus, not the reason for its existence.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Moving on, the c=
ase of runtime-const-size stack-allocated container is a different beast, d=
ynarray should not try to solve it by its own, but unique_ptr&lt;dynarray&l=
t;T&gt;&gt; is what one needs in this case; the same way how unique_ptr&lt;=
array&lt;T, n&gt;&gt; works for a compile-time-size stack allocated arrays.=
</div></blockquote><div><br>No it does not. `unqiue_ptr&lt;array&lt;&gt;&gt=
;` does not allocate <i>anything</i> on the stack. `array&lt;&gt;` is only =
allocated on the stack if it is allocated <i>on the stack</i>, and `unique_=
ptr` <i>cannot</i> store stack-allocated objects. So if you want to create =
a `unique_ptr&lt;array&lt;&gt;&gt;`, you're going to have to heap allocate =
that `array`.<br></div></blockquote><div><br>Oh my god, sorry, this is a bi=
g time mistype, I should not write these mails at 1:30 am.. I meant a heap =
allocated container. Heap heap heap.<br></div></blockquote><div><br>OK, so =
std::vector. We already have that; just don't resize it. Admittedly, it wou=
ld be nice to have a vector-like container that would not allow resizing. B=
ut it would just be std::vector without certain members.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_40_9404663.1370265556183--

.

------=_Part_2588_32784521.1370268864891
Content-Type: text/plain; charset=ISO-8859-1



> The main purpose of the class is to be able to have it select stack vs.
> heap allocation based on non-local factors.
>

Alright. So it is not an std::array, that has dynamic size? Why is it
called dynarray then?

It feels like this class wants to do way too much - I don't have a tool
that always allocates data on stack, if I wanted to take responsibility for
that. (Of course the new C-style dynamic array is one - but that doesn't
have begin()/end(), so cannot use stl algorithms on it, not possible for a
library to check for out of range indexing, etc.) If there is a need to
have a standard library tool for automatic stack vs. heap selection, then
there should be a class to do this selection (what dynarray is now),
wrapping / building on std::dynamic_stack_array and/or std::vector (or
std::dynamic_heap_array)

Regards, Robert

--

---
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/?hl=en.



------=_Part_2588_32784521.1370268864891
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>The main purpose of t=
he class is to be able to have it select stack vs. heap allocation based on=
 non-local factors.<br></div></blockquote><div><br>Alright. So it is not an=
 std::array, that has dynamic size? Why is it called dynarray then?<br><br>=
It feels like this class wants to do way too much - I don't have a tool tha=
t always allocates data on stack, if I wanted to take responsibility for th=
at. (Of course the new C-style dynamic array is one - but that doesn't have=
 begin()/end(), so cannot use stl algorithms on it, not possible for a libr=
ary to check for out of range indexing, etc.) If there is a need to have a =
standard library tool for automatic stack vs. heap selection, then there sh=
ould be a class to do this selection (what dynarray is now), wrapping / bui=
lding on std::dynamic_stack_array and/or std::vector (or std::dynamic_heap_=
array)<br><br>Regards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2588_32784521.1370268864891--

.

2013/6/3 R=F3bert D=E1vid <lrdxgm@gmail.com>:
>
> Alright. So it is not an std::array, that has dynamic size? Why is it cal=
led
> dynarray then?

The "dyn" standards for "dynamically allocated", not for resizable.
There was quite amount of discussion of the naming choice, but in the
end "dynarray" won.

> It feels like this class wants to do way too much - I don't have a tool t=
hat
> always allocates data on stack, if I wanted to take responsibility for th=
at.

I'm not sure what you are trying to express here.

- 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/?hl=3Den.



.

------=_Part_296_21819481.1370289699436
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. j=FAnius 3., h=E9tf=F5 16:23:11 UTC+2 id=F5pontban Daniel Kr=FCgler a=
=20
k=F6vetkez=F5t =EDrta:
>
> 2013/6/3 R=F3bert D=E1vid <lrd...@gmail.com <javascript:>>:=20
> >=20
> > Alright. So it is not an std::array, that has dynamic size? Why is it=
=20
> called=20
> > dynarray then?=20
>
> The "dyn" standards for "dynamically allocated", not for resizable.=20
> There was quite amount of discussion of the naming choice, but in the=20
> end "dynarray" won.=20
>
Noone questioned that, you are just suggesting that I should not consider=
=20
std::dynarray as an std::array that has "dynamic", aka non-compile-time=20
size.
=20

>
> > It feels like this class wants to do way too much - I don't have a tool=
=20
> that=20
> > always allocates data on stack, if I wanted to take responsibility for=
=20
> that.=20
>
> I'm not sure what you are trying to express here.=20
>

What should I use when I want a runtime-size array that is definitely stack=
=20
allocated? Is there any other option than doing it C-style?

Regards, Robert

--=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/?hl=3Den.



------=_Part_296_21819481.1370289699436
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. j=FAnius 3., h=E9tf=F5 16:23:11 UTC+2 id=F5pontban Daniel Kr=
=FCgler a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">2013/6/3 R=F3bert D=E1vid &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"gIMNNpyICN8J">lrd...@gmail.com</a>&gt;:
<br>&gt;
<br>&gt; Alright. So it is not an std::array, that has dynamic size? Why is=
 it called
<br>&gt; dynarray then?
<br>
<br>The "dyn" standards for "dynamically allocated", not for resizable.
<br>There was quite amount of discussion of the naming choice, but in the
<br>end "dynarray" won.
<br></blockquote><div>Noone questioned that, you are just suggesting that I=
 should not consider std::dynarray as an std::array that has "dynamic", aka=
 non-compile-time size.<br>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">
<br>&gt; It feels like this class wants to do way too much - I don't have a=
 tool that
<br>&gt; always allocates data on stack, if I wanted to take responsibility=
 for that.
<br>
<br>I'm not sure what you are trying to express here.
<br></blockquote><div><br>What should I use when I want a runtime-size arra=
y that is definitely stack allocated? Is there any other option than doing =
it C-style?<br><br>Regards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_296_21819481.1370289699436--

.

2013/6/3 R=F3bert D=E1vid <lrdxgm@gmail.com>:
>
> 2013. j=FAnius 3., h=E9tf=F5 16:23:11 UTC+2 id=F5pontban Daniel Kr=FCgler=
 a k=F6vetkez=F5t
> =EDrta:
>>
>> 2013/6/3 R=F3bert D=E1vid <lrd...@gmail.com>:
>> >
>> > Alright. So it is not an std::array, that has dynamic size? Why is it
>> > called
>> > dynarray then?
>>
>> The "dyn" standards for "dynamically allocated", not for resizable.
>> There was quite amount of discussion of the naming choice, but in the
>> end "dynarray" won.
>
> Noone questioned that, you are just suggesting that I should not consider
> std::dynarray as an std::array that has "dynamic", aka non-compile-time
> size.

I'm not suggesting anything, I was just trying to respond to your question.

>> > It feels like this class wants to do way too much - I don't have a too=
l
>> > that
>> > always allocates data on stack, if I wanted to take responsibility for
>> > that.
>>
>> I'm not sure what you are trying to express here.
>
> What should I use when I want a runtime-size array that is definitely sta=
ck
> allocated? Is there any other option than doing it C-style?

You should be aware, that there is no guarantee that a array with
runtime-bound will allocate from the stack (8.3.4 p4):

"If the size of the array exceeds the size of the memory available for
objects with automatic storage duration,
the behavior is undefined. It is unspecified whether a global
allocation function (3.7.4) is invoked to
obtain storage for the array."

Of-course, implementations usually *will* allocate from the stack. The
same idea exists for std::dynarray except that it guarantees to allow
you to create also objects of this type with storage durations
different from automatic ones (in which case stack allocation won't be
possible). Still, it will be q.o.i whether an implementation allocates
memory from the stack for either runtime-bound arrays or std::dynarray
objects.

- 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/?hl=3Den.



.

------=_Part_135_28723811.1370339120372
Content-Type: text/plain; charset=ISO-8859-1



>
> You should be aware, that there is no guarantee that a array with
> runtime-bound will allocate from the stack (8.3.4 p4):
>
> "If the size of the array exceeds the size of the memory available for
> objects with automatic storage duration,
> the behavior is undefined. It is unspecified whether a global
> allocation function (3.7.4) is invoked to
> obtain storage for the array."
>

That says, allocate from the stack (rather, 'automatic storage', as there
is no concept of stack in the standard), or UD. There is nothing about
possibility of allocating on heap instead (ok, technically UD covers it,
but it is also allows it to launch nuclear missiles). It does guarantee to
allocate on stack when there is enough memory.

Regards, Robert

--

---
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/?hl=en.



------=_Part_135_28723811.1370339120372
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>You should be aware, that there is no guarantee that a array with
<br>runtime-bound will allocate from the stack (8.3.4 p4):
<br>
<br>"If the size of the array exceeds the size of the memory available for
<br>objects with automatic storage duration,
<br>the behavior is undefined. It is unspecified whether a global
<br>allocation function (3.7.4) is invoked to
<br>obtain storage for the array."
<br></blockquote><div><br>That says, allocate from the stack (rather, 'auto=
matic storage', as there is no concept of stack in the standard), or UD. Th=
ere is nothing about possibility of allocating on heap instead (ok, technic=
ally UD covers it, but it is also allows it to launch nuclear missiles). It=
 does guarantee to allocate on stack when there is enough memory.<br><br>Re=
gards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_135_28723811.1370339120372--

.

2013/6/4 R=F3bert D=E1vid <lrdxgm@gmail.com>:
>
>>
>> You should be aware, that there is no guarantee that a array with
>> runtime-bound will allocate from the stack (8.3.4 p4):
>>
>> "If the size of the array exceeds the size of the memory available for
>> objects with automatic storage duration,
>> the behavior is undefined. It is unspecified whether a global
>> allocation function (3.7.4) is invoked to
>> obtain storage for the array."
>
> That says, allocate from the stack (rather, 'automatic storage', as there=
 is
> no concept of stack in the standard), or UD. There is nothing about
> possibility of allocating on heap instead (ok, technically UD covers it, =
but
> it is also allows it to launch nuclear missiles). It does guarantee to
> allocate on stack when there is enough memory.

It doesn't, please read the wording a second time. The wording just
says that it is unspecified whether a global allocation function will
be used, which grants an implementation the freedom to use operator
new to get the memory for the runtime array.  In particular the
wording does *not* say, which conditions are the right ones to call
operator new. It could be each time.

- 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/?hl=3Den.



.

------=_Part_3712_13186950.1370339935745
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 4, 2013 2:45:20 AM UTC-7, R=F3bert D=E1vid wrote:
>
>
>
>> You should be aware, that there is no guarantee that a array with=20
>> runtime-bound will allocate from the stack (8.3.4 p4):=20
>>
>> "If the size of the array exceeds the size of the memory available for=
=20
>> objects with automatic storage duration,=20
>> the behavior is undefined. It is unspecified whether a global=20
>> allocation function (3.7.4) is invoked to=20
>> obtain storage for the array."=20
>>
>
> That says, allocate from the stack (rather, 'automatic storage', as there=
=20
> is no concept of stack in the standard), or UD. There is nothing about=20
> possibility of allocating on heap instead (ok, technically UD covers it,=
=20
> but it is also allows it to launch nuclear missiles). It does guarantee t=
o=20
> allocate on stack when there is enough memory.
>

No it doesn't. It specifically allows for the possibility of using "a=20
global allocation function" *regardless* of the size of the allocation.=20
Yes, that is "unspecified" (meaning that it is *allowed*), but it doesn't=
=20
require exceeding a memory threshold to invoke it. It doesn't say "if you=
=20
exceed the memory limits, a global allocation function can be used." It=20
simply says "a global allocation function can be used."

So stack allocation is certainly *not* guaranteed, regardless of whether=20
there is enough memory or not.

--=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/?hl=3Den.



------=_Part_3712_13186950.1370339935745
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 4, 2013 2:45:20 AM UTC-7, R=F3bert D=E1vid wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<br>You should be aware, that there is no guarantee that a array with
<br>runtime-bound will allocate from the stack (8.3.4 p4):
<br>
<br>"If the size of the array exceeds the size of the memory available for
<br>objects with automatic storage duration,
<br>the behavior is undefined. It is unspecified whether a global
<br>allocation function (3.7.4) is invoked to
<br>obtain storage for the array."
<br></blockquote><div><br>That says, allocate from the stack (rather, 'auto=
matic storage', as there is no concept of stack in the standard), or UD. Th=
ere is nothing about possibility of allocating on heap instead (ok, technic=
ally UD covers it, but it is also allows it to launch nuclear missiles). It=
 does guarantee to allocate on stack when there is enough memory.<br></div>=
</blockquote><div><br>No it doesn't. It specifically allows for the possibi=
lity of using "a global allocation function" <i>regardless</i> of the size =
of the allocation. Yes, that is "unspecified" (meaning that it is <i>allowe=
d</i>), but it doesn't require exceeding a memory threshold to invoke it. I=
t doesn't say "if you exceed the memory limits, a global allocation functio=
n can be used." It simply says "a global allocation function can be used."<=
br><br>So stack allocation is certainly <i>not</i> guaranteed, regardless o=
f whether there is enough memory or not.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3712_13186950.1370339935745--

.

------=_Part_421_8317624.1370363814826
Content-Type: text/plain; charset=ISO-8859-1

What I'm curious about is the performance case. The entire justification
for all of this is based on the performance benefits of stack allocation,
but I'm curious as to how rigorously these benefits were checked and what
evidence was submitted to show that the performance of stack allocation was
so desirable.

--

---
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/?hl=en.



------=_Part_421_8317624.1370363814826
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

What I'm curious about is the performance case. The entire justification fo=
r all of this is based on the performance benefits of stack allocation, but=
 I'm curious as to how rigorously these benefits were checked and what evid=
ence was submitted to show that the performance of stack allocation was so =
desirable.

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_421_8317624.1370363814826--

.

------=_Part_4041_5053627.1370370038351
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, June 4, 2013 9:36:54 AM UTC-7, DeadMG wrote:
>
> What I'm curious about is the performance case. The entire justification
> for all of this is based on the performance benefits of stack allocation,
> but I'm curious as to how rigorously these benefits were checked and what
> evidence was submitted to show that the performance of stack allocation was
> so desirable.


Since the cost of stack allocation is essentially just the cost of moving
the stack pointer, it's pretty hard for heap allocation to beat that. How
much that cost actually matters depends on a great many factors. But
really, just put a five-element std::vector<int> in a tight loop that does
nothing but re-initialize the 5 elements every frame, and compare it to the
performance of a std::array<int, 5>. People uses std::array for these same
benefits for compile-time sizes; it's simply a matter of wanting those
benefits for runtime sizes.

--

---
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/?hl=en.



------=_Part_4041_5053627.1370370038351
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 4, 2013 9:36:54 AM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">What I'm curious about is the performance case.=
 The entire justification for all of this is based on the performance benef=
its of stack allocation, but I'm curious as to how rigorously these benefit=
s were checked and what evidence was submitted to show that the performance=
 of stack allocation was so desirable.</blockquote><div><br>Since the cost =
of stack allocation is essentially just the cost of moving the stack pointe=
r, it's pretty hard for heap allocation to beat that. How much that cost ac=
tually matters depends on a great many factors. But really, just put a five=
-element std::vector&lt;int&gt; in a tight loop that does nothing but re-in=
itialize the 5 elements every frame, and compare it to the performance of a=
 std::array&lt;int, 5&gt;. People uses std::array for these same benefits f=
or compile-time sizes; it's simply a matter of wanting those benefits for r=
untime sizes.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4041_5053627.1370370038351--

.

------=_Part_509_8427271.1370372262256
Content-Type: text/plain; charset=ISO-8859-1

That's not really the same thing. The vector uses the most general-purpose
heap allocator possible. You can get much, much tighter timings with a more
specific allocator.

Also, I checked the implementation of alloca in Visual Studio, and it's a
lot more expensive than you'd think- something about stack pointer
alignment and checking and stuff. I had plenty of success getting
competitive performance with a choice heap allocator- as in, within the
inaccuracies of the test, they were the same speed.

--

---
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/?hl=en.



------=_Part_509_8427271.1370372262256
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

That's not really the same thing. The vector uses the most general-purpose =
heap allocator possible. You can get much, much tighter timings with a more=
 specific allocator.<div><br></div><div>Also, I checked the implementation =
of alloca in Visual Studio, and it's a lot more expensive than you'd think-=
 something about stack pointer alignment and checking and stuff. I had plen=
ty of success getting competitive performance with a choice heap allocator-=
 as in, within the inaccuracies of the test, they were the same speed.</div=
>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_509_8427271.1370372262256--

.

On Tue, Apr 2, 2013 at 9:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I do have some concerns about this though. One is purely functional and
> easily resolved: `dynarray` should have a constructor that can use
> default-initialization of its array elements instead of
> value-initialization.

Agreed.  I think it's OK for dynarray and make_unique share
a `default_initialize` tag.

> But this should be true of all standard library
> containers and warrants a full proposal.

Some of the containers are node-based.  std::vector has
`.reserve()`, which is even better.

> Another is the lack of allocator
> support when not using stack memory; again, relatively easily resolved.

?? dynarray has allocator-aware constructors.  See:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3662.html

and N3690.

> The main issue is this:
>
> dynarray<Type> GetArray(int size)
> {
>   dynarray<Type> arr(size);
>   //Fill in arr with stuff.
>   return arr;
> }
>
> unique_ptr<dynarray<Type>> arrPtr = new dynarray<Type>(GetArray(12));

dynarray's move is O(n), as well as std::array.

> It should be the user's choice to use `dynarray` as a fixed-size `vector`,
> with all of the move characteristics of that class.

.... It's not the purpose of dynarray.  But it might be useful...

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

On 6/4/13, DeadMG <wolfeinstein@gmail.com> wrote:
> That's not really the same thing. The vector uses the most
> general-purpose heap allocator possible. You can get much, much
> tighter timings with a more specific allocator.
>
> Also, I checked the implementation of alloca in Visual Studio, and
> it's a lot more expensive than you'd think- something about stack
> pointer alignment and checking and stuff. I had plenty of success
> getting competitive performance with a choice heap allocator- as
> in, within the inaccuracies of the test, they were the same speed.

Calling alloca is a not what the compiler should do.  It should
modify the stack pointer directly.

--
Lawrence Crowl

--

---
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/?hl=en.



.

------=_Part_3745_22419293.1370398837953
Content-Type: text/plain; charset=ISO-8859-1

It would have to perform essentially the same work. alloca is basically a
language primitive anyway that's just named like a function.

--

---
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/?hl=en.



------=_Part_3745_22419293.1370398837953
Content-Type: text/html; charset=ISO-8859-1

It would have to perform essentially the same work. alloca is basically a language primitive anyway that's just named like a function.

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3745_22419293.1370398837953--

.

On 6/4/13, Zhihao Yuan <lichray@gmail.com> wrote:
> On Tue, Apr 2, 2013 at 9:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> I do have some concerns about this though. One is purely functional and
>> easily resolved: `dynarray` should have a constructor that can use
>> default-initialization of its array elements instead of
>> value-initialization.
>
> Agreed.  I think it's OK for dynarray and make_unique share
> a `default_initialize` tag.
>
>> But this should be true of all standard library
>> containers and warrants a full proposal.
>
> Some of the containers are node-based.  std::vector has
> `.reserve()`, which is even better.
>
>> Another is the lack of allocator
>> support when not using stack memory; again, relatively easily resolved.
>
> ?? dynarray has allocator-aware constructors.  See:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3662.html
>
> and N3690.

There was some debate over whether the allocator should apply to
the storage block (when not allocated on the stack) and the elements
or just the elements alone.

>
>> The main issue is this:
>>
>> dynarray<Type> GetArray(int size)
>> {
>>   dynarray<Type> arr(size);
>>   //Fill in arr with stuff.
>>   return arr;
>> }
>>
>> unique_ptr<dynarray<Type>> arrPtr = new dynarray<Type>(GetArray(12));
>
> dynarray's move is O(n), as well as std::array.
>
>> It should be the user's choice to use `dynarray` as a fixed-size
>> `vector`,
>> with all of the move characteristics of that class.
>
> ... It's not the purpose of dynarray.  But it might be useful...
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> 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/?hl=en.
>
>
>


--
Lawrence Crowl

--

---
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/?hl=en.



.

On 6/4/13, DeadMG <wolfeinstein@gmail.com> wrote:
> It would have to perform essentially the same work. alloca is basically a
> language primitive anyway that's just named like a function.

The compiler knows more, and can avoid checks and return-pointer
futzing that might happen in alloca.  Of course, one can inline and then
the analysis gets murky.

--
Lawrence Crowl

--

---
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/?hl=en.



.

------=_Part_3705_28195378.1370399899206
Content-Type: text/plain; charset=ISO-8859-1

How could alloca possibly operate if it wasn't inlined? The stack pointer
would simply be adjusted right back when the function returns.

But in a more general case, what I'm saying is, a comparison to alloca is
pretty much all we've got since there is no implementation for dynarray
right now. And it's not very compelling to hear that it should be faster
than a naive std::vector, because that's not what dynarray is competing
against. It's competing against a bunch of specialized allocators which
offer very similar allocation semantics and speed to alloca, but don't have
most or all of the horrible pitfalls.

For a feature whose inclusion brings a bunch of pitfalls by it's very
nature, and whose inclusion is justified exclusively by performance, I find
it extremely odd that (as far as I can tell) there are no benchmarks, no
discussion of real implementations, no comparison to alternatives (actual
alternatives, not global operator new, but a specialized allocator), no
anything. I got ripped for this stuff with N3575 and rightly so. I read the
paper and was present in Bristol for that meeting.

--

---
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/?hl=en.



------=_Part_3705_28195378.1370399899206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

How could alloca possibly operate if it wasn't inlined? The stack pointer w=
ould simply be adjusted right back when the function returns.<div><br><div>=
But in a more general case, what I'm saying is, a comparison to alloca is p=
retty much all we've got since there is no implementation for dynarray righ=
t now. And it's not very compelling to hear that it should be faster than a=
 naive std::vector, because that's not what dynarray is competing against. =
It's competing against a bunch of specialized allocators which offer very s=
imilar allocation semantics and speed to alloca, but don't have most or all=
 of the horrible pitfalls.</div><div><br></div><div>For a feature whose inc=
lusion brings a bunch of pitfalls by it's very nature, and whose inclusion =
is justified exclusively by performance, I find it extremely odd that (as f=
ar as I can tell) there are no benchmarks, no discussion of real implementa=
tions, no comparison to alternatives (actual alternatives, not global opera=
tor new, but a specialized allocator), no anything. I got ripped for this s=
tuff with N3575 and rightly so. I read the paper and was present in Bristol=
 for that meeting.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3705_28195378.1370399899206--

.

On 05/06/13 03:38, DeadMG wrote:
> How could alloca possibly operate if it wasn't inlined? The stack
> pointer would simply be adjusted right back when the function returns.
>
> But in a more general case, what I'm saying is, a comparison to alloca
> is pretty much all we've got since there is no implementation for
> dynarray right now. And it's not very compelling to hear that it
> should be faster than a naive std::vector, because that's not what
> dynarray is competing against. It's competing against a bunch of
> specialized allocators which offer very similar allocation semantics
> and speed to alloca, but don't have most or all of the horrible pitfalls

Competing against std::vector is exactly what I feel dynarray should be
competing against. I can certainly produce code, if you want it, where
variable-sized arrays in gcc massively outperform std::vector.

Where are these 'bunch of specialized allocators'?  Making a comparision
against some nebulus "super-optimised code" is not useful. Comparing
against specialized allocators is not a fair comparision in my opinion,
unless you also intend to bring those up for standardisation.

Chris

--

---
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/?hl=en.



.

------=_Part_4713_13100164.1370424548001
Content-Type: text/plain; charset=ISO-8859-1

Er, I did submit N3575. It's a billion miles away from ready, but I
certainly do intend to bring them up for Standardisation. Also, just
because the other options are not yet Standard does not mean that he should
not compare them, since they certainly could be included instead of
dynarray to improve memory allocation performance. Also, why not just run
the alloca code in release mode and the vector in debug mode whilst you're
at it? You can't compare "Code I optimized using Technique X" and
"Unoptimized code" to find that X is worth including over Technique Y.

What I'm saying is that if you have a feature whose inclusion is improved
performance, then you should have proof on hand that it does improve
performance against realistic competitors.

--

---
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/?hl=en.



------=_Part_4713_13100164.1370424548001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Er, I did submit N3575. It's a billion miles away from ready, but I certain=
ly do intend to bring them up for Standardisation. Also, just because the o=
ther options are not yet Standard does not mean that he should not compare =
them, since they certainly could be included instead of dynarray to improve=
 memory allocation performance. Also, why not just run the alloca code in r=
elease mode and the vector in debug mode whilst you're at it? You can't com=
pare "Code I optimized using Technique X" and "Unoptimized code" to find th=
at X is worth including over Technique Y.<div><br></div><div>What I'm sayin=
g is that if you have a feature whose inclusion is improved performance, th=
en you should have proof on hand that it does improve performance against r=
ealistic competitors.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4713_13100164.1370424548001--

.

On 05/06/13 10:29, DeadMG wrote:
> Er, I did submit N3575. It's a billion miles away from ready, but I
> certainly do intend to bring them up for Standardisation. Also, just
> because the other options are not yet Standard does not mean that he
> should not compare them, since they certainly could be included
> instead of dynarray to improve memory allocation performance. Also,
> why not just run the alloca code in release mode and the vector in
> debug mode whilst you're at it? You can't compare "Code I optimized
> using Technique X" and "Unoptimized code" to find that X is worth
> including over Technique Y.
>
> What I'm saying is that if you have a feature whose inclusion is
> improved performance, then you should have proof on hand that it does
> improve performance against realistic competitors.

I assuming this is a reply to my message.

std::vector is the standard way which I, and I think everyone else(?)
has suggested users get a block of runtime-variable size memory since
C++ began. Suggesting std::vector is equivalent to "unoptimized code" is
extremely disturbing, does this mean one of the most fundamental classes
in the standard library is not fit for purpose?

Could you please suggest an allocator which I could use as a replacement
for my use of alloca? I am happy to try such a thing, and report back on
the performance I achieve.

Chris

--

---
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/?hl=en.



.

------=_Part_6604_22289797.1370430972419
Content-Type: text/plain; charset=ISO-8859-1

It is the least optimized code, not because std::vector is slow or poorly
implemented, but because it solves a different problem. std::vector solves
the problem of "Allocate some memory, some time, with some size, then
deallocate at some time in the future". Alloca solves the problem of
"Allocate some small memory, but deallocate at a very fixed time in the
future, with a fixed ordering w.r.t. other allocations from this source.".
It is much akin to suggesting that arbitrary-precision integers are
unoptimized for operations whose values are fixed at needing less than
64bits- the more constrained version will easily cope and is much faster.
That's not to say that arbitrary-precision integers are poorly optimized,
but that you're using them in the wrong circumstances.

As for an allocator to replace alloca, I don't have the code to hand (will
look in a sec) but have a look at memory region/memory arena allocators.
They have similar constraints to alloca and operate on much the same
principle as the stack, but the memory comes from the heap. Strangely
enough, it turns out that the cost of "Just subtract from the stack
pointer" is pretty much the same as "Just subtract from the heap pointer".
Of course, there are a few niggles each way, and I'm not going to argue
that an arena is a replacement for dynamic stack allocation in every single
case, ever. But what I am saying is that it should be considered, rather
than assumed.

--

---
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/?hl=en.



------=_Part_6604_22289797.1370430972419
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It is the least optimized code, not because std::vector is slow or poorly i=
mplemented, but because it solves a different problem. std::vector solves t=
he problem of "Allocate some memory, some time, with some size, then deallo=
cate at some time in the future". Alloca solves the problem of "Allocate so=
me small memory, but deallocate at a very fixed time in the future, with a =
fixed ordering w.r.t. other allocations from this source.". It is much akin=
 to suggesting that arbitrary-precision integers are unoptimized for operat=
ions whose values are fixed at needing less than 64bits- the more constrain=
ed version will easily cope and is much faster. That's not to say that arbi=
trary-precision integers are poorly optimized, but that you're using them i=
n the wrong circumstances.<div><br></div><div>As for an allocator to replac=
e alloca, I don't have the code to hand (will look in a sec) but have a loo=
k at memory region/memory arena allocators. They have similar constraints t=
o alloca and operate on much the same principle as the stack, but the memor=
y comes from the heap. Strangely enough, it turns out that the cost of "Jus=
t subtract from the stack pointer" is pretty much the same as "Just subtrac=
t from the heap pointer". Of course, there are a few niggles each way, and =
I'm not going to argue that an arena is a replacement for dynamic stack all=
ocation in every single case, ever. But what I am saying is that it should =
be considered, rather than assumed.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6604_22289797.1370430972419--

.

On 6/4/13, DeadMG <wolfeinstein@gmail.com> wrote:
> How could alloca possibly operate if it wasn't inlined? The stack
> pointer would simply be adjusted right back when the function
> returns.

The saved stack pointer is on the stack, so you simply write a
little assembly that edits the saved value.  It does require a
suitably friendly calling convention.

> But in a more general case, what I'm saying is, a comparison
> to alloca is pretty much all we've got since there is no
> implementation for dynarray right now. And it's not very compelling
> to hear that it should be faster than a naive std::vector,
> because that's not what dynarray is competing against. It's
> competing against a bunch of specialized allocators which offer
> very similar allocation semantics and speed to alloca, but don't
> have most or all of the horrible pitfalls.

The problem is that to get the speed, you'd need an allocator with
LIFO properties.  But since vectors can be resized, it won't work
with those in general, only in specific use cases.

> For a feature whose inclusion brings a bunch of pitfalls by it's
> very nature, and whose inclusion is justified exclusively by
> performance,

Not exclusively by performance.  It also places an invariant on
the size of the array.  This invariant can be exploited to avoid
worrying that a subroutine changes the size of a vector.  Indeed,
I have code that uses dynarray for that purpose.

> I find it extremely odd that (as far as I can tell) there are no
> benchmarks, no discussion of real implementations, no comparison
> to alternatives (actual alternatives, not global operator new,
> but a specialized allocator), no anything. I got ripped for this
> stuff with N3575 and rightly so. I read the paper and was present
> in Bristol for that meeting.

I think that is partly for two reasons.  First, the technology that
goes into implementing dynarray is old.  It is a rather unsuprising
compiler optimization.  Second, it is a compiler optimization,
and that means there is a much higher bar in doing the testing than
with library changes.

--
Lawrence Crowl

--

---
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/?hl=en.



.

On 6/5/13, DeadMG <wolfeinstein@gmail.com> wrote:
> It is the least optimized code, not because std::vector is
> slow or poorly implemented, but because it solves a different
> problem. std::vector solves the problem of "Allocate some memory,
> some time, with some size, then deallocate at some time in
> the future". Alloca solves the problem of "Allocate some small
> memory, but deallocate at a very fixed time in the future, with
> a fixed ordering w.r.t. other allocations from this source.".
> It is much akin to suggesting that arbitrary-precision integers
> are unoptimized for operations whose values are fixed at needing
> less than 64bits- the more constrained version will easily cope
> and is much faster.  That's not to say that arbitrary-precision
> integers are poorly optimized, but that you're using them in the
> wrong circumstances.
>
> As for an allocator to replace alloca, I don't have the code to
> hand (will look in a sec) but have a look at memory region/memory
> arena allocators.  They have similar constraints to alloca and
> operate on much the same principle as the stack, but the memory
> comes from the heap. Strangely enough, it turns out that the
> cost of "Just subtract from the stack pointer" is pretty much
> the same as "Just subtract from the heap pointer".  Of course,
> there are a few niggles each way, and I'm not going to argue
> that an arena is a replacement for dynamic stack allocation in
> every single case, ever. But what I am saying is that it should
> be considered, rather than assumed.

It is probably fairly safe to say that most code will not use an
explicit allocator.  For that code, the performance issue remains.
If we can do something simple, we should.

Going further, using a dynarray in source gives you more confidence
in the applicability of special allocators than does vector precisely
because its size will not change.

--
Lawrence Crowl

--

---
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/?hl=en.



.

------=_Part_1077_10266923.1370645895335
Content-Type: text/plain; charset=ISO-8859-1

Op zaterdag 8 juni 2013 00:52:23 UTC+2 schreef Lawrence Crowl het volgende:

> > For a feature whose inclusion brings a bunch of pitfalls by it's
> > very nature, and whose inclusion is justified exclusively by
> > performance,
>
> Not exclusively by performance.  It also places an invariant on
> the size of the array.  This invariant can be exploited to avoid
> worrying that a subroutine changes the size of a vector.  Indeed,
> I have code that uses dynarray for that purpose.
>
>
Wouldn't (mutable) array ref / (iterator) range be a better type for such
an argument?


--

---
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/?hl=en.



------=_Part_1077_10266923.1370645895335
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op zaterdag 8 juni 2013 00:52:23 UTC+2 schreef Lawrence Crowl het volgende:=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; For a feature whose i=
nclusion brings a bunch of pitfalls by it's
<br>&gt; very nature, and whose inclusion is justified exclusively by
<br>&gt; performance,
<br>
<br>Not exclusively by performance. &nbsp;It also places an invariant on
<br>the size of the array. &nbsp;This invariant can be exploited to avoid
<br>worrying that a subroutine changes the size of a vector. &nbsp;Indeed,
<br>I have code that uses dynarray for that purpose.
<br><br></blockquote><div><br></div><div>Wouldn't (mutable) array ref / (it=
erator) range be a better type for such an argument?</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1077_10266923.1370645895335--

.

------=_Part_161_11577842.1370692338332
Content-Type: text/plain; charset=ISO-8859-1


>
> The problem is that to get the speed, you'd need an allocator with
> LIFO properties.  But since vectors can be resized, it won't work
> with those in general, only in specific use cases.


There's nothing more general about "You can't resize your dynamically-sized
container because I allocated off the LIFO allocator which is the stack"
compared to "You can't resize your dynamically-sized container because I
allocated off the LIFO allocator which is on the heap". Resizing a vector
would work, it just wouldn't work as well as not resizing it, but that's
nothing new. In fact, for some of the smaller sizes, the arena can probably
still beat new. One of the many, many ways in which "LIFO heap" is a lot
more flexible and general than alloca. Not to mention that, as Olaf says,
non-resizability is a different issue really- and we already have tools or
proposals that could be used for this, like array_ref.

I think that is partly for two reasons.  First, the technology that
> goes into implementing dynarray is old.  It is a rather unsuprising
> compiler optimization.  Second, it is a compiler optimization,
> and that means there is a much higher bar in doing the testing than
> with library changes.


If it's readily done, then why are there no sample implementations, like a
Clang fork, for example? You can't say that dynarray's performance is
incomparable to alloca, and then say you can't implement dynarray (even
though it's supposedly non-problematic to implement), and that the
performance is obviously justified.

Just for reference, I checked alloca for VS2012 again, and it is maybe
15-20 instructions or so. Some stuff I don't understand about control
registers. Not just sub esp.

--

---
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/?hl=en.



------=_Part_161_11577842.1370692338332
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">The problem is that to get the speed, you'd ne=
ed an allocator with&nbsp;<br>LIFO properties. &nbsp;But since vectors can =
be resized, it won't work&nbsp;<br>with those in general, only in specific =
use cases.&nbsp;</blockquote><div><br></div><div>There's nothing more gener=
al about "You can't resize your dynamically-sized container because I alloc=
ated off the LIFO allocator which is the stack" compared to "You can't resi=
ze your dynamically-sized container because I allocated off the LIFO alloca=
tor which is on the heap". Resizing a vector would work, it just wouldn't w=
ork as well as not resizing it, but that's nothing new. In fact, for some o=
f the smaller sizes, the arena can probably still beat new. One of the many=
, many ways in which "LIFO heap" is a lot more flexible and general than al=
loca. Not to mention that, as Olaf says, non-resizability is a different is=
sue really- and we already have tools or proposals that could be used for t=
his, like array_ref.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-col=
or: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">I thi=
nk that is partly for two reasons. &nbsp;First, the technology that&nbsp;<b=
r>goes into implementing dynarray is old. &nbsp;It is a rather unsuprising&=
nbsp;<br>compiler optimization. &nbsp;Second, it is a compiler optimization=
,&nbsp;<br>and that means there is a much higher bar in doing the testing t=
han&nbsp;<br>with library changes.&nbsp;</blockquote><div><br></div><div>If=
 it's readily done, then why are there no sample implementations, like a Cl=
ang fork, for example? You can't say that dynarray's performance is incompa=
rable to alloca, and then say you can't implement dynarray (even though it'=
s supposedly non-problematic to implement), and that the performance is obv=
iously justified.</div><div><br></div><div>Just for reference, I checked al=
loca for VS2012 again, and it is maybe 15-20 instructions or so. Some stuff=
 I don't understand about control registers. Not just sub esp.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_161_11577842.1370692338332--

.

On 6/7/13, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Op 8 juni 2013 schreef Lawrence Crowl het volgende:
> > > For a feature whose inclusion brings a bunch of pitfalls by it's
> > > very nature, and whose inclusion is justified exclusively by
> > > performance,
> >
> > Not exclusively by performance.  It also places an invariant on
> > the size of the array.  This invariant can be exploited to avoid
> > worrying that a subroutine changes the size of a vector.  Indeed,
> > I have code that uses dynarray for that purpose.
>
> Wouldn't (mutable) array ref / (iterator) range be a better type
> for such an argument?

In this case, no, because I'm allocating an array to match the size
of an existing array.  Those arrays need to have the same size for
the duration of the pairing.

It seems to me that an array_ref is still vulnerable to an underlying
vector changing size.

--
Lawrence Crowl

--

---
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/?hl=en.



.

On 6/8/13, DeadMG <wolfeinstein@gmail.com> wrote:
> > The problem is that to get the speed, you'd need an allocator with
> > LIFO properties.  But since vectors can be resized, it won't work
> > with those in general, only in specific use cases.
>
> There's nothing more general about "You can't resize your
> dynamically-sized container because I allocated off the LIFO
> allocator which is the stack" compared to "You can't resize your
> dynamically-sized container because I allocated off the LIFO
> allocator which is on the heap".

True, but the issue isn't the implementation, but the distinction
between "if you call the resize function unexpectedly the code
breaks" and "there is no resize function to call so you cannot make
that mistake".

I am not arguing that one cannot write correct code with vector
an a LIFO allocator, just that a restriction in the type makes the
intent clearer and correct code more likely.

> Resizing a vector would work, it just wouldn't work as well as
> not resizing it, but that's nothing new. In fact, for some of
> the smaller sizes, the arena can probably still beat new. One of
> the many, many ways in which "LIFO heap" is a lot more flexible
> and general than alloca. Not to mention that, as Olaf says,
> non-resizability is a different issue really - and we already have
> tools or proposals that could be used for this, like array_ref.

I do not see how taking a reference to a vector prevents the vector
from changing size.

> > I think that is partly for two reasons.  First, the technology
> > that goes into implementing dynarray is old.  It is a rather
> > unsuprising compiler optimization.  Second, it is a compiler
> > optimization, and that means there is a much higher bar in
> > doing the testing than with library changes.
>
> If it's readily done, then why are there no sample implementations,
> like a Clang fork, for example? You can't say that dynarray's
> performance is incomparable to alloca, and then say you can't
> implement dynarray (even though it's supposedly non-problematic
> to implement), and that the performance is obviously justified.

Sun's compiler had a somewhat similar feature ten years ago.
Isn't that sufficient evidence of implementability?  No one has
argued that the implementation is difficult.

> Just for reference, I checked alloca for VS2012 again, and it
> is maybe 15-20 instructions or so. Some stuff I don't understand
> about control registers. Not just sub esp.

I am not familiar with that plaform, but on other platforms
allocating from the stack can be as little as one instruction.
Typically, though, you will have a few more to compute the size,
which is common to all allocation mechanisms.

--
Lawrence Crowl

--

---
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/?hl=en.



.

--047d7b3a98320847bd04debd60a5
Content-Type: text/plain; charset=ISO-8859-1

I am just wondering, why cannot the compiler decide for simple cases of
std::vector, how to allocate it. Surely if a vector is allocated at the
beginning of the block, not changed and not passed anywhere, it can be
allocated on the stack and destroyed on exit from the block. Then we would
not need another data structure. Or is it to much to ask of the compile:
"You are free to use the best allocator you can. I don't care" ?


On 9 June 2013 18:18, Lawrence Crowl <crowl@googlers.com> wrote:

> On 6/8/13, DeadMG <wolfeinstein@gmail.com> wrote:
> > > The problem is that to get the speed, you'd need an allocator with
> > > LIFO properties.  But since vectors can be resized, it won't work
> > > with those in general, only in specific use cases.
> >
> > There's nothing more general about "You can't resize your
> > dynamically-sized container because I allocated off the LIFO
> > allocator which is the stack" compared to "You can't resize your
> > dynamically-sized container because I allocated off the LIFO
> > allocator which is on the heap".
>
> True, but the issue isn't the implementation, but the distinction
> between "if you call the resize function unexpectedly the code
> breaks" and "there is no resize function to call so you cannot make
> that mistake".
>
> I am not arguing that one cannot write correct code with vector
> an a LIFO allocator, just that a restriction in the type makes the
> intent clearer and correct code more likely.
>
> > Resizing a vector would work, it just wouldn't work as well as
> > not resizing it, but that's nothing new. In fact, for some of
> > the smaller sizes, the arena can probably still beat new. One of
> > the many, many ways in which "LIFO heap" is a lot more flexible
> > and general than alloca. Not to mention that, as Olaf says,
> > non-resizability is a different issue really - and we already have
> > tools or proposals that could be used for this, like array_ref.
>
> I do not see how taking a reference to a vector prevents the vector
> from changing size.
>
> > > I think that is partly for two reasons.  First, the technology
> > > that goes into implementing dynarray is old.  It is a rather
> > > unsuprising compiler optimization.  Second, it is a compiler
> > > optimization, and that means there is a much higher bar in
> > > doing the testing than with library changes.
> >
> > If it's readily done, then why are there no sample implementations,
> > like a Clang fork, for example? You can't say that dynarray's
> > performance is incomparable to alloca, and then say you can't
> > implement dynarray (even though it's supposedly non-problematic
> > to implement), and that the performance is obviously justified.
>
> Sun's compiler had a somewhat similar feature ten years ago.
> Isn't that sufficient evidence of implementability?  No one has
> argued that the implementation is difficult.
>
> > Just for reference, I checked alloca for VS2012 again, and it
> > is maybe 15-20 instructions or so. Some stuff I don't understand
> > about control registers. Not just sub esp.
>
> I am not familiar with that plaform, but on other platforms
> allocating from the stack can be as little as one instruction.
> Typically, though, you will have a few more to compute the size,
> which is common to all allocation mechanisms.
>
> --
> Lawrence Crowl
>
> --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--047d7b3a98320847bd04debd60a5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am just wondering, why cannot the compiler decide for si=
mple cases of std::vector, how to allocate it. Surely if a vector is alloca=
ted at the beginning of the block, not changed and not passed anywhere, it =
can be allocated on the stack and=A0destroyed=A0on exit from the block. The=
n we would not need another data structure.=A0Or is it to much to ask of th=
e compile: &quot;You are free to use the best allocator you can. I don&#39;=
t care&quot; ?=A0</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 9 June 201=
3 18:18, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=3D"mailto:crowl@googl=
ers.com" target=3D"_blank">crowl@googlers.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div class=3D"im">On 6/8/13, DeadMG &lt;<a href=3D"mailto:wolfeinstein@gmai=
l.com">wolfeinstein@gmail.com</a>&gt; wrote:<br>
&gt; &gt; The problem is that to get the speed, you&#39;d need an allocator=
 with<br>
&gt; &gt; LIFO properties. =A0But since vectors can be resized, it won&#39;=
t work<br>
&gt; &gt; with those in general, only in specific use cases.<br>
&gt;<br>
&gt; There&#39;s nothing more general about &quot;You can&#39;t resize your=
<br>
&gt; dynamically-sized container because I allocated off the LIFO<br>
&gt; allocator which is the stack&quot; compared to &quot;You can&#39;t res=
ize your<br>
&gt; dynamically-sized container because I allocated off the LIFO<br>
&gt; allocator which is on the heap&quot;.<br>
<br>
</div>True, but the issue isn&#39;t the implementation, but the distinction=
<br>
between &quot;if you call the resize function unexpectedly the code<br>
breaks&quot; and &quot;there is no resize function to call so you cannot ma=
ke<br>
that mistake&quot;.<br>
<br>
I am not arguing that one cannot write correct code with vector<br>
an a LIFO allocator, just that a restriction in the type makes the<br>
intent clearer and correct code more likely.<br>
<div class=3D"im"><br>
&gt; Resizing a vector would work, it just wouldn&#39;t work as well as<br>
&gt; not resizing it, but that&#39;s nothing new. In fact, for some of<br>
&gt; the smaller sizes, the arena can probably still beat new. One of<br>
&gt; the many, many ways in which &quot;LIFO heap&quot; is a lot more flexi=
ble<br>
&gt; and general than alloca. Not to mention that, as Olaf says,<br>
</div>&gt; non-resizability is a different issue really - and we already ha=
ve<br>
<div class=3D"im">&gt; tools or proposals that could be used for this, like=
 array_ref.<br>
<br>
</div>I do not see how taking a reference to a vector prevents the vector<b=
r>
from changing size.<br>
<div class=3D"im"><br>
&gt; &gt; I think that is partly for two reasons. =A0First, the technology<=
br>
&gt; &gt; that goes into implementing dynarray is old. =A0It is a rather<br=
>
&gt; &gt; unsuprising compiler optimization. =A0Second, it is a compiler<br=
>
&gt; &gt; optimization, and that means there is a much higher bar in<br>
&gt; &gt; doing the testing than with library changes.<br>
&gt;<br>
&gt; If it&#39;s readily done, then why are there no sample implementations=
,<br>
&gt; like a Clang fork, for example? You can&#39;t say that dynarray&#39;s<=
br>
&gt; performance is incomparable to alloca, and then say you can&#39;t<br>
&gt; implement dynarray (even though it&#39;s supposedly non-problematic<br=
>
&gt; to implement), and that the performance is obviously justified.<br>
<br>
</div>Sun&#39;s compiler had a somewhat similar feature ten years ago.<br>
Isn&#39;t that sufficient evidence of implementability? =A0No one has<br>
argued that the implementation is difficult.<br>
<div class=3D"im"><br>
&gt; Just for reference, I checked alloca for VS2012 again, and it<br>
&gt; is maybe 15-20 instructions or so. Some stuff I don&#39;t understand<b=
r>
&gt; about control registers. Not just sub esp.<br>
<br>
</div>I am not familiar with that plaform, but on other platforms<br>
allocating from the stack can be as little as one instruction.<br>
Typically, though, you will have a few more to compute the size,<br>
which is common to all allocation mechanisms.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Lawrence Crowl<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3a98320847bd04debd60a5--

.

--089e011828b441efff04dedbda1e
Content-Type: text/plain; charset=ISO-8859-1

*First-allocation preference* can be used for vectors (proper notation can
be sorted out later):
*std::vector<double> a(std::on_stack, 100);*
 *std::vector<double> b(std::on_heap, 10000);*

The user can explicitly state which type of allocation is preferred. If
later the vector is re-allocated, the heap can be used. In this case, we
don't impose any restrictions on the structure we are dealing with. But
behind the scenes, if we want move an on-stack vector, copy will be used
(at least in most  cases).

--

---
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/?hl=en.



--089e011828b441efff04dedbda1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><strong><font color=3D"#006600"><u>First-allocation preference</u></fo=
nt></strong> can be used for vectors (proper notation can be sorted out lat=
er):</div>
<div><strong><font color=3D"#3366ff">std::vector&lt;double&gt; a(std::on_st=
ack, 100);</font></strong></div>
<div>
<div><strong><font color=3D"#3366ff">std::vector&lt;double&gt; b(std::on_he=
ap, 10000);</font></strong></div>
<div>=A0</div>
<div>The user can explicitly state which type of allocation is preferred. I=
f later the vector is re-allocated, the heap can be used. In this case, we =
don&#39;t impose any restrictions on the structure we are dealing with. But=
 behind the scenes, if we want move an on-stack vector, copy will be used (=
at least in most=A0 cases).</div>

<div>=A0</div>
<div>=A0</div>
<div>=A0</div>
<div>=A0</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e011828b441efff04dedbda1e--

.

--20cf302d4e60c4c0b004dedc8286
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 10:29, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> *First-allocation preference* can be used for vectors (proper notation
> can be sorted out later):
> *std::vector<double> a(std::on_stack, 100);*
>  *std::vector<double> b(std::on_heap, 10000);*
>
> The user can explicitly state which type of allocation is preferred. If
> later the vector is re-allocated, the heap can be used. In this case, we
> don't impose any restrictions on the structure we are dealing with. But
> behind the scenes, if we want move an on-stack vector, copy will be used
> (at least in most  cases).
>
>
>
Why wouldn't I do that with a polymorphic allocator instead of adding yet
another constructor signature to vector?

--

---
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/?hl=en.



--20cf302d4e60c4c0b004dedc8286
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 June 2013 10:29, Mikhail Semenov <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1=
957@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><b><font color=3D"#006600"><u>First-all=
ocation preference</u></font></b> can be used for vectors (proper notation =
can be sorted out later):</div>

<div><b><font color=3D"#3366ff">std::vector&lt;double&gt; a(std::on_stack, =
100);</font></b></div>
<div>
<div><b><font color=3D"#3366ff">std::vector&lt;double&gt; b(std::on_heap, 1=
0000);</font></b></div>
<div>=A0</div>
<div>The user can explicitly state which type of allocation is preferred. I=
f later the vector is re-allocated, the heap can be used. In this case, we =
don&#39;t impose any restrictions on the structure we are dealing with. But=
 behind the scenes, if we want move an on-stack vector, copy will be used (=
at least in most=A0 cases).</div>


<div><br><br></div></div></blockquote><div><br></div><div>Why wouldn&#39;t =
I do that with a polymorphic allocator instead of adding yet another constr=
uctor signature to vector? <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf302d4e60c4c0b004dedc8286--

.

--047d7b41400c6be50f04dedd4998
Content-Type: text/plain; charset=ISO-8859-1

>Why wouldn't I do that with a polymorphic allocator instead of adding yet
another constructor signature to vector?
I had mentioned that the exact notation could be sorted out later. If
polymorphic allocators could solve the problem easily let them do it. The
exact mechanism or syntax is not the point.

--

---
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/?hl=en.



--047d7b41400c6be50f04dedd4998
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><font color=3D"#3333ff">&gt;Why wouldn&#39;t I do that with a polymorp=
hic allocator instead of adding yet another constructor signature to vector=
? <br></font></div>
<div>I had mentioned that=A0the exact=A0notation could be sorted out later.=
 If polymorphic allocators could solve the problem easily let them do it. T=
he exact mechanism or syntax is not the point. <br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b41400c6be50f04dedd4998--

.

--001a1133dde60e2ea204dee1fcf2
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 02:29, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> *First-allocation preference* can be used for vectors (proper notation
> can be sorted out later):
> *std::vector<double> a(std::on_stack, 100);*
>  *std::vector<double> b(std::on_heap, 10000);*
>
> The user can explicitly state which type of allocation is preferred. If
> later the vector is re-allocated, the heap can be used. In this case, we
> don't impose any restrictions on the structure we are dealing with. But
> behind the scenes, if we want move an on-stack vector, copy will be used
> (at least in most  cases).
>

-1.

Take the following case:

vector<int> VectorFactory()
{
    vector<int> vi(std::on_stack, 100);
    return vi;
}

struct S
{
    vector<int> vi;
    S() : vi(VectorFactory()) {}
};

unique_ptr<S> SFactory()
{
    return unique_ptr<S>(new S);
}

Now I have a heap object referring to possibly released stack space.  Ugh.

Remember, this is for the standard, not your own personal code base.  Copy,
move and RVO better work correctly and as expected, and shouldn't require
developers to "be careful" when using the class.

The lifetime of stack space (the duration of your stack frame) is
fundamentally different than the lifetime of heap space (the duration of
your program).  Combining the two is tricky.  dynarray gets this correct
with no programmer intervention.  Your solution does not.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--001a1133dde60e2ea204dee1fcf2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 June 2013 02:29, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1957@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div><b><font color=3D"#006600"><u>First-allocation preference</u></font></=
b> can be used for vectors (proper notation can be sorted out later):</div>
<div><b><font color=3D"#3366ff">std::vector&lt;double&gt; a(std::on_stack, =
100);</font></b></div>
<div>
<div><b><font color=3D"#3366ff">std::vector&lt;double&gt; b(std::on_heap, 1=
0000);</font></b></div>
<div>=A0</div>
<div>The user can explicitly state which type of allocation is preferred. I=
f later the vector is re-allocated, the heap can be used. In this case, we =
don&#39;t impose any restrictions on the structure we are dealing with. But=
 behind the scenes, if we want move an on-stack vector, copy will be used (=
at least in most=A0 cases).<br>

</div></div></blockquote></div><br clear=3D"all">-1.<br><br>Take the follow=
ing case:<br><br>vector&lt;int&gt; VectorFactory()<br>{<br>=A0=A0=A0 vector=
&lt;int&gt; vi(std::on_stack, 100);<br>=A0=A0=A0 return vi;<br>}<br><br>str=
uct S<br>
{<br>
=A0=A0=A0 vector&lt;int&gt; vi;<br>=A0=A0=A0 S() : vi(VectorFactory()) {}<b=
r>};<br><br>unique_ptr&lt;S&gt; SFactory()<br>{<br>=A0=A0=A0 return unique_=
ptr&lt;S&gt;(new S);<br>}<br><br>Now I have a heap object referring to poss=
ibly released stack space.=A0 Ugh.<br>

<br>Remember, this is for the standard, not your own personal code base.=A0=
 Copy, move and RVO better work correctly and as expected, and shouldn&#39;=
t require developers to &quot;be careful&quot; when using the class.<br>
<br>
The lifetime of stack space (the duration of your stack frame) is fundament=
ally different than the lifetime of heap space (the duration of your progra=
m).=A0 Combining the two is tricky.=A0 dynarray gets this correct with no p=
rogrammer intervention.=A0 Your solution does not.<br>

-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a1133dde60e2ea204dee1fcf2--

.

------=_Part_348_1761984.1370962986354
Content-Type: text/plain; charset=ISO-8859-1

*>vector<int> VectorFactory()
>{
>    vector<int> vi(std::on_stack, 100);
>    return vi;
>}*
My point was that when this happens the vi is copied into the heap: no move
should be performed here!
(In older days, it was just a copy into a new place; in C++11, it is a move;
but if we allow stack-heap allocation, when we do copy from stack to heap,
not move).
*The point is: we should not allow on-stack vectors to move.*
**
*
*


--

---
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/?hl=en.



------=_Part_348_1761984.1370962986354
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<DIV><FONT style=3D"BACKGROUND-COLOR: #ffffff"><FONT color=3D#000000 face=
=3Darial,sans-serif><STRONG><FONT color=3D#9900ff>&gt;vector&lt;int&gt; Vec=
torFactory()<BR>&gt;{<BR>&gt;&nbsp;&nbsp;&nbsp; vector&lt;int&gt; vi(std::o=
n_stack, 100);<BR>&gt;&nbsp;&nbsp;&nbsp; return vi;<BR>&gt;}</FONT></STRONG=
><BR></FONT></FONT></DIV>
<DIV><FONT style=3D"BACKGROUND-COLOR: #ffffff"><FONT color=3D#000000 face=
=3Darial,sans-serif>My point was that when this happens&nbsp;the vi is copi=
ed&nbsp;into the heap: no move should be performed here!</FONT></FONT></DIV=
>
<DIV><FONT color=3D#000000>(In older days, it was just a copy into a new pl=
ace; in C++11, it is a move;</FONT></DIV>
<DIV><FONT color=3D#000000>but if we allow stack-heap allocation, when we d=
o copy from stack to heap, not move).</FONT></DIV>
<DIV><FONT color=3D#cc0000><STRONG>The point is: we should not allow on-sta=
ck vectors to move.</STRONG></FONT></DIV>
<DIV><FONT style=3D"BACKGROUND-COLOR: #ffffff"><FONT color=3D#9900ff><STRON=
G></STRONG></FONT></FONT>&nbsp;</DIV>
<DIV><FONT style=3D"BACKGROUND-COLOR: #ffffff"><FONT color=3D#9900ff><STRON=
G><BR></STRONG></FONT><BR>&nbsp;</DIV></FONT>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_348_1761984.1370962986354--

.

--14dae9c09c1e60a68e04dee26e53
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 18:03, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> *>vector<int> VectorFactory()
> >{
> >    vector<int> vi(std::on_stack, 100);
> >    return vi;
> >}*
> My point was that when this happens the vi is copied into the heap: no
> move should be performed here!
> (In older days, it was just a copy into a new place; in C++11, it is a
> move;
> but if we allow stack-heap allocation, when we do copy from stack to heap,
> not move).
> *The point is: we should not allow on-stack vectors to move.*
> **
>
>
If that's the point, we have gone seriously astray. If you want to achieve
efficient allocation,
use a pool allocator for which the pool lives longer than the allocator,
and don't do things
that destroy the pool and let the allocator using such pools escape the
scope of the pool.

--

---
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/?hl=en.



--14dae9c09c1e60a68e04dee26e53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 June 2013 18:03, Mikhail Semenov <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1=
957@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><div><font style><font col=
or=3D"#000000" face=3D"arial,sans-serif"><b><font color=3D"#9900ff">&gt;vec=
tor&lt;int&gt; VectorFactory()<br>
&gt;{<br>&gt;=A0=A0=A0 vector&lt;int&gt; vi(std::on_stack, 100);<br>&gt;=A0=
=A0=A0 return vi;<br>&gt;}</font></b><br></font></font></div>
</div><div><font style><font color=3D"#000000" face=3D"arial,sans-serif">My=
 point was that when this happens=A0the vi is copied=A0into the heap: no mo=
ve should be performed here!</font></font></div>
<div><font color=3D"#000000">(In older days, it was just a copy into a new =
place; in C++11, it is a move;</font></div>
<div><font color=3D"#000000">but if we allow stack-heap allocation, when we=
 do copy from stack to heap, not move).</font></div>
<div><font color=3D"#cc0000"><b>The point is: we should not allow on-stack =
vectors to move.</b></font></div><div class=3D"HOEnZb"><div class=3D"h5">
<div><font style><font color=3D"#9900ff"><b></b></font></font><br><br></div=
></div></div></blockquote><div><br></div><div>If that&#39;s the point, we h=
ave gone seriously astray. If you want to achieve efficient allocation,<br>
</div><div>use a pool allocator for which the pool lives longer than the al=
locator, and don&#39;t do things<br>that destroy the pool and let the alloc=
ator using such pools escape the scope of the pool. <br></div></div><br>
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae9c09c1e60a68e04dee26e53--

.

--047d7bea42d45c737a04dee27283
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 10:03, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> *>vector<int> VectorFactory()
> >{
> >    vector<int> vi(std::on_stack, 100);
> >    return vi;
> >}*
> My point was that when this happens the vi is copied into the heap: no
> move should be performed here!
> (In older days, it was just a copy into a new place; in C++11, it is a
> move;
> but if we allow stack-heap allocation, when we do copy from stack to heap,
> not move).
> *The point is: we should not allow on-stack vectors to move.*
>

1.  Are you seriously suggesting removing vector's move constructor?
2.  Even if move was disabled, this is still broken, because you don't know
if RVO will be used or not.

I don't see any way to shoehorn this into vector, without significantly
complicating both its implementation and its use.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--047d7bea42d45c737a04dee27283
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 June 2013 10:03, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1957@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im"><div><font style><font color=3D"#000000" face=3D"arial,sa=
ns-serif"><b><font color=3D"#9900ff">&gt;vector&lt;int&gt; VectorFactory()<=
br>&gt;{<br>&gt;=A0=A0=A0 vector&lt;int&gt; vi(std::on_stack, 100);<br>&gt;=
=A0=A0=A0 return vi;<br>

&gt;}</font></b><br></font></font></div>
</div><div><font style><font color=3D"#000000" face=3D"arial,sans-serif">My=
 point was that when this happens=A0the vi is copied=A0into the heap: no mo=
ve should be performed here!</font></font></div>
<div><font color=3D"#000000">(In older days, it was just a copy into a new =
place; in C++11, it is a move;</font></div>
<div><font color=3D"#000000">but if we allow stack-heap allocation, when we=
 do copy from stack to heap, not move).</font></div>
<div><font color=3D"#cc0000"><b>The point is: we should not allow on-stack =
vectors to move.</b></font></div></blockquote><div><br>1.=A0 Are you seriou=
sly suggesting removing vector&#39;s move constructor?<br>2.=A0 Even if mov=
e was disabled, this is still broken, because you don&#39;t know if RVO wil=
l be used or not.<br>

<br>I don&#39;t see any way to shoehorn this into vector, without significa=
ntly complicating both its implementation and its use.<br clear=3D"all"></d=
iv></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt=
;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bea42d45c737a04dee27283--

.

------=_Part_41_2832622.1370977012325
Content-Type: multipart/alternative;
 boundary="----=_Part_42_27699440.1370977012325"

------=_Part_42_27699440.1370977012325
Content-Type: text/plain; charset=ISO-8859-1


>1.  Are you seriously suggesting removing vector's move constructor?
>2.  Even if move was disabled, this is still broken, because you don't
know if RVO will be used or not.

>I don't see any way to shoehorn this into vector, without significantly
complicating both its implementation and its use.

I am not suggesting to remove anything. I am suggesting to add an internal
flag (on_stack) that is set to *true* when the allocation is on the stack,
and *false* otherwise.  The move constructor will look like this (I have
attached the full example of a simple class *vect -- vector *of double):

*    vect(vect&& x)
    {
        if (x.on_stack)
        {
            v = new double[x.length];
            on_stack = false;
            length = x.length;
            memcpy(v,x.v, sizeof(double)*x.length);// only for demostration
            x.release(); // from stack
        }
        else
        {
            v = x.v;
            length = x.length;
            x.v = nullptr;
            x.length = 0;
            on_stack = false;
        }
    }*
**
The compiled program works both in Visual C++ 2012 and GCC 4.7.2, 4.8.0.
It's interesting GCC already optimises the code.

Imagine a situation with dynamic arrays: they cannot be easily copied. You
start using them then you realise you have to extend, you have to change to
vectors. With vectors you can change the constructor,
leaving the other code intact.




--

---
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/?hl=en.



------=_Part_42_27699440.1370977012325
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><font color=3D"#9900ff"></font>&nbsp;</div><div><font color=3D"#9900ff=
">&gt;1.&nbsp; Are you seriously suggesting removing vector's move construc=
tor?<br>&gt;2.&nbsp; Even if move was disabled, this is still broken, becau=
se you don't know if RVO will be used or not.<br><br>&gt;I don't see any wa=
y to shoehorn this into vector, without significantly complicating both its=
 implementation and its use.</font></div><div>&nbsp;</div><div>I am not sug=
gesting to remove anything. I am suggesting to add an internal flag (on_sta=
ck) that is set to <strong>true</strong> when the allocation is on the stac=
k,</div><div>and <strong>false</strong> otherwise.&nbsp; The move construct=
or will look like this (I have attached the full example of a simple&nbsp;c=
lass <strong>vect&nbsp;-- vector </strong>of double):</div><div>&nbsp;</div=
><div><font face=3D"courier new,monospace"><strong>&nbsp;&nbsp;&nbsp;&nbsp;=
vect(vect&amp;&amp; x)<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;if (x.on_stack)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; v =3D new double[x.length];<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; on_stack =3D false;<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length =3D x.length;<br>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; memcpy(v,x.v, =
sizeof(double)*x.length);// only for demostration<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x.release(); // from stack&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else<br>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v =3D x.v;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length =3D x.length;<br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x.v =3D nullptr;<br>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x.length =
=3D 0;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; on_stack =3D false;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&n=
bsp;&nbsp;&nbsp; }</strong></font></div><div><strong><font face=3D"Courier =
New"></font></strong>&nbsp;</div><div><font face=3D"arial,sans-serif">The c=
ompiled program works both in Visual C++ 2012 and GCC 4.7.2, 4.8.0. It's in=
teresting GCC already optimises the code.</font></div><div>&nbsp;</div><div=
>Imagine a situation with dynamic arrays: they cannot be easily copied. You=
 start using them then you realise you have to extend, you have to change t=
o vectors. With vectors you can change the constructor,</div><div>leaving t=
he other code intact.</div><div>&nbsp;</div><div>&nbsp;</div><div>&nbsp;</d=
iv>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_42_27699440.1370977012325--
------=_Part_41_2832622.1370977012325
Content-Type: text/plain; charset=US-ASCII; name=on_stack_vector.cpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=on_stack_vector.cpp
X-Attachment-Id: abe36520-5e63-491f-990c-e8bae46edff5
Content-ID: <abe36520-5e63-491f-990c-e8bae46edff5>


#include <iostream>
#include <memory>
#include <string.h> // for memcpy


class Mystack
{
    double mem[1000000];
    int pointer;
public:
    Mystack():pointer(0) {}
    double* alloc(int n)
    {
        double* v1 = pointer+mem;
        pointer+= n;
        std::cout << "alloc: " << pointer << std::endl;
        return v1;
    }

    void release(double *v)
    {

        pointer = (int)(v-mem);
        std::cout << "release: " << pointer << std::endl;
    }
};

Mystack mystack;

class vect
{
    double* v;
    int length;
    bool on_stack;
public:
    vect(bool on_stack1, int length1):on_stack(on_stack1),length(length1)
    {
        if (on_stack)
        {
            std::cout << "stack allocation " << std::endl;
            v = mystack.alloc(length1);
        }
        else
        {
            std::cout << "heap allocation " << std::endl;
            v = new double[length1];
        }
    }

    vect(const vect& x)
    {
 std::cout << "copy constructor" << std::endl;
        v = new double[x.length];
        length = x.length;
        memcpy(v,x.v, sizeof(double)*x.length);
        on_stack = false;
    }

    vect(vect&& x)
    {
        std::cout << "move constructor" << std::endl;
        if (x.on_stack)
        {
            v = new double[x.length];
            on_stack = false;
            length = x.length;
            memcpy(v,x.v, sizeof(double)*x.length);
            x.release(); // from stack
        }
        else
        {
            v = x.v;
            length = x.length;
            x.v = nullptr;
            x.length = 0;
            on_stack = false;
        }
    }

    vect& operator=(const vect& x)
    {
        std::cout << "copy" << std::endl;
        if (x.length != length)
        {
            release();
            v = new double[x.length];
            length = x.length;
        }
        memcpy(v,x.v, sizeof(double)*x.length);
        return *this;
    }

    vect& operator= (vect&& x)
    {
        std::cout << "move" << std::endl;
        if (x.on_stack)
        {
            if (x.length != length)
            {
                release();
                v = new double[x.length];
                length = x.length;
                on_stack = false;
            }
            memcpy(v,x.v, sizeof(double)*x.length);
            x.release();
        }
        else
        {
            release();
            v = x.v;
            length = x.length;
            x.v = nullptr;
            x.length = 0;
            on_stack = false;
        }
        return *this;
    }

    double& operator[](std::size_t i) { return v[i]; }
    double operator[](std::size_t i) const { return v[i]; }

    ~vect() { release(); }

private:

    void release()
    {
        if (on_stack)
        {
            mystack.release(v);
        }
        else
        {
             delete [] v;
        }
        v = nullptr;
        length = 0;
        on_stack = false;
    }
};

vect VectorFactory()
{
    vect vi(true, 100);
    return vi;
}

struct S
 {
    vect vi;
    S() : vi(VectorFactory()) {}
};

std::unique_ptr<S> SFactory()
{
    return std::unique_ptr<S>(new S);
}

int main()
{
    std::unique_ptr<S> p[3];

    p[0] = SFactory();
    p[1] = SFactory();
    p[2] = SFactory();


    for (int i = 0; i < 3; i++)
    {
        (*p[i]).vi[i] = i;
    }

    for (int i = 0; i < 3; i++)
    {
        std::cout << (*p[i]).vi[i] << std::endl;
    }
 return 0;
}

------=_Part_41_2832622.1370977012325--

.

--047d7bd6acf4679bdc04dee5a740
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 13:56, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

>
> >1.  Are you seriously suggesting removing vector's move constructor?
> >2.  Even if move was disabled, this is still broken, because you don't
> know if RVO will be used or not.
>
> >I don't see any way to shoehorn this into vector, without significantly
> complicating both its implementation and its use.
>
> I am not suggesting to remove anything. I am suggesting to add an internal
> flag (on_stack) that is set to *true* when the allocation is on the stack,
> and *false* otherwise.
>

As I wrote in (2) above, I don't see how that works correctly when RVO is
involved, since no copy or move is actually executed.  Could you elaborate?

If you want to write your own fragile allocator and fragile containers
which does this for your users, go right ahead.  But I am strongly against
this kind of change to either the standard allocator or standard containers.

Imagine a situation with dynamic arrays: they cannot be easily copied.
>

dynarray can be very easily copied.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--047d7bd6acf4679bdc04dee5a740
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 June 2013 13:56, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1957@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im"><div><font color=3D"#9900ff"></font>=A0</div><div><font c=
olor=3D"#9900ff">&gt;1.=A0 Are you seriously suggesting removing vector&#39=
;s move constructor?<br>&gt;2.=A0 Even if move was disabled, this is still =
broken, because you don&#39;t know if RVO will be used or not.<br>

<br>&gt;I don&#39;t see any way to shoehorn this into vector, without signi=
ficantly complicating both its implementation and its use.</font></div><div=
>=A0</div></div><div>I am not suggesting to remove anything. I am suggestin=
g to add an internal flag (on_stack) that is set to <b>true</b> when the al=
location is on the stack,</div>

<div>and <b>false</b> otherwise.=A0</div></blockquote><div><br>As I wrote i=
n (2) above, I don&#39;t see how that works correctly when RVO is involved,=
 since no copy or move is actually executed.=A0 Could you elaborate?<br><br=
>

If you want to write your own fragile allocator and fragile containers whic=
h does this for your users, go right ahead.=A0 But I am strongly against th=
is kind of change to either the standard allocator or standard containers.<=
br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div>Imagine a situation with dyna=
mic arrays: they cannot be easily copied. </div></blockquote><div><br>dynar=
ray can be very easily copied.<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bd6acf4679bdc04dee5a740--

.

------=_Part_55_28788440.1370980809948
Content-Type: text/plain; charset=ISO-8859-1

>2.  Even if move was disabled, this is still broken, because you don't
know if RVO will be used or not.
The return value optimisation will work, if you follow standard rules of
defining move or copy. I don't see the point in mixing various array
containers.
Below is a quote from the standard when RVO performs.

"When certain criteria are met, an implementation is allowed to omit the
copy/move construction of a class
object, even if the constructor selected for the copy/move operation and/or
the destructor for the object
have side effects. In such cases, the implementation treats the source and
target of the omitted copy/move
operation as simply two different ways of referring to the same object, and the
destruction of that object
occurs at the later of the times when the two objects would have been
destroyed without the optimization."

In other words,  either destruction happens at a later time for object (the
time should be the same for both objects), or RVO will not be performed.
How can an object be destroyed later, if it is on the stack? Another issue
is that the standard allows different allocators anyway, they should work.

--

---
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/?hl=en.



------=_Part_55_28788440.1370980809948
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><font color=3D"#9900ff">&gt;2.&nbsp; Even if move was disabled, this i=
s still broken, because you don't know if RVO will be used or not.</font><b=
r></div><div>The return value optimisation will work, if you follow standar=
d rules of defining move or copy. I don't see the point in mixing various a=
rray containers.</div><div>Below is a quote from the standard when RVO perf=
orms. </div><div>&nbsp;</div><div><font color=3D"#134f5c">"When certain cri=
teria are met, an implementation is allowed to omit the copy/move construct=
ion of a class<br>object, even if the constructor selected for the copy/mov=
e operation and/or the destructor for the object<br>have side effects. In s=
uch cases, the implementation treats the source and target of the omitted c=
opy/move<br>operation as simply two different ways of referring to the same=
 object, and <font color=3D"#990000">the destruction of that object<br>occu=
rs at the later of the times when the two objects would have been destroyed=
 without the optimization</font>."</font></div><div><font color=3D"#134f5c"=
></font>&nbsp;</div><div><font color=3D"#000000" face=3D"arial,sans-serif">=
In other words,&nbsp; either destruction happens at a later time for object=
 (the time should be the same for both objects), or RVO will not be perform=
ed. </font></div><div><font color=3D"#000000" face=3D"arial,sans-serif">How=
 can an object be destroyed later, if it is on the stack? Another issue is =
that the standard allows different allocators anyway, they should work.</fo=
nt></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_55_28788440.1370980809948--

.

--001a11c2d3aa93ba8b04dee68676
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 15:00, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> >2.  Even if move was disabled, this is still broken, because you don't
> know if RVO will be used or not.
> The return value optimisation will work,
>

And give you a dangling reference to stack memory, which is just not
possible with the C++11 standard containers using the standard allocator.
 Look at my example again.


> How can an object be destroyed later, if it is on the stack?
>

You tell us; it's your suggestion that we allow the standard containers
with the standard allocator to be that fragile.

Another issue is that the standard allows different allocators anyway, they
> should work.
>

They do work because if the user has a custom allocator, it is their job to
ensure that the lifetime of the storage is at least as long as the lifetime
of all containers which use that storage.  That would be a change (and a
horrible one IMO) to put that burden on all users of standard containers
using the standard allocator.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--001a11c2d3aa93ba8b04dee68676
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 June 2013 15:00, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1957@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im"><div><font color=3D"#9900ff">&gt;2.=A0 Even if move was d=
isabled, this is still broken, because you don&#39;t know if RVO will be us=
ed or not.</font><br></div></div><div>The return value optimisation will wo=
rk,</div>

</blockquote><div><br></div><div>And give you a dangling reference to stack=
 memory, which is just not possible with the C++11 standard containers usin=
g the standard allocator. =A0Look at my example again.</div><div>=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div><span class=3D"Apple-style-span" style=3D"font-family:arial,sans-serif=
">How can an object be destroyed later, if it is on the stack?</span></div>=
</blockquote><div><br></div><div>You tell us; it&#39;s your suggestion that=
 we allow the standard containers with the standard allocator to be that fr=
agile.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div><span class=3D"Apple-sty=
le-span" style=3D"font-family:arial,sans-serif"> Another issue is that the =
standard allows different allocators anyway, they should work.</span></div>

</blockquote><div><br></div><div>They do work because if the user has a cus=
tom allocator, it is their job to ensure that the lifetime of the storage i=
s at least as long as the lifetime of all containers which use that storage=
.. =A0That would be a change (and a horrible one IMO) to put that burden on =
all users of standard containers using the standard allocator.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2d3aa93ba8b04dee68676--

.

------=_Part_412_26149155.1370985654291
Content-Type: text/plain; charset=ISO-8859-1

>And give you a dangling reference to stack memory, which is just not
possible with the C++11 standard containers using the standard >allocator.
 Look at my example again.

No dangling reference: the stack will be cleared.

>They do work because if the user has a custom allocator, it is their job
to ensure that the lifetime of the storage is at least as long as the
>lifetime of all containers which use that storage.  That would be a change
(and a horrible one IMO) to put that burden on all users of >standard
containers using the standard allocator.

To be honest, I lost you point here. You mean that if different allocators
are used, memory handling will be inefficient. I thick we are talking about
the optimisation issues here. Don't optimise then!. There is enough
efficiency in using move. If it is difficult for the compiler to do the
optimisation then don't do it. Your unique pointer is using move: what's
the problem.

Look at my move code: if it's originally allocated on the stack: you copy;
by what is on the stack you destroy (and assign nullptr to the pointer). If
it is allocated on the heap you move. What is the problem? The compiler is
only allowed to do what is legal. There is no problem in designing your own
containers.



--

---
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/?hl=en.



------=_Part_412_26149155.1370985654291
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><font color=3D"#9900ff">&gt;And give you a dangling reference to stack=
 memory, which is just not possible with the C++11 standard containers usin=
g the standard &gt;allocator. &nbsp;Look at my example again.</font></div><=
div><font color=3D"#9900ff"></font>&nbsp;</div><div><font color=3D"#000000"=
>No dangling reference: the stack will be cleared.</font></div><div><br><fo=
nt color=3D"#9900ff">&gt;They do work because if the user has a custom allo=
cator, it is their job to ensure that the lifetime of the storage is at lea=
st as long as the &gt;lifetime of all containers which use that storage. &n=
bsp;That would be a change (and a horrible one IMO) to put that burden on a=
ll users of &gt;standard containers using the standard allocator.</font></d=
iv><div>&nbsp;</div><div><font face=3D"arial,sans-serif">To be honest, I lo=
st you point here.&nbsp;You mean that if different allocators are used, mem=
ory handling will be inefficient. I thick we are talking about the optimisa=
tion issues here. Don't optimise then!. There is enough efficiency in using=
 move. If it is difficult for the compiler to do the optimisation then don'=
t do it. Your unique pointer is using move: what's the problem. </font></di=
v><div><font face=3D"arial,sans-serif"></font>&nbsp;</div><div><font face=
=3D"arial,sans-serif">Look at my move code: if it's originally allocated on=
 the stack: you copy; by what is on the stack you destroy (and assign nullp=
tr to the pointer). If it is allocated on the heap you move. What is the pr=
oblem? The compiler is only allowed to do what is legal. There is no proble=
m in designing your own containers.</font></div><div>&nbsp;</div><div>&nbsp=
;</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_412_26149155.1370985654291--

.

------=_Part_4463_26325321.1370987194577
Content-Type: text/plain; charset=ISO-8859-1

*>Look at my example again.*

For your information, I put *your example* into the sample code that I
attached before.
It does not have any leaks (all the allocated memory is correctly
destroyed). But it behaves slightly differently in VC++ depending on the
optimization level. Again it does nothing wrong with the code.

Since I am not really using stack, but LIFO allocation, in the optimized
code it uses this LIFO memory,
ignoring the heap. The same happens in GCC. But this is another issue. If
such optimisation is not
a good idea, I thick the standard can be changed to enforce the rules.




*
*

--

---
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/?hl=en.



------=_Part_4463_26325321.1370987194577
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<font color=3D"#9900ff"><div><font color=3D"#9900ff"><strong>&gt;Look at my=
 example again.</strong></font></div><div><font color=3D"#9900ff"></font>&n=
bsp;</div><div><font color=3D"#000000" face=3D"arial,sans-serif">For your i=
nformation, I put <strong>your example</strong> into the sample code that I=
 attached before. </font></div><div><font color=3D"#000000">It does not hav=
e any leaks (all the allocated memory is correctly destroyed). But it behav=
es slightly differently in VC++ depending on the optimization level. </font=
><font color=3D"#000000">Again it does nothing wrong with the code. </font>=
</div><div><font color=3D"#000000"></font>&nbsp;</div><div><font color=3D"#=
000000">Since I am not really using stack, but LIFO allocation, in the opti=
mized code it uses this LIFO memory,</font></div><div><font color=3D"#00000=
0">ignoring the heap. The same happens in GCC. But this is another issue. I=
f such optimisation is not</font></div><div><font color=3D"#000000">a good =
idea, I thick the standard can be changed to enforce the rules.</font></div=
><div><font color=3D"#000000"></font>&nbsp;</div><div><font color=3D"#00000=
0"></font>&nbsp;</div><div><font color=3D"#000000"></font>&nbsp;</div><div>=
&nbsp;</div><div><strong><br></strong>&nbsp;</div></font>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4463_26325321.1370987194577--

.

--001a11c1f4a274524904dee7d9c2
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2013 16:20, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> >They do work because if the user has a custom allocator, it is their job
> to ensure that the lifetime of the storage is at least as long as the
> >lifetime of all containers which use that storage.  That would be a change
> (and a horrible one IMO) to put that burden on all users of >standard
> containers using the standard allocator.
>
> To be honest, I lost you point here. You mean that if different allocators
> are used, memory handling will be inefficient.
>

No. I mean if different allocators are used, the copy/move
constructors/assignment may lead to nasty runtime bugs if you are not
handling the lifetime of the storage correctly.  This cannot happen when
containers use the standard allocator.


> I thick we are talking about the optimisation issues here.
>

We are talking about correctness with respect to legal C++ optimizations.


> Don't optimise then!.
>

Huh?  Even if I would want to (and I most certainly don't), compilers are
not required to give me options to turn off copy/move elision.


>  Look at my move code: if it's originally allocated on the stack: you
> copy; by what is on the stack you destroy (and assign nullptr to the
> pointer). If it is allocated on the heap you move. What is the problem?
>

Your move constructor *will not be executed* if the move is elided.


>  The compiler is only allowed to do what is legal.
>

It is doing something legal.

> --
>
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--001a11c1f4a274524904dee7d9c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 June 2013 16:20, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1957@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im"><div><span class=3D"Apple-style-span" style=3D"color:rgb(=
153,0,255)">&gt;They do work because if the user has a custom allocator, it=
 is their job to ensure that the lifetime of the storage is at least as lon=
g as the &gt;lifetime of all containers which use that storage. =A0That wou=
ld be a change (and a horrible one IMO) to put that burden on all users of =
&gt;standard containers using the standard allocator.</span></div>

</div><div class=3D"im"><div>=A0</div></div><div><font face=3D"arial,sans-s=
erif">To be honest, I lost you point here.=A0You mean that if different all=
ocators are used, memory handling will be inefficient. </font></div></block=
quote>

<div><br></div><div>No. I mean if different allocators are used, the copy/m=
ove constructors/assignment may lead to nasty runtime bugs if you are not h=
andling the lifetime of the storage correctly. =A0This cannot happen when c=
ontainers use the standard allocator.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div><font face=3D"arial,sans-=
serif">I thick we are talking about the optimisation issues here.</font></d=
iv>
</blockquote>
<div><br></div><div>We are talking about correctness with respect to legal =
C++ optimizations.</div><div>=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><=
font face=3D"arial,sans-serif"> Don&#39;t optimise then!.</font></div>

</blockquote><div><br></div><div>Huh? =A0Even if I would want to (and I mos=
t certainly don&#39;t), compilers are not required to give me options to tu=
rn off copy/move elision.</div><div>=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<div>=A0<span class=3D"Apple-style-span" style=3D"font-family:arial,sans-se=
rif">Look at my move code: if it&#39;s originally allocated on the stack: y=
ou copy; by what is on the stack you destroy (and assign nullptr to the poi=
nter). If it is allocated on the heap you move. What is the problem?</span>=
</div>

</blockquote><div><br></div><div>Your move constructor *will not be execute=
d* if the move is elided.</div><div>=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div>
<span class=3D"Apple-style-span" style=3D"font-family:arial,sans-serif"> Th=
e compiler is only allowed to do what is legal. </span></div></blockquote><=
div><br></div><div>It is doing something legal.=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div>--=A0</div></blockquote></div>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c1f4a274524904dee7d9c2--

.

On 6/9/13, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:
> I am just wondering, why cannot the compiler decide for simple
> cases of std::vector, how to allocate it. Surely if a vector is
> allocated at the beginning of the block, not changed and not passed
> anywhere, it can be allocated on the stack and destroyed on exit
> from the block. Then we would not need another data structure. Or
> is it to much to ask of the compile: "You are free to use the
> best allocator you can. I don't care" ?

The compiler is always free to apply the as-if rule.  The problem
is that compiler writers need some evidence that they will find
enough gain to do the analysis to find that the rule applies.  The
harder the analysis, the more gain one needs to match it.

--
Lawrence Crowl

--

---
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/?hl=en.



.

------=_Part_4094_6247100.1371025135096
Content-Type: text/plain; charset=ISO-8859-1


>
> Lawrence,
>
> My basic concern about dynamic arrays is that if I define some functions,
> like that:
> *std::vector<double> f(const std::vector<double>& a, const
> std::vector<double>& b);*
>
> (and there will be lot's of them in the program),
> I won't be able to apply them to similar dynamic arrays: they are
> different types.
>
> On the other hand,  if I use vectors only, I will be able to apply them.
>
> *The solution will be either to avoid dynamic arrays or write templates. *
>
> *As I've shown in my (quickly patched up) example, there is no problem to
> allow vectors to provide two kinds of allocation: on the stack or on the
> heap. Once you start moving/coping/extending, the on-stack data changes to
> the on-heap one. I used my own stack in the example, but I think using a
> program stack won't be a problem.*
>
> I compiled my example using three different compilers (and in different
> modes): there was no problem.  I understand it's only a small test, but I
> think the concept is correct.
>
> Mikhail.
>

--

---
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/?hl=en.



------=_Part_4094_6247100.1371025135096
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<P>Lawrence,</P>
<P>My basic concern about dynamic arrays is that if I define some functions=
, like that:<BR><STRONG>std::vector&lt;double&gt; f(const std::vector&lt;do=
uble&gt;&amp; a, const std::vector&lt;double&gt;&amp; b);</STRONG></P>
<P>(and there will be lot's of them in the program),<BR>I won't be able to =
apply them to similar dynamic arrays: they are different types.</P>
<P>On the other hand,&nbsp; if I use vectors only, I will be able to apply =
them.</P>
<P><STRONG>The solution will be either to avoid dynamic arrays or write tem=
plates. </STRONG></P>
<P><STRONG><FONT color=3D#134f5c>As I've shown in my (quickly patched up) e=
xample, there is no problem to allow vectors to provide two kinds of alloca=
tion: on the stack or on the heap. Once you start moving/coping/extending, =
the on-stack data changes to the on-heap one. I used my own stack in the ex=
ample, but I think using a program stack won't be a problem.</FONT></STRONG=
></P>
<P>I compiled my example using three different compilers (and in different =
modes): there was no problem.&nbsp; I understand it's only a small test, bu=
t I think the concept is correct.</P>
<P>Mikhail.<BR></P></BLOCKQUOTE>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4094_6247100.1371025135096--

.

--047d7b6dc474912aa704def0e174
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 12, 2013 at 10:18 AM, Mikhail Semenov <
mikhailsemenov1957@gmail.com> wrote:

> Lawrence,
>>
>> My basic concern about dynamic arrays is that if I define some functions,
>> like that:
>> *std::vector<double> f(const std::vector<double>& a, const
>> std::vector<double>& b);*
>>
>> (and there will be lot's of them in the program),
>> I won't be able to apply them to similar dynamic arrays: they are
>> different types.
>>
>> On the other hand,  if I use vectors only, I will be able to apply them.
>>
>> *The solution will be either to avoid dynamic arrays or write templates.
>> *
>>
> Unsurprisingly, if you want generic code, you need to use the generic code
facilities.

> *As I've shown in my (quickly patched up) example, there is no problem to
>> allow vectors to provide two kinds of allocation: on the stack or on the
>> heap. Once you start moving/coping/extending, the on-stack data changes to
>> the on-heap one. I used my own stack in the example, but I think using a
>> program stack won't be a problem.*
>>
>> Judging from the response such example generated, I would think it failed
to show any of what you claim it did.

I compiled my example using three different compilers (and in different
>> modes): there was no problem.  I understand it's only a small test, but I
>> think the concept is correct.
>>
> Your test is not testing what it should. It tests that you can write to
some place in memory and read the same values from it immediately
afterwards. That's meaningless. As C++ programmers we all know about
undefined behaviour.

Your test is also more complex than it needs to be. Just make the member
variables of the vect class public and test this instead:

vect VectorFactory()
{
    vect vi(true, 100);
    return vi;
}

int main()
{
    vect v = VectorFactory();
    std::cout << std::boolalpha << v.on_stack << std::endl;
}

I get a "true" output with both clang and GCC.

Martinho

--

---
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/?hl=en.



--047d7b6dc474912aa704def0e174
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 12, 2013 at 10:18 AM, Mikhail Semenov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov19=
57@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote style=3D"bord=
er-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1e=
x" class=3D"gmail_quote">

<p>Lawrence,</p>
<p>My basic concern about dynamic arrays is that if I define some functions=
, like that:<br><b>std::vector&lt;double&gt; f(const std::vector&lt;double&=
gt;&amp; a, const std::vector&lt;double&gt;&amp; b);</b></p>
<p>(and there will be lot&#39;s of them in the program),<br>I won&#39;t be =
able to apply them to similar dynamic arrays: they are different types.</p>
<p>On the other hand,=A0 if I use vectors only, I will be able to apply the=
m.</p>
<p><b>The solution will be either to avoid dynamic arrays or write template=
s. </b></p></blockquote></blockquote><div>Unsurprisingly, if you want gener=
ic code, you need to use the generic code facilities. <br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<blockquote style=3D"border-left:1px solid rgb(204,204,204);margin:0px 0px =
0px 0.8ex;padding-left:1ex" class=3D"gmail_quote">
<p><b><font color=3D"#134f5c">As I&#39;ve shown in my (quickly patched up) =
example, there is no problem to allow vectors to provide two kinds of alloc=
ation: on the stack or on the heap. Once you start moving/coping/extending,=
 the on-stack data changes to the on-heap one. I used my own stack in the e=
xample, but I think using a program stack won&#39;t be a problem.</font></b=
></p>

<p></p></blockquote></blockquote><div>Judging from the response such exampl=
e generated, I would think it failed to show any of what you claim it did.<=
br clear=3D"all"></div><div><div><br></div></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
<blockquote style=3D"border-left:1px solid rgb(204,204,204);margin:0px 0px =
0px 0.8ex;padding-left:1ex" class=3D"gmail_quote"><p>I compiled my example =
using three different compilers (and in different modes): there was no prob=
lem.=A0 I understand it&#39;s only a small test, but I think the concept is=
 correct.</p>
</blockquote></blockquote><div>Your test is not testing what it should. It =
tests that you can write to some place in memory and read the same values f=
rom it immediately afterwards. That&#39;s meaningless. As C++ programmers w=
e all know about undefined behaviour.<br>
<br></div><div>Your test is also more complex than it needs to be. Just mak=
e the member variables of the vect class public and test this instead:<br><=
/div><div><br>vect VectorFactory()<br>{<br>=A0=A0=A0 vect vi(true, 100);<br=
>=A0=A0=A0 return vi;<br>
}<br><br>int main()<br>{<br>=A0=A0=A0 vect v =3D VectorFactory();<br>=A0=A0=
=A0 std::cout &lt;&lt; std::boolalpha &lt;&lt; v.on_stack &lt;&lt; std::end=
l;<br>}<br><br></div>I get a &quot;true&quot; output with both clang and GC=
C.<br></div>
<div class=3D"gmail_quote"><br><div>Martinho <br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6dc474912aa704def0e174--

.

--001a11c35d14d6606704def1042f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 12, 2013 at 10:34 AM, Martinho Fernandes <
martinho.fernandes@gmail.com> wrote:

>
> I get a "true" output with both clang and GCC.
>
>
I want to make this clear.

A "true" output means the copy or move constructors that were supposed be
saving the day were not called, as some other people mentioned in this
conversation. Had this been the actual call stack and not a fake one, v
would now be holding memory in a dead stack frame below the current one.

Martinho

--

---
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/?hl=en.



--001a11c35d14d6606704def1042f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 12, 2013 at 10:34 AM, Martinho Fernandes <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">martinho.fern=
andes@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><br>I get a &quot;true&quot; =
output with both clang and GCC.<span class=3D""><font color=3D"#888888"><br=
>
</font></span></div><span class=3D""><font color=3D"#888888"></font></span>=
<br></div></div></blockquote></div><br>I want to make this clear.<br><br></=
div><div class=3D"gmail_extra">A &quot;true&quot; output means the copy or =
move constructors that were supposed be saving the day were not called, as =
some other people mentioned in this conversation. Had this been the actual =
call stack and not a fake one, v would now be holding memory in a dead stac=
k frame below the current one.<br>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div>Martinho</div>
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c35d14d6606704def1042f--

.

On Wed, Jun 12, 2013 at 10:18 AM, Mikhail Semenov
<mikhailsemenov1957@gmail.com> wrote:
>> Lawrence,
>>
>> My basic concern about dynamic arrays is that if I define some functions,
>> like that:
>> std::vector<double> f(const std::vector<double>& a, const
>> std::vector<double>& b);
>>
>> (and there will be lot's of them in the program),
>> I won't be able to apply them to similar dynamic arrays: they are
>> different types.
>>
>> On the other hand,  if I use vectors only, I will be able to apply them.
>>
>> The solution will be either to avoid dynamic arrays or write templates.

No, the solution is to use range<double*> or array_ref<double>
const vector& (and most of the time) const string& are unnecessarily
restrictive.

--

---
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/?hl=en.



.