Hi, STL:

Indeed the proposal covers the most possible needs of the users,
while IMHO, to make the use similar to STL the library may be
more helpful.  Say:

  vector<T>(sz)  // value init with a size
  vector<T>(sz, value)  // init all to `value`
  vector<T>{...}  // uniform (element-by-element in this case)

In our case, I think we can just make the first overload

  make_unique<T[]>(sz)  // do default initialization

and keep the second overload

  make_unique<T[]>(sz, value)  // use T() instead of value to get value init

and distinguished uniform init from them

  make_unique_with<T[]>(v1, v2, ...)  // like auto-size

Comments?

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



.

I am trying to follow a few principles:

1. Safety.
2. Clarity.
3. Symmetry with new-expressions, which this is wrapping.

I don't want to reinvent vector. (In fact, I am personally not fond of uniq=
ue_ptr<T[]>. I recognize that it is zero-overhead and may be useful in cert=
ain situations, especially because it can release(), but I have never encou=
ntered a situation in my own code where I would want to use it instead of v=
ector.)

As I explained in N3588, I believe that make_unique<T> and make_unique<T[]>=
 should value-init, for safety. Default-init (aka garbage-init) is dangerou=
s, and should be explicitly requested.

The Core Language doesn't have syntax for new-expressions that allocates N =
elements, all initialized to T. Therefore, I do not believe that such synta=
x should be invented for make_unique<T[]>. (auto-size is novel, but there I=
 just think Core is deficient and will be corrected eventually.)

I like the name "make_unique_with" - that hadn't occurred to me, and it may=
 be useful. I'll keep it in mind!

I am currently considering new syntax, in order to improve clarity (and pos=
sibly solve the friendship problem):

make_unique<T>(args...)      // unchanged
make_unique<T>(default_init) // instead of make_unique_default_init<T>()

make_unique<T[]>(n)(args...)      // instead of make_unique<T[]>(n) and mak=
e_unique_value_init<T[]>(n, args...)
make_unique<T[]>(n)(default_init) // instead of make_unique_default_init<T[=
]>(n)
make_unique<T[]>()(args...)       // instead of make_unique_auto_size<T[]>(=
args...)

Thanks,
STL

-----Original Message-----
From: Zhihao Yuan [mailto:lichray@gmail.com]=20
Sent: Wednesday, March 20, 2013 7:46 AM
To: Stephan T. Lavavej
Cc: std-proposals@isocpp.org
Subject: Some words on N3588, make_unique

Hi, STL:

Indeed the proposal covers the most possible needs of the users,
while IMHO, to make the use similar to STL the library may be
more helpful.  Say:

  vector<T>(sz)  // value init with a size
  vector<T>(sz, value)  // init all to `value`
  vector<T>{...}  // uniform (element-by-element in this case)

In our case, I think we can just make the first overload

  make_unique<T[]>(sz)  // do default initialization

and keep the second overload

  make_unique<T[]>(sz, value)  // use T() instead of value to get value ini=
t

and distinguished uniform init from them

  make_unique_with<T[]>(v1, v2, ...)  // like auto-size

Comments?

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


--=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 Thu, Mar 21, 2013 at 5:03 AM, Stephan T. Lavavej
<stl@exchange.microsoft.com> wrote:
> make_unique<T>(args...)      // unchanged
> make_unique<T>(default_init) // instead of make_unique_default_init<T>()
>
> make_unique<T[]>(n)(args...)      // instead of make_unique<T[]>(n) and make_unique_value_init<T[]>(n, args...)
> make_unique<T[]>(n)(default_init) // instead of make_unique_default_init<T[]>(n)
> make_unique<T[]>()(args...)       // instead of make_unique_auto_size<T[]>(args...)

Exactly!  Those come to my mind last night, and they do model the new[] syntax
very well.  If we write {n} instead of (0), then they look even clear.

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



.

Objects can be constructed with braces, but functions can't be called with braces, unless I'm missing something.

STL

-----Original Message-----
From: Zhihao Yuan [mailto:lichray@gmail.com]
Sent: Thursday, March 21, 2013 6:12 AM
To: Stephan T. Lavavej
Cc: std-proposals@isocpp.org
Subject: Re: [std-proposals] RE: Some words on N3588, make_unique

On Thu, Mar 21, 2013 at 5:03 AM, Stephan T. Lavavej
<stl@exchange.microsoft.com> wrote:
> make_unique<T>(args...)      // unchanged
> make_unique<T>(default_init) // instead of make_unique_default_init<T>()
>
> make_unique<T[]>(n)(args...)      // instead of make_unique<T[]>(n) and make_unique_value_init<T[]>(n, args...)
> make_unique<T[]>(n)(default_init) // instead of make_unique_default_init<T[]>(n)
> make_unique<T[]>()(args...)       // instead of make_unique_auto_size<T[]>(args...)

Exactly!  Those come to my mind last night, and they do model the new[] syntax
very well.  If we write {n} instead of (0), then they look even clear.

--
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 Thu, Mar 21, 2013 at 2:01 PM, Stephan T. Lavavej
<stl@exchange.microsoft.com> wrote:
> Objects can be constructed with braces, but functions can't be called with braces, unless I'm missing something.

Regards make_unique as a class template with an operator(), and the
object holds a size and a bool (saying whether we have the sized passed).

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



.

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

On Thu, Mar 21, 2013 at 2:57 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> Regards make_unique as a class template with an operator(), and the
> object holds a size and a bool (saying whether we have the sized passed).

Here is something I got to pass all your test cases.  Far from complete, though.

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



--bcaec554de865c2b3504d8754297
Content-Type: application/octet-stream; name="a.cc"
Content-Disposition: attachment; filename="a.cc"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hekdo7ro0

I2luY2x1ZGUgPHR5cGVfdHJhaXRzPgojaW5jbHVkZSA8aW9zdHJlYW0+CiNpbmNsdWRlIDxtZW1v
cnk+Cgp0ZW1wbGF0ZTx0eXBlbmFtZSBUPgpzdHJ1Y3QgX1VuaXF1ZV9pZiB7Cgl0eXBlZGVmIHN0
ZDo6dW5pcXVlX3B0cjxUPiBfU2luZ2xlOwp9OwoKdGVtcGxhdGU8dHlwZW5hbWUgVD4Kc3RydWN0
IF9VbmlxdWVfaWY8VFtdPiB7Cgl0eXBlZGVmIHN0ZDo6dW5pcXVlX3B0cjxUW10+IF9SdW50aW1l
Owp9OwoKc3RydWN0IGRlZmF1bHRfaW5pdF90IHt9OwpkZWZhdWx0X2luaXRfdCBkZWZhdWx0X2lu
aXQ7Cgp0ZW1wbGF0ZSA8dHlwZW5hbWUgVCwgdHlwZW5hbWUgPSB2b2lkPgpzdHJ1Y3QgbWFrZV91
bmlxdWU7Cgp0ZW1wbGF0ZSA8dHlwZW5hbWUgVD4Kc3RydWN0IG1ha2VfdW5pcXVlPFQsIHR5cGVu
YW1lIHN0ZDo6ZW5hYmxlX2lmPApub3Qgc3RkOjppc19hcnJheTxUPjo6dmFsdWU+Ojp0eXBlPiB7
Cgl0ZW1wbGF0ZSA8dHlwZW5hbWUuLi4gQXJncz4KCW1ha2VfdW5pcXVlKEFyZ3MmJi4uLiBhcmdz
KSA6CgkJcF8obmV3IFQoc3RkOjpmb3J3YXJkPEFyZ3M+KGFyZ3MpLi4uKSkge30KCW1ha2VfdW5p
cXVlKGRlZmF1bHRfaW5pdF90KSA6CgkJcF8obmV3IFQpIHt9CgoJLy8gbmVlZCBtb3JlIHN0dWZm
IHRvIG1ha2UgdGhpbmdzIGxpa2UgdGhpcyB3b3JrCglvcGVyYXRvciBzdGQ6OnVuaXF1ZV9wdHI8
VD4oKSAmJiB7CgkJcmV0dXJuIHN0ZDo6bW92ZShwXyk7Cgl9CgkKCS8vIGZha2UgZXZlcnl0aGlu
ZyB1bmlxdWVfcHRyIGhhcwoJVCYgb3BlcmF0b3IqKCkgewoJCXJldHVybiAqcF87Cgl9Cgpwcml2
YXRlOgoJc3RkOjp1bmlxdWVfcHRyPFQ+IHBfOwp9OwoKdGVtcGxhdGUgPHR5cGVuYW1lIFQ+CnN0
cnVjdCBtYWtlX3VuaXF1ZTxULCB0eXBlbmFtZSBzdGQ6OmVuYWJsZV9pZjwKc3RkOjppc19hcnJh
eTxUPjo6dmFsdWU+Ojp0eXBlPiB7CgltYWtlX3VuaXF1ZSgpIDogYnJhY2VkXyh0cnVlKSB7fQoJ
bWFrZV91bmlxdWUoc2l6ZV90IG4pIDogYnJhY2VkXyhmYWxzZSksIHN6XyhuKSB7fQoKCXRlbXBs
YXRlIDx0eXBlbmFtZS4uLiBBcmdzPgoJYXV0byBvcGVyYXRvcigpKEFyZ3MmJi4uLiBhcmdzKSAt
PiBzdGQ6OnVuaXF1ZV9wdHI8VD4gewoJCXR5cGVkZWYgdHlwZW5hbWUgc3RkOjpyZW1vdmVfZXh0
ZW50PFQ+Ojp0eXBlIFU7CgoJCXJldHVybiBzdGQ6OnVuaXF1ZV9wdHI8VD4oYnJhY2VkXyA/CgkJ
ICAgIG5ldyBVW3NpemVvZi4uLihBcmdzKV17IHN0ZDo6Zm9yd2FyZDxBcmdzPihhcmdzKS4uLiB9
IDoKCQkgICAgbmV3IFVbc3pfXXsgc3RkOjpmb3J3YXJkPEFyZ3M+KGFyZ3MpLi4uIH0pOwoJfQoK
CWF1dG8gb3BlcmF0b3IoKShkZWZhdWx0X2luaXRfdCkgLT4gc3RkOjp1bmlxdWVfcHRyPFQ+IHsK
CQl0eXBlZGVmIHR5cGVuYW1lIHN0ZDo6cmVtb3ZlX2V4dGVudDxUPjo6dHlwZSBVOwoKCQlyZXR1
cm4gc3RkOjp1bmlxdWVfcHRyPFQ+KG5ldyBVW3N6X10pOwoJfQoKcHJpdmF0ZToKCWJvb2wgYnJh
Y2VkXzsKCXNpemVfdCBzel87Cn07Cgp1c2luZyBuYW1lc3BhY2Ugc3RkOwoKdm9pZCBwcmludChj
b25zdCB1bmlxdWVfcHRyPGludFtdPiYgdXApIHsKICAgIGZvciAoaW50IGkgPSAwOyBpIDwgNTsg
KytpKSB7CiAgICAgICAgY291dCA8PCB1cFtpXSA8PCAiICI7CiAgICB9CgogICAgY291dCA8PCBl
bmRsOwp9CgppbnQgbWFpbigpIHsKICAgIGNvdXQgPDwgKm1ha2VfdW5pcXVlPGludD4oKSA8PCBl
bmRsOwogICAgY291dCA8PCAqbWFrZV91bmlxdWU8aW50PigxNzI5KSA8PCBlbmRsOwogICAgY291
dCA8PCAiXCIiIDw8ICptYWtlX3VuaXF1ZTxzdHJpbmc+KCkgPDwgIlwiIiA8PCBlbmRsOwogICAg
Y291dCA8PCAiXCIiIDw8ICptYWtlX3VuaXF1ZTxzdHJpbmc+KCJtZW93IikgPDwgIlwiIiA8PCBl
bmRsOwogICAgY291dCA8PCAiXCIiIDw8ICptYWtlX3VuaXF1ZTxzdHJpbmc+KDYsICd6JykgPDwg
IlwiIiA8PCBlbmRsOwoKICAgIGNvdXQgPDwgKm1ha2VfdW5pcXVlPGludD4oZGVmYXVsdF9pbml0
KSA8PCBlbmRsOwogICAgY291dCA8PCAiXCIiIDw8ICptYWtlX3VuaXF1ZTxzdHJpbmc+KGRlZmF1
bHRfaW5pdCkgPDwgIlwiIiA8PCBlbmRsOwoKICAgIHByaW50KG1ha2VfdW5pcXVlPGludFtdPns1
fSgpKTsKICAgIHByaW50KG1ha2VfdW5pcXVlPGludFtdPns1fShkZWZhdWx0X2luaXQpKTsKICAg
IHByaW50KG1ha2VfdW5pcXVlPGludFtdPns1fSgxMDAsIDIwMCwgMzAwKSk7CiAgICBwcmludCht
YWtlX3VuaXF1ZTxpbnRbXT57fSgxMTEsIDIyMiwgMzMzLCA0NDQsIDU1NSkpOwp9Cg==
--bcaec554de865c2b3504d8754297--

.

On Thu, Mar 21, 2013 at 4:34 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Thu, Mar 21, 2013 at 2:57 PM, Zhihao Yuan <lichray@gmail.com> wrote:
>> Regards make_unique as a class template with an operator(), and the
>> object holds a size and a bool (saying whether we have the sized passed).
>
> Here is something I got to pass all your test cases.  Far from complete, though.

If it's allowed that to inherit from unique_ptr, than this one should work:
https://gist.github.com/lichray/5219299

Well, I don't know whether this syntax is worth or not LOL

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



.

------=_Part_332_12148163.1364228570357
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, March 21, 2013 10:03:39 AM UTC+1, Stephan T. Lavavej wrote:

> I am trying to follow a few principles:
>
> 1. Safety.
> 2. Clarity.
> 3. Symmetry with new-expressions, which this is wrapping.
>
> I don't want to reinvent vector. (In fact, I am personally not fond of
> unique_ptr<T[]>. I recognize that it is zero-overhead and may be useful in
> certain situations, especially because it can release(), but I have never
> encountered a situation in my own code where I would want to use it instead
> of vector.)
>
>
I'd love to see a shared_array (with size, begin, end, etc) though. Using
shared_ptr and unique_ptr for arrays seems kinda weird.

--

---
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_332_12148163.1364228570357
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, March 21, 2013 10:03:39 AM UTC+1, Stephan T. Lavavej wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">I am trying to follow a few p=
rinciples: <br> <br>1. Safety. <br>2. Clarity. <br>3. Symmetry with new-exp=
ressions, which this is wrapping. <br> <br>I don't want to reinvent vector.=
 (In fact, I am personally not fond of unique_ptr&lt;T[]&gt;. I recognize t=
hat it is zero-overhead and may be useful in certain situations, especially=
 because it can release(), but I have never encountered a situation in my o=
wn code where I would want to use it instead of vector.) <br><br></blockquo=
te><div><br></div><div>I'd love to see a shared_array (with size, begin, en=
d, etc) though. Using shared_ptr and unique_ptr for arrays seems kinda weir=
d.</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_332_12148163.1364228570357--

.

------=_Part_3681_1666724.1364229336919
Content-Type: text/plain; charset=ISO-8859-1



On Friday, March 22, 2013 6:25:19 AM UTC, Zhihao Yuan wrote:
>
> On Thu, Mar 21, 2013 at 4:34 PM, Zhihao Yuan <lic...@gmail.com<javascript:>>
> wrote:
> > On Thu, Mar 21, 2013 at 2:57 PM, Zhihao Yuan <lic...@gmail.com<javascript:>>
> wrote:
> >> Regards make_unique as a class template with an operator(), and the
> >> object holds a size and a bool (saying whether we have the sized
> passed).
> >
> > Here is something I got to pass all your test cases.  Far from complete,
> though.
>
> If it's allowed that to inherit from unique_ptr, than this one should
> work:
> https://gist.github.com/lichray/5219299
>
> Well, I don't know whether this syntax is worth or not LOL
>

That is horrible.

If I use make_unique<X>() as an argument of a function template I want it
to deduce the type as std::unique_ptr<X> not some other type.



--

---
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_3681_1666724.1364229336919
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, March 22, 2013 6:25:19 AM UTC, Zhihao Yuan wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Thu, Mar 21, 2013 at 4:34 PM, Zhih=
ao Yuan &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"vA-NTCcsitgJ">lic...@gmail.com</a>&gt; wrote: <br>&gt; On Thu, Mar 21, =
2013 at 2:57 PM, Zhihao Yuan &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"vA-NTCcsitgJ">lic...@gmail.com</a>&gt; wrote: <br>=
&gt;&gt; Regards make_unique as a class template with an operator(), and th=
e <br>&gt;&gt; object holds a size and a bool (saying whether we have the s=
ized passed). <br>&gt; <br>&gt; Here is something I got to pass all your te=
st cases. &nbsp;Far from complete, though. <br> <br>If it's allowed that to=
 inherit from unique_ptr, than this one should work: <br><a href=3D"https:/=
/gist.github.com/lichray/5219299" target=3D"_blank">https://gist.github.com=
/<wbr>lichray/5219299</a> <br> <br>Well, I don't know whether this syntax i=
s worth or not LOL <br></blockquote><div><br>That is horrible.<br><br>If I =
use make_unique&lt;X&gt;() as an argument of a function template I want it =
to deduce the type as std::unique_ptr&lt;X&gt; not some other type.<br><br>=
&nbsp;<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_3681_1666724.1364229336919--

.

On Mon, Mar 25, 2013 at 12:35 PM, Jonathan Wakely <cxx@kayari.org> wrote:
> That is horrible.
>
> If I use make_unique<X>() as an argument of a function template I want it to
> deduce the type as std::unique_ptr<X> not some other type.

Unless you do a `is_same<>`, you can't tell they are the same type or not.
Because if T is implicitly convertible from U, then U's possible value is
a subset of T; and if T is implicitly convertible to U at the same time,
then T's possible value set is as same as U's.

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



.

------=_Part_1429_13449248.1364296049447
Content-Type: text/plain; charset=ISO-8859-1



On Monday, March 25, 2013 8:41:22 PM UTC, Zhihao Yuan wrote:
>
> On Mon, Mar 25, 2013 at 12:35 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> > That is horrible.
> >
> > If I use make_unique<X>() as an argument of a function template I want
> it to
> > deduce the type as std::unique_ptr<X> not some other type.
>
> Unless you do a `is_same<>`, you can't tell they are the same type or not.
>

Really?

template<typename T>
void foo(std::unique_ptr<T>);  // handle unique_ptr

template<typename T>
void foo(T);  // handle everything else

Now if I call foo(make_unique<X>()) it calls the wrong overload.

Because if T is implicitly convertible from U, then U's possible value is
> a subset of T; and if T is implicitly convertible to U at the same time,
> then T's possible value set is as same as U's.
>

Yes, I understand how implicit conversions work, but implicit conversions
don't get used in all contexts.

std::make_unique should be a function that returns std::unique_ptr.

--

---
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_1429_13449248.1364296049447
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, March 25, 2013 8:41:22 PM UTC, Zhihao Yuan wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Mon, Mar 25, 2013 at 12:35 PM, Jon=
athan Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"onN1TXM17kwJ">c...@kayari.org</a>&gt; wrote: <br>&gt; That is horr=
ible. <br>&gt; <br>&gt; If I use make_unique&lt;X&gt;() as an argument of a=
 function template I want it to <br>&gt; deduce the type as std::unique_ptr=
&lt;X&gt; not some other type. <br> <br>Unless you do a `is_same&lt;&gt;`, =
you can't tell they are the same type or not. <br></blockquote><div><br>Rea=
lly?<br><br>template&lt;typename T&gt;<br>void foo(std::unique_ptr&lt;T&gt;=
);&nbsp; // handle unique_ptr<br><br>template&lt;typename T&gt;<br>void foo=
(T);&nbsp; // handle everything else<br>&nbsp;<br>Now if I call foo(make_un=
ique&lt;X&gt;()) it calls the wrong overload.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">Because if T is implicitly convertible from U,=
 then U's possible value is <br>a subset of T; and if T is implicitly conve=
rtible to U at the same time, <br>then T's possible value set is as same as=
 U's. <br></blockquote><div></div><br>Yes, I understand how implicit conver=
sions work, but implicit conversions don't get used in all contexts.<br><br=
>std::make_unique should be a function that returns std::unique_ptr.<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_1429_13449248.1364296049447--

.

2013/3/26 Jonathan Wakely <cxx@kayari.org>:
> On Monday, March 25, 2013 8:41:22 PM UTC, Zhihao Yuan wrote:
>> Because if T is implicitly convertible from U, then U's possible value is
>> a subset of T; and if T is implicitly convertible to U at the same time,
>> then T's possible value set is as same as U's.
>
>
> Yes, I understand how implicit conversions work, but implicit conversions
> don't get used in all contexts.
>
> std::make_unique should be a function that returns std::unique_ptr.

Yes, I think this approach should be used as we have for all other
"make_" templates in the library. It would be quite surprising to
deviate here for a std::unique_ptr generator.

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



.

On Tue, Mar 26, 2013 at 7:07 AM, Jonathan Wakely <cxx@kayari.org> wrote:
> template<typename T>
> void foo(std::unique_ptr<T>);  // handle unique_ptr
>
> template<typename T>
> void foo(T);  // handle everything else

Of course you can catch this, and conversion can also be re-enabled
for this need.  A more useful case may be:

  template<typename T>
  void foo(T*);  // this works

Anyway, it's not worth.

--
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 26 March 2013 15:57, Zhihao Yuan <lichray@gmail.com> wrote:
> On Tue, Mar 26, 2013 at 7:07 AM, Jonathan Wakely <cxx@kayari.org> wrote:
>> template<typename T>
>> void foo(std::unique_ptr<T>);  // handle unique_ptr
>> template<typename T>
>> void foo(T);  // handle everything else
> Of course you can catch this, and conversion can also be re-enabled
> for this need.  A more useful case may be:

A conversion? Such a SFINAE case will not invoke any conversion, it'll deduce
to the everything-else 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_277_17665061.1364510878955
Content-Type: text/plain; charset=ISO-8859-1

I find the functor syntax a little odd, and prone to user error.
  auto array = make_unique<string[]>(5);
  array[0] = "hello"; // error, huh?

I expect "make_unique" to model "new" as close as possible

I find these very clear.
  make_unique<T>(default_init)      // models: new T
  make_unique<T>(args...)           // models: new T(args...)
  make_unique_from_list<T>(args...) // models: new T{args...}; got a better
name?

I would suggest these for fixed size arrays, as they model the "new" syntax
as close as possible.
  make_unique<T[N]>(default_init) // models: new T[N]
  make_unique<T[N]>(args...)      // models: new T[N]{args...}
  make_unique<T[]>(args...)       // auto-sizing, models: new T[]{args...}

The problem with the above is, there's no runtime size version, so...
  make_unique_array<T>(n, default_init) // models: new T[n]
  make_unique_array<T>(n, args...)      // models: new T[n]{args...}

Still fixed size at compile time, but now we're clear on behavior.
  make_unique_array<T>(auto_size, args...) // models: new T[]{args...}

Anyone using auto-complete/intellisense will see the make_*_array versions
and know immediately what to use.

Seperating array types completely might be better, as unique_ptr<T[]> would
have been better as unique_array<T> considering is has a different
interface than it's non-specialized version.  Consider:

  make_unique<T> -> unique_ptr<T>
  make_shared<T> -> shared_ptr<T>

  make_unique_array<T> -> unique_array<T>
  make_shared_array<T> -> shared_array<T>

  unique_ptr<T[]> // (deprecated)

This makes the interfaces clearer, with less trying to do everything in one
place.  Or, we could add an array specialization for shared_ptr, and get
something like this:

  make_unique<T | (T[] | T[N])> -> unique_ptr<T | T[]>
  make_shared<T | (T[] | T[N])> -> shared_ptr<T | T[]>

  make_unique_array<T> -> unique_ptr<T[]>
  make_shared_array<T> -> shared_ptr<T[]>

The above changes a little if we're dead set against T[N], but I disagree
that returning a *_ptr<T[]> from make_*<T[N]> is a problem.  It is no more
confusing than "new T[N]" returning a T* instead of T(*)[N].  If T[] was a
complete type, and "new T[N]" returned that, then I could agree.

T[] as a complete type, now that would be cool:
  template<class T> void free_some_space(T t) { delete t; }
  auto var = new int[]{1,2,3};
  free_some_space(var); // we know var is a int[], so we do the right thing
No more need for specialized deleters for arrays.  I can only dream, or
wait for the new C++...

On Thursday, March 21, 2013 5:03:39 AM UTC-4, Stephan T. Lavavej wrote:
>
> I am trying to follow a few principles:
>
> 1. Safety.
> 2. Clarity.
> 3. Symmetry with new-expressions, which this is wrapping.
>
> I don't want to reinvent vector. (In fact, I am personally not fond of
> unique_ptr<T[]>. I recognize that it is zero-overhead and may be useful in
> certain situations, especially because it can release(), but I have never
> encountered a situation in my own code where I would want to use it instead
> of vector.)
>
> As I explained in N3588, I believe that make_unique<T> and
> make_unique<T[]> should value-init, for safety. Default-init (aka
> garbage-init) is dangerous, and should be explicitly requested.
>
> The Core Language doesn't have syntax for new-expressions that allocates N
> elements, all initialized to T. Therefore, I do not believe that such
> syntax should be invented for make_unique<T[]>. (auto-size is novel, but
> there I just think Core is deficient and will be corrected eventually.)
>
> I like the name "make_unique_with" - that hadn't occurred to me, and it
> may be useful. I'll keep it in mind!
>
> I am currently considering new syntax, in order to improve clarity (and
> possibly solve the friendship problem):
>
> make_unique<T>(args...)      // unchanged
> make_unique<T>(default_init) // instead of make_unique_default_init<T>()
>
> make_unique<T[]>(n)(args...)      // instead of make_unique<T[]>(n) and
> make_unique_value_init<T[]>(n, args...)
> make_unique<T[]>(n)(default_init) // instead of
> make_unique_default_init<T[]>(n)
> make_unique<T[]>()(args...)       // instead of
> make_unique_auto_size<T[]>(args...)
>
> Thanks,
> STL
>
> -----Original Message-----
> From: Zhihao Yuan [mailto:lic...@gmail.com <javascript:>]
> Sent: Wednesday, March 20, 2013 7:46 AM
> To: Stephan T. Lavavej
> Cc: std-pr...@isocpp.org <javascript:>
> Subject: Some words on N3588, make_unique
>
> Hi, STL:
>
> Indeed the proposal covers the most possible needs of the users,
> while IMHO, to make the use similar to STL the library may be
> more helpful.  Say:
>
>   vector<T>(sz)  // value init with a size
>   vector<T>(sz, value)  // init all to `value`
>   vector<T>{...}  // uniform (element-by-element in this case)
>
> In our case, I think we can just make the first overload
>
>   make_unique<T[]>(sz)  // do default initialization
>
> and keep the second overload
>
>   make_unique<T[]>(sz, value)  // use T() instead of value to get value
> init
>
> and distinguished uniform init from them
>
>   make_unique_with<T[]>(v1, v2, ...)  // like auto-size
>
> Comments?
>
> --
> 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.



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

I find the functor syntax a little odd, and prone to user error.<br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> array </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> make_unique</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">[]&gt;(</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; array</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=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=
: #080;" class=3D"styled-by-prettify">"hello"</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// error, huh?</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><br>I expect "make_uniqu=
e" to model "new" as close as possible<br><br>I find these very clear.<br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; make_u=
nique</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">default_init</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp; &nbsp;</span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// models: new T</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; make=
_unique</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// model=
s: new T(args...)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; make_unique_from_list</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// models: =
new T{args...}; got a better name?</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>I would suggest t=
hese for fixed size arrays, as they model the "new" syntax as close as poss=
ible.<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 class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nb=
sp; make_unique</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">N</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]&gt;(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">default_init</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: #800;" =
class=3D"styled-by-prettify">// models: new T[N]</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; make_unique</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">N</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">]&gt;(</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> &nbsp; &nbsp; &nbsp;</span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// models: new T[N]{args...}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp; make_unique</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">[]&gt;(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">args</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// auto-sizing, models: new T[]{args...}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></co=
de></div><br>The problem with the above is, there's no runtime size version=
, so...<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">&=
nbsp; make_unique_array</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">n</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> default_init</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: #=
800;" class=3D"styled-by-prettify">// models: new T[n]</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; make_unique_array</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">n</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> args</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> &nbsp; &nbsp; &nbsp;</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// models: new T[n]{args...}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br=
>Still fixed size at compile time, but now we're clear on behavior.<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">&nbsp; make_uniq=
ue_array</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">auto_size</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> args</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: #800;" class=
=3D"styled-by-prettify">// models: new T[]{args...}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>=
Anyone using auto-complete/intellisense will see the make_*_array versions =
and know immediately what to use.<br><br>Seperating array types completely =
might be better, as unique_ptr&lt;T[]&gt; would have been better as unique_=
array&lt;T&gt; considering is has a different interface than it's non-speci=
alized version.&nbsp; Consider:<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">&nbsp; make_unique</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 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">T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; make_shar=
ed</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> shared_ptr</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br>&nbsp; make_unique_array</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 unique_array</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; make_sh=
ared_array</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> shared_array</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br>&nbsp; unique_ptr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[]&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// (deprecated)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></div></code></div><br>This makes the interf=
aces clearer, with less trying to do everything in one place.&nbsp; Or, we =
could add an array specialization for shared_ptr, and get something like th=
is:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">&=
nbsp; make_unique</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T </span><span style=3D"color: #660;" class=3D"styled-by-prettify">|</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</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: #660;" class=3D"style=
d-by-prettify">|</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">N</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">])&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> 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">T </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">|</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[]&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp; make_shared</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">T </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: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">|</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">N<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">])&gt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> shared_ptr</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">T </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">|</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">[]&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br>&nbsp; make_unique_array</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 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">T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">[]&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; make_sh=
ared_array</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> shared_ptr</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">[]&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>The above changes=
 a little if we're dead set against T[N], but I disagree that returning a *=
_ptr&lt;T[]&gt; from make_*&lt;T[N]&gt; is a problem.&nbsp; It is no more c=
onfusing than "new T[N]" returning a T* instead of T(*)[N].&nbsp; If T[] wa=
s a complete type, and "new T[N]" returned that, then I could agree.<br><br=
>T[] as a complete type, now that would be cool:<br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">&nbsp; </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> free=
_some_space</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T t</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">delete</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </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; </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">var</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=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: #008;" class=3D"style=
d-by-prettify">new</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]{</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; free_some_space</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">var</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// we kno=
w var is a int[], so we do the right thing</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div>No more need =
for specialized deleters for arrays.&nbsp; I can only dream, or wait for th=
e new C++...<br><br>On Thursday, March 21, 2013 5:03:39 AM UTC-4, Stephan T=
.. Lavavej wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I am trying to=
 follow a few principles:
<br>
<br>1. Safety.
<br>2. Clarity.
<br>3. Symmetry with new-expressions, which this is wrapping.
<br>
<br>I don't want to reinvent vector. (In fact, I am personally not fond of =
unique_ptr&lt;T[]&gt;. I recognize that it is zero-overhead and may be usef=
ul in certain situations, especially because it can release(), but I have n=
ever encountered a situation in my own code where I would want to use it in=
stead of vector.)
<br>
<br>As I explained in N3588, I believe that make_unique&lt;T&gt; and make_u=
nique&lt;T[]&gt; should value-init, for safety. Default-init (aka garbage-i=
nit) is dangerous, and should be explicitly requested.
<br>
<br>The Core Language doesn't have syntax for new-expressions that allocate=
s N elements, all initialized to T. Therefore, I do not believe that such s=
yntax should be invented for make_unique&lt;T[]&gt;. (auto-size is novel, b=
ut there I just think Core is deficient and will be corrected eventually.)
<br>
<br>I like the name "make_unique_with" - that hadn't occurred to me, and it=
 may be useful. I'll keep it in mind!
<br>
<br>I am currently considering new syntax, in order to improve clarity (and=
 possibly solve the friendship problem):
<br>
<br>make_unique&lt;T&gt;(args...) &nbsp; &nbsp; &nbsp;// unchanged
<br>make_unique&lt;T&gt;(default_init) // instead of make_unique_default_in=
it&lt;T&gt;()
<br>
<br>make_unique&lt;T[]&gt;(n)(args...) &nbsp; &nbsp; &nbsp;// instead of ma=
ke_unique&lt;T[]&gt;(n) and make_unique_value_init&lt;T[]&gt;(n, args...)
<br>make_unique&lt;T[]&gt;(n)(default_<wbr>init) // instead of make_unique_=
default_init&lt;T[]&gt;(<wbr>n)
<br>make_unique&lt;T[]&gt;()(args...) &nbsp; &nbsp; &nbsp; // instead of ma=
ke_unique_auto_size&lt;T[]&gt;(<wbr>args...)
<br>
<br>Thanks,
<br>STL
<br>
<br>-----Original Message-----
<br>From: Zhihao Yuan [mailto:<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"Z_JivR39ELoJ">lic...@gmail.com</a>]=20
<br>Sent: Wednesday, March 20, 2013 7:46 AM
<br>To: Stephan T. Lavavej
<br>Cc: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Z_JivR39ELoJ">std-pr...@isocpp.org</a>
<br>Subject: Some words on N3588, make_unique
<br>
<br>Hi, STL:
<br>
<br>Indeed the proposal covers the most possible needs of the users,
<br>while IMHO, to make the use similar to STL the library may be
<br>more helpful. &nbsp;Say:
<br>
<br>&nbsp; vector&lt;T&gt;(sz) &nbsp;// value init with a size
<br>&nbsp; vector&lt;T&gt;(sz, value) &nbsp;// init all to `value`
<br>&nbsp; vector&lt;T&gt;{...} &nbsp;// uniform (element-by-element in thi=
s case)
<br>
<br>In our case, I think we can just make the first overload
<br>
<br>&nbsp; make_unique&lt;T[]&gt;(sz) &nbsp;// do default initialization
<br>
<br>and keep the second overload
<br>
<br>&nbsp; make_unique&lt;T[]&gt;(sz, value) &nbsp;// use T() instead of va=
lue to get value init
<br>
<br>and distinguished uniform init from them
<br>
<br>&nbsp; make_unique_with&lt;T[]&gt;(v1, v2, ...) &nbsp;// like auto-size
<br>
<br>Comments?
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br>
<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_277_17665061.1364510878955--

.

------=_Part_19_20200211.1364539064108
Content-Type: text/plain; charset=ISO-8859-1

I agree with most of what you said (save for wanting T[N] to be a complete
type. It would have been nice in 98, but there's too much chance for
breaking the world on that one now). But I want to make this note: if the
make_unique taking a `default_init` parameter goes through, can we please
get that into standard library containers too? I once wrote a proposal for
it, but it was also mixed up in fixing the standard library for uniform
initialization, and I ditched that idea in favor of fixing the language
feature itself.

--

---
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_19_20200211.1364539064108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree with most of what you said (save for wanting T[N] to be a complete =
type. It would have been nice in 98, but there's too much chance for breaki=
ng the world on that one now). But I want to make this note: if the make_un=
ique taking a `default_init` parameter goes through, can we please get that=
 into standard library containers too? I once wrote a proposal for it, but =
it was also mixed up in fixing the standard library for uniform initializat=
ion, and I ditched that idea in favor of fixing the language feature itself=
..<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_19_20200211.1364539064108--

.

------=_Part_587_16404895.1364552015367
Content-Type: text/plain; charset=ISO-8859-1

I only wanted T[N] in the case of no make_*_array, as it made the usage
similar to the single object case, but dropping T[N] on the floor is fine
by me, I won't lose any sleep.

So interface-wise, is make_*_array a cleaner interface?

 // guard against is_array<T> == true, and warn to use make_*_array
 make_unique<T>(args...)
 make_unique<T>(default_init)
 make_shared<T>(default_init) // new for make_shared
 make_*_from_list<T>(args...)

 // no guarding needed
 make_*_array<T>(n, default_init)
 // when sizeof...(args) > 0, guarded against is_array<T> == true, warn
about array of arrays init
 make_*_array<T>(n, args...)
 make_*_array<T>(auto_size, args...)

I'm also liking auto_size tag, as it makes the usage very clear, just like
the default_init tag.  How about the *_array interfaces?  I think it would
be fine to have those too. Then function signatures are much clearer about
intention, plus no more need to pass along the size everywhere.

 // make_unique<T> -> unique_ptr<T>
 // make_shared<T> -> shared_ptr<T>
 // make_unique_array<T> -> unique_array<T>
 // make_shared_array<T> -> shared_array<T>

 template<class T> T rand_pick(unique_array<T> objects); // better than
below
 template<class T> T rand_pick(unique_ptr<T[]> objects, int size); // ugly

 // hopefully
 unique_ptr<T[]>; // (specialization deprecated, use base interface)

 // also
 unique_array<T>; // can explicitly decay to a unique_ptr<T[]>
 shared_array<T>; // can explicitly decay to a shared_ptr<T[]>, with a
proper deleter

Also unique_array has a concise interface, unlike unique_ptr. It's also the
exact same number of characters, so there's no extra typing involved for
the user.  I'm not sure I like the implicit conversions, but if
unique_ptr<T[]>'s specialization isn't deprecated, then that might be the
way to go.  I really dislike the unique_ptr<T[]> though, since it has a
difference interface, and requires a specialized deleter to go with it.

I've been using something like make_shared_array in my own code to pass
around arrays, since make_shared<vector> allows the recipient to add or
remove values.  make_shared_array also removes one more layer on
indirection, because we can imbed the control block in the beginning of a
bigger array, and offset accordingly.  aligned_storage is your friend.

Side bar:
It's 2013 and there's still no way to query the run-time about the size of
an array, one that it allocated and is keeping track of.  Now that would be
nice:
auto arr = new int[20];
auto size = sizeofarray(arr); // yeah!!
They we could stop duplicating the size of the array everywhere.  vector
would implicitly know its capacty and be a smaller object.

On Friday, March 29, 2013 2:37:44 AM UTC-4, Nicol Bolas wrote:
>
> I agree with most of what you said (save for wanting T[N] to be a complete
> type. It would have been nice in 98, but there's too much chance for
> breaking the world on that one now). But I want to make this note: if the
> make_unique taking a `default_init` parameter goes through, can we please
> get that into standard library containers too? I once wrote a proposal for
> it, but it was also mixed up in fixing the standard library for uniform
> initialization, and I ditched that idea in favor of fixing the language
> feature itself.
>

--

---
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_587_16404895.1364552015367
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I only wanted <code><span style=3D"color:#000">T[N]</span></code> in the ca=
se of no <code><span style=3D"color:#000">make_*_array</span></code>, as it=
 made the usage similar to the single object case, but dropping <code><span=
 style=3D"color:#000">T[N]</span></code> on the floor is fine by me, I won'=
t lose any sleep.<br><br>So interface-wise, is <code><span style=3D"color:#=
000">make_*_array</span></code> a cleaner interface?<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// guard against is_array&lt;T&=
gt; =3D=3D true, and warn to use make_*_array</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>&nbsp;make_unique</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">args</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">...)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp;make_unique</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">default_init</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code c=
lass=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">&nbsp;</span></code><span style=3D"color: #=
000;" class=3D"styled-by-prettify">make_shared</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">default_init</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// new for make_shared</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></code>&nbsp;make_*_from_list</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">args</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// no guarding need=
ed</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp;</span><=
/code></code></span></code>make_*_array</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">n</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> default=
_init</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prett=
yprint"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">&nbsp;</span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// </span></code></code></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><code class=3D"prettyprint"><code class=3D"pre=
ttyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify"><code c=
lass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><code class=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"=
color: #800;" class=3D"styled-by-prettify">when sizeof...(args) &gt; 0, g</=
span></code></code></span></code>uarded against is_array&lt;T&gt; =3D=3D tr=
ue, warn about array of arrays init</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">&nbsp;</span></code></code>make_*_array</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">n</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> args</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>&nbsp;make_*_array</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">auto_size=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> args</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">...)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"></span><br></div></code></di=
v><br>I'm also liking <code class=3D"prettyprint"><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">auto_size</span></code> tag, as it makes the usage =
very clear, just like the <code class=3D"prettyprint"><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">default_init</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"></span></code></span></co=
de> tag.&nbsp; How about the *_array interfaces?&nbsp; I think it would be =
fine to have those too.  Then function signatures are much clearer about in=
tention, plus no more need to pass along the size everywhere.<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-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #800;" class=3D"styled-by-prettify">&nbsp;// make_uni=
que&lt;T&gt; -&gt; unique_ptr&lt;T&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>&nbsp;</span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">// make_shared&lt;T&gt; -&gt; shared_ptr&lt;T&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// make_=
unique_array&lt;T&gt; -&gt; unique_array&lt;T&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp;</span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// make_shared_array&lt;T&gt; -&gt; =
shared_array&lt;T&gt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br>&nbsp;</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> rand_pick</span><co=
de class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"></span><span style=3D"color: #660;" class=3D"styled-by-prettify"></=
span></code><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">unique_array</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> objects</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// better than below</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp;</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">rand_pick</span></code><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">unique_ptr</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
[]&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> obj=
ects</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">, int size</span></code>);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// ugly<br>&nbsp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>&nbsp;</span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// hopefully</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp;unique_ptr</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[]&gt;;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// (specialization deprecated, use base interface)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp;</span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// also</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;unique_array</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// can explicitly decay to a unique_ptr&lt;T[=
]&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp;shared_array</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">// </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<span style=3D"color: #800;" class=3D"styled-by-prettify">can explicitly</s=
pan></code> decay to a shared_ptr&lt;T[]&gt;, with a proper deleter</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div><br>Also <code class=3D"prettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">unique_array</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"></span></code> has a concise interface, u=
nlike <code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">unique_ptr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"></span></code>.  It's also the exact same number of charac=
ters, so there's no extra typing involved for the user.&nbsp; I'm not sure =
I like the implicit conversions, but if <code class=3D"prettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">unique_ptr&lt;T[]&gt;</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></code=
>'s specialization isn't deprecated, then that might be the way to go.&nbsp=
; I really dislike the <code class=3D"prettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">unique_ptr&lt;T[]&gt;</span></code> thoug=
h, since it has a difference interface, and requires a specialized deleter =
to go with it.&nbsp; <br><br>I've been using something like <code class=3D"=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">make=
_shared_array</span></code> in my own code to pass around arrays, since <co=
de class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">make_shared&lt;vector&gt;</span></code> allows the recipient to add=
 or remove values.&nbsp; <code class=3D"prettyprint"><span style=3D"color: =
#000;" class=3D"styled-by-prettify">make_shared_array</span></code> also re=
moves one more layer on indirection, because we can imbed the control block=
 in the beginning of a bigger array, and offset accordingly.&nbsp; <code cl=
ass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">aligned_storage</span></code> is your friend.<br><br>Side bar:<br>It's 2=
013 and there's still no way to query the run-time about the size of an arr=
ay, one that it allocated and is keeping track of.&nbsp; Now that would be =
nice:<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 class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n 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"col=
or: #000;" class=3D"styled-by-prettify"> </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: #066;" class=3D"style=
d-by-prettify">20</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> size </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> sizeofarray</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">arr</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">); // yeah!!</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div>They w=
e could stop duplicating the size of the array everywhere.&nbsp; vector wou=
ld implicitly know its capacty and be a smaller object.<br><br>On Friday, M=
arch 29, 2013 2:37:44 AM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">I agree with most of what you said (save for wanting T[=
N] to be a complete type. It would have been nice in 98, but there's too mu=
ch chance for breaking the world on that one now). But I want to make this =
note: if the make_unique taking a `default_init` parameter goes through, ca=
n we please get that into standard library containers too? I once wrote a p=
roposal for it, but it was also mixed up in fixing the standard library for=
 uniform initialization, and I ditched that idea in favor of fixing the lan=
guage feature itself.<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_587_16404895.1364552015367--

.

On Fri, Mar 29, 2013 at 11:13 AM, <phernost@gmail.com> wrote:

> Side bar:
> It's 2013 and there's still no way to query the run-time about the size of
> an array, one that it allocated and is keeping track of.  Now that would be
> nice:
> auto arr = new int[20];
> auto size = sizeofarray(arr); // yeah!!
> They we could stop duplicating the size of the array everywhere.  vector
> would implicitly know its capacty and be a smaller object.

Type of arr would be int*, right?
What if it points to something not allocated by the run-time, would
sizeofarray(arr) be undefined behavior? Sounds really unsafe.


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



.

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

So then we're going to removing the delete keyword?  It's unsafe in the=20
same context.
auto crazy =3D (int*)5318008;
auto size =3D sizeofarray(crazy); // what?
delete[] crazy; // crash

Currently the run-time imbeds the size of every array at the beginning of=
=20
the memory block.  If you override new[] you see this with size requests=20
larger than you would expect.  The standard defines this too, new T[N],=20
requests sizeof(T)*N+y, y being implementation defined (=A7 5.3.4 12).  Thi=
s=20
is so it knows how many objects are in the array that need to be=20
destructed.  Clever compilers don't bother with allocating space for the=20
size when the objects have no destructor.  It saves about 8 bytes, but I=20
would prefer to have that be there all the time and a standard way of=20
accessing it.

Internally you would probably see this:
std::size_t sizeofarray( void* ptr )
{ return *( ( std::size_t* )ptr - 1 ); }

So I guess garbage in, garbage out?  No need to crash.

On Sunday, March 31, 2013 10:10:43 AM UTC-4, Olaf van der Spek wrote:
>
> On Fri, Mar 29, 2013 at 11:13 AM, <pher...@gmail.com <javascript:>>=20
> wrote:=20
>
> > Side bar:=20
> > It's 2013 and there's still no way to query the run-time about the size=
=20
> of=20
> > an array, one that it allocated and is keeping track of.  Now that woul=
d=20
> be=20
> > nice:=20
> > auto arr =3D new int[20];=20
> > auto size =3D sizeofarray(arr); // yeah!!=20
> > They we could stop duplicating the size of the array everywhere.  vecto=
r=20
> > would implicitly know its capacty and be a smaller object.=20
>
> Type of arr would be int*, right?=20
> What if it points to something not allocated by the run-time, would=20
> sizeofarray(arr) be undefined behavior? Sounds really unsafe.=20
>
>
> --=20
> Olaf=20
>

--=20

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



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

So then we're going to removing the delete keyword?&nbsp; It's unsafe in th=
e same context.<br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> crazy </span><span style=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: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=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: #=
066;" class=3D"styled-by-prettify">5318008</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: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> size </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> sizeofarray</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">crazy<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// what?</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">delete</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> crazy</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// crash</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br>Currently the run-time imbeds the si=
ze of every array at the beginning of the memory block.&nbsp; If you overri=
de <code class=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">new</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</span></co=
de> you see this with size requests larger than you would expect.&nbsp; The=
 standard defines this too, <code class=3D"prettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">new</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">N</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"></s=
pan></code>, requests <code class=3D"prettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">y</span></code>=
, <code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">y</span></code> being implementation defined (=A7 5.3.4 12).&n=
bsp; This is so it knows how many objects are in the array that need to be =
destructed.&nbsp; Clever compilers don't bother with allocating space for t=
he size when the objects have no destructor.&nbsp; It saves about 8 bytes, =
but I would prefer to have that be there all the time and a standard way of=
 accessing it.<br><br>Internally you would probably see this:<br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">size_t sizeofarray</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: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> ptr </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"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>size_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">ptr </span><span style=3D"co=
lor: #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-by-prettify">1</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br>So I guess garbage in, garbage out?&nbsp; No need to crash.<b=
r><br>On Sunday, March 31, 2013 10:10:43 AM UTC-4, Olaf van der Spek wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Mar 29, 2013 at 11:13 =
AM, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
fHDuVMUs5rQJ">pher...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Side bar:
<br>&gt; It's 2013 and there's still no way to query the run-time about the=
 size of
<br>&gt; an array, one that it allocated and is keeping track of. &nbsp;Now=
 that would be
<br>&gt; nice:
<br>&gt; auto arr =3D new int[20];
<br>&gt; auto size =3D sizeofarray(arr); // yeah!!
<br>&gt; They we could stop duplicating the size of the array everywhere. &=
nbsp;vector
<br>&gt; would implicitly know its capacty and be a smaller object.
<br>
<br>Type of arr would be int*, right?
<br>What if it points to something not allocated by the run-time, would
<br>sizeofarray(arr) be undefined behavior? Sounds really unsafe.
<br>
<br>
<br>--
<br>Olaf
<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_1783_5691999.1364750388314--

.

On Sun, Mar 31, 2013 at 7:19 PM,  <phernost@gmail.com> wrote:
> Currently the run-time

What run-time?

> imbeds the size of every array at the beginning of
> the memory block.

Does ISO C++ require this?

> If you override new[] you see this with size requests
> larger than you would expect.  The standard defines this too, new T[N],
> requests sizeof(T)*N+y, y being implementation defined (=A7 5.3.4 12).  T=
his
> is so it knows how many objects are in the array that need to be destruct=
ed.
> Clever compilers don't bother with allocating space for the size when the
> objects have no destructor.  It saves about 8 bytes, but I would prefer t=
o
> have that be there all the time and a standard way of accessing it.
>
> Internally you would probably see this:
> std::size_t sizeofarray( void* ptr )
> { return *( ( std::size_t* )ptr - 1 ); }
>
> So I guess garbage in, garbage out?  No need to crash.

I wasn't talking about crashing.
What if vector is used with an allocator that doesn't (need to) store this =
size?

--=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_2083_23477196.1364766837661
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


>
> --What if it points to something not allocated by the run-time
> What run-time?
>
=20
Weren't you the one who brought up "run-time"?

-- What if it points to something not allocated by the run-time, would=20
> sizeofarray(arr) be undefined behavior? Sounds really unsafe.=20
> I wasn't talking about crashing.


Unsafe and crashing sound similar to me.

What if vector is used with an allocator that doesn't (need to) store this=
=20
> size?
>

Vector with a smart allocator, wouldn't need to store the size.  Vector=20
with a dumb allocator, would need to store the size.  I'm not saying this=
=20
is worth it just to save 8 bytes off the size of a vector, I was really=20
using vector as an example of duplication of an allocation's size.

Duplication is bad, it increases the chances of errors, and it's a waste of=
=20
space and time.  The size of an allocation is, or should be, the=20
responsibility of the allocator.  This is similar to how the size of a=20
vector is the responsibility of the vector.  Externally it's useful data. =
=20
Internally it's required.

The current definition of an allocator, in the standard, is that deallocate=
=20
must match the same location (p) returned by allocate and the count (n)=20
passed to allocate.  n must be stored locally and passed along at a later=
=20
time.  This comes from when allocators couldn't have local state. =20
Allocators do not allow hole punching, deallocating smaller regions in an=
=20
allocated region, therefore deallocation is an all or nothing approach,=20
just like malloc/free and new/delete.  The standard also says deallocate is=
=20
not allowed to throw, it doesn't say what happens when I pass in a=20
different n.

Smart allocators "should" have a deallocate(p) and an allocation_size(p). =
=20
Which would be much easier to implement if we had something like=20
sizeofarray(p).

sizeofarray is very doable, it's sad it hasn't been done yet.  Fixing=20
allocators, might be easier, since they are just templates, no one would=20
need to rebuild their compiler.

In the mean time, I much rather see unique_array and share_array, with an=
=20
interface similar to std::array.


On Sunday, March 31, 2013 1:53:58 PM UTC-4, Olaf van der Spek wrote:
>
> On Sun, Mar 31, 2013 at 7:19 PM,  <pher...@gmail.com <javascript:>>=20
> wrote:=20
> > Currently the run-time=20
>
> What run-time?=20
>
> > imbeds the size of every array at the beginning of=20
> > the memory block.=20
>
> Does ISO C++ require this?=20
>
> > If you override new[] you see this with size requests=20
> > larger than you would expect.  The standard defines this too, new T[N],=
=20
> > requests sizeof(T)*N+y, y being implementation defined (=A7 5.3.4 12).=
=20
>  This=20
> > is so it knows how many objects are in the array that need to be=20
> destructed.=20
> > Clever compilers don't bother with allocating space for the size when=
=20
> the=20
> > objects have no destructor.  It saves about 8 bytes, but I would prefer=
=20
> to=20
> > have that be there all the time and a standard way of accessing it.=20
> >=20
> > Internally you would probably see this:=20
> > std::size_t sizeofarray( void* ptr )=20
> > { return *( ( std::size_t* )ptr - 1 ); }=20
> >=20
> > So I guess garbage in, garbage out?  No need to crash.=20
>
> I wasn't talking about crashing.=20
> What if vector is used with an allocator that doesn't (need to) store thi=
s=20
> size?=20
>

--=20

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



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

<blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">--What if it poin=
ts to something not allocated by the run-time<br>What run-time?<br></blockq=
uote><div>&nbsp;</div>Weren't you the one who brought up "run-time"?<br><br=
><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb=
(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">-- What if it po=
ints to something not allocated by the run-time, would
sizeofarray(arr) be undefined behavior? Sounds really unsafe.
<br>I wasn't talking about crashing.</blockquote><br>Unsafe and crashing so=
und similar to me.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; b=
order-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmai=
l_quote">What if vector is used with an allocator that doesn't (need to) st=
ore this size?<br></blockquote><div><br>Vector with a smart allocator, woul=
dn't need to store the size.&nbsp; Vector=20
with a dumb allocator, would need to store the size.&nbsp; I'm not saying=
=20
this is worth it just to save 8 bytes off the size of a vector, I was=20
really using vector as an example of duplication of an allocation's=20
size.<br><br>Duplication is bad, it increases the chances of errors, and it=
's a waste of space and time.&nbsp; The size of an allocation is, or should=
 be, the responsibility of the allocator.&nbsp; This is similar to how the =
size of a vector is the responsibility of the vector.&nbsp; Externally it's=
 useful data.&nbsp; Internally it's required.<br><br>The current definition=
 of an allocator, in the standard, is that deallocate must match the same l=
ocation (p) returned by allocate and the count (n) passed to allocate.&nbsp=
; n must be stored locally and passed along at a later time.&nbsp; This com=
es from when allocators couldn't have local state.&nbsp; Allocators do not =
allow hole punching, deallocating smaller regions in an allocated region, t=
herefore deallocation is an all or nothing approach, just like malloc/free =
and new/delete.&nbsp; The standard also says deallocate is not allowed to t=
hrow, it doesn't say what happens when I pass in a different n.<br><br>Smar=
t allocators "should" have a deallocate(p) and an allocation_size(p).&nbsp;=
 Which would be much easier to implement if we had something like sizeofarr=
ay(p).<br><br>sizeofarray is very doable, it's sad it hasn't been done yet.=
&nbsp; Fixing allocators, might be easier, since they are just templates, n=
o one would need to rebuild their compiler.<br><br>In the mean time, I much=
 rather see unique_array and share_array, with an interface similar to std:=
:array.<br><br></div><br>On Sunday, March 31, 2013 1:53:58 PM UTC-4, Olaf v=
an der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Mar =
31, 2013 at 7:19 PM, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"fEeukC6vHXUJ">pher...@gmail.com</a>&gt; wrote:
<br>&gt; Currently the run-time
<br>
<br>What run-time?
<br>
<br>&gt; imbeds the size of every array at the beginning of
<br>&gt; the memory block.
<br>
<br>Does ISO C++ require this?
<br>
<br>&gt; If you override new[] you see this with size requests
<br>&gt; larger than you would expect. &nbsp;The standard defines this too,=
 new T[N],
<br>&gt; requests sizeof(T)*N+y, y being implementation defined (=A7 5.3.4 =
12). &nbsp;This
<br>&gt; is so it knows how many objects are in the array that need to be d=
estructed.
<br>&gt; Clever compilers don't bother with allocating space for the size w=
hen the
<br>&gt; objects have no destructor. &nbsp;It saves about 8 bytes, but I wo=
uld prefer to
<br>&gt; have that be there all the time and a standard way of accessing it=
..
<br>&gt;
<br>&gt; Internally you would probably see this:
<br>&gt; std::size_t sizeofarray( void* ptr )
<br>&gt; { return *( ( std::size_t* )ptr - 1 ); }
<br>&gt;
<br>&gt; So I guess garbage in, garbage out? &nbsp;No need to crash.
<br>
<br>I wasn't talking about crashing.
<br>What if vector is used with an allocator that doesn't (need to) store t=
his size?
<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_2083_23477196.1364766837661--

.

------=_Part_151_1566548.1364837724031
Content-Type: text/plain; charset=ISO-8859-1



> In the mean time, I much rather see unique_array and share_array, with an
> interface similar to std::array.
>

What's wrong with std::unique_ptr<std::array<..>> and
std::shared_ptr<std::array<..>>?

As far as I know the only place where std::array is not a good replacement
to plain old arrays is when you encapsulate it into an object, as
std::array might add some extra fields next to the 'array' of data (e.g. an
std::array<std::array<int, 2>, 2> might not have contiguous layout of the
user's ints). And that should be still no problem unless you are writing
something very close to the metal. But if you have a shared/unique pointer
to it, this is not the case.

That said, I don't actually like std::make_shared_array, sizeofarray(),
etc. ideas altogether: I think it is giving the wrong message to encourage
using boring old C style arrays instead of the awesome new C++ style
std::array - I would even deprecate new[] ( go new std::array<..> - or
rather, go std::make_*<std::array<..>> ), but that would probably go too
far.

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_151_1566548.1364837724031
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>In the mean time, I m=
uch rather see unique_array and share_array, with an interface similar to s=
td::array.</div></blockquote><div><br>What's wrong with std::unique_ptr&lt;=
std::array&lt;..&gt;&gt; and std::shared_ptr&lt;std::array&lt;..&gt;&gt;?<b=
r><br>As
 far as I know the only place where std::array is not a good replacement
 to plain old arrays is when you encapsulate it into an object, as=20
std::array might add some extra fields next to the 'array' of data (e.g.
 an std::array&lt;std::array&lt;int, 2&gt;, 2&gt; might not have=20
contiguous layout of the user's ints). And that should be still no=20
problem unless you are writing something very close to the metal. But if
 you have a shared/unique pointer to it, this is not the case.<br><br>That
 said, I don't actually like std::make_shared_array, sizeofarray(), etc.
 ideas altogether: I think it is giving the wrong message to encourage=20
using boring old C style arrays instead of the awesome new C++ style=20
std::array - I would even deprecate new[] ( go new=20
std::array&lt;..&gt; - or rather, go std::make_*&lt;std::array&lt;..&gt;&gt=
; ), but that would probably go too far.<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_151_1566548.1364837724031--

.

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

 std::array is guaranteed to have the same layout as a c style array.=20
std::array servers one purpose, to encapsulate a fixed size c style array=
=20
in a standard container template.=20

std::array< int, 2 > a;=20
auto& ref =3D *reinterpret_cast< int(*)[ 2 ]>( &a );
ref[ 1 ] =3D 3; // a[1] =3D=3D 3

The above, and the reverse cast, will always work. But this won't:=20

int size =3D 5;=20
std::array< int, size > b; // no good=20

So std::array is a replacement only for compile time arrays, which I agree,=
=20
should always be used now. I'd be happy so see a compiler flag for warning=
=20
about compile time arrays and replacing them, optional of course.=20

int b[ 3 ]; // replace with 'std::array< int, 3 > b'=20

make_unique serves the purpose of eliminating the potential for unordered=
=20
construction.=20

f( unique_ptr(new Obj{1}), unique_ptr(new Obj{2}) );=20

If Obj's constructor, or one of the new operators, throws an exception, we=
=20
will most likely have a leak.=20

f( make_unique<Obj>(1), make_unique<Obj>(2) );=20

No chances of leaks now, plus an interface that shares similarity to the=20
already existing make_shared.=20

The purpose of a unique_ptr is to have a single reference to an object.=20
This breaks when an array is concerned.=20

auto arr =3D unique_ptr< array< string, 4 > >( new array< string, 4 > );=20
arr[ 0 ] =3D "1"; // error?, ah it's a pointer to an object=20
( * arr )[ 1 ] =3D "2"; // ok, it points to a array< string, 4 >=20
arr->operator[]( 2 ) =3D "3"; // convoluted, but sensible=20

auto arr2 =3D unique_ptr< string[] >( new string[ 4 ] );=20
arr2[ 0 ] =3D "1"; // works now? what happened to pointing to an object?=20
( * arr2 )[ 1 ] =3D "2"; // error? it's not pointing to a string[]?=20
arr2.operator[]( 2 ) =3D "3"; // convoluted, nonsensical=20

I believe the second shouldn't exist. In the second, unique_ptr is no=20
longer acting like a pointer to a single object. If unique_ptr was supposed=
=20
to act like a naked pointer, then arr[ 0 ] would have referenced=20
unallocated memory, which we don't want, so it doesn't emulate a naked=20
pointer. If you really want a reference to an array of objects, then a=20
better type is need.=20

auto arr3 =3D unique_array< string >( 4 );=20
*arr3 =3D "0"; // error, it's not a pointer, it's an array=20
arr3[ 1 ] =3D "2"; // no bounds checking=20
arr3.at( 2 ) =3D "3"; // bounds checking=20

This behaves exactly like std::array, but for run-time fixed size arrays.=
=20
shared_array being the same, but with shared semantics. Looking at the=20
above, I no longer see a need for make_unique_array or make_shared_array,=
=20
the constructors of *_array serve the original purpose of make_*_array, and=
=20
perform the purpose of eliminating the potential for unordered=20
construction. I'd like *_array to also support allocators, then their=20
usefulness is much higher.=20

auto arr4 =3D new string[4];=20

// In my dreams=20
//arr3.reset( arr4 );=20

arr3.reset(arr4, 4);=20

// In my dreams=20
//auto arr5 =3D unique_array< string >( arr3.release() );=20

auto arr5 =3D unique_array< string >( arr4.release(), 4 );=20
auto arr6 =3D unique_array< string >( move( arr5 ) );=20
auto arr7 =3D shared_array< string >( move( arr6 ) );=20

This completely replaces the need for new[], although it still allows=20
interacting with it.=20

*Allocation Side Bar: *

allocator.allocation_size(p) would make unique_array have a cleaner=20
interface and same size as a naked array. After the previous discussion,=20
sizeofarray (I haven't thought of a better name) should be like this:

template< typename T >=20
size_t sizeofarray( T* p ) { return std::allocator< T >{}.allocation_size(p
); }=20

Then again, I'd like to new/delete wrap std::allocator, not the other-way=
=20
around.

Allocators should know the size of their allocations. It's an internal=20
detail, that should have external visibility. Forcing the allocation size=
=20
to be external is just increasing the chance of errors, for no good reason.=
=20
I may be just lazy, but I don't think it's the responsibility of the user=
=20
to repeatedly tell the computer how much ram it's used, especially when it=
=20
already knows. It's playing a catch 22 with the allocator. malloc knows how=
=20
big it's allocations are, thats why free only needs a pointer. new knows=20
how big it's allocations are, thats why delete only need a pointer, since=
=20
it's most likely wrapping malloc.=20

As I stated before, the standard say that new T[N] allocates sizeof(T)*N+y,=
=20
where y is the header and implementation defined. This is the same for=20
placement new[], which makes it absolutely useless because y is undefined.=
=20
The header information stores the size of the array, so that the correct=20
number of destructors are called before deallocating. This is why we needed=
=20
delete instead of free in the first place. The header also typically=20
contains padding to maintain alignment of T. If T has no destructor, the=20
header usually doesn't store the size, making y smaller. The work is=20
already done for recording the allocation size, give me access to it, I=20
don't need to duplicate it. This would of course force new[] to record the=
=20
size of the array even for types without destructors. This also makes=20
bounds checking easier, which I seem to remember a lot a people saying was=
=20
important for security.=20

Failing to have allocator.allocation_size(p), unique_array would just be=20
sizeof(size_t) bigger, not the end of the world, but people still complain=
=20
about vector being the size of 3 pointers. If unique_array is the same=20
overhead and size as a native array, it's adoption will be similar to that=
=20
of unique_ptr, not much resistance at all.

On Monday, April 1, 2013 1:35:24 PM UTC-4, R=F3bert D=E1vid wrote:
>
>
> In the mean time, I much rather see unique_array and share_array, with an=
=20
>> interface similar to std::array.
>>
>
> What's wrong with std::unique_ptr<std::array<..>> and=20
> std::shared_ptr<std::array<..>>?
>
> As far as I know the only place where std::array is not a good replacemen=
t=20
> to plain old arrays is when you encapsulate it into an object, as=20
> std::array might add some extra fields next to the 'array' of data (e.g. =
an=20
> std::array<std::array<int, 2>, 2> might not have contiguous layout of the=
=20
> user's ints). And that should be still no problem unless you are writing=
=20
> something very close to the metal. But if you have a shared/unique pointe=
r=20
> to it, this is not the case.
>
> That said, I don't actually like std::make_shared_array, sizeofarray(),=
=20
> etc. ideas altogether: I think it is giving the wrong message to encourag=
e=20
> using boring old C style arrays instead of the awesome new C++ style=20
> std::array - I would even deprecate new[] ( go new std::array<..> - or=20
> rather, go std::make_*<std::array<..>> ), but that would probably go too=
=20
> far.
>
> 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_304_13227013.1364849263461
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

 std::array is guaranteed to have the same layout as a c style array. std::=
array servers one purpose, to encapsulate a fixed size c style array in a s=
tandard container template. <br><br> <div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">array</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> a</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: #008;" class=3D"styled-by-prettify">auto=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">reinterpret_cast</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </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><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">]&gt;(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">a </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </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: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</s=
pan><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: #800;" class=3D"styled-by-prettify">// a[1] =3D=3D 3</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div><br>The above, and the reverse cast, will always work. But this won't:=
 <br><br> <div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> size </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> <br>std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">array</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> size </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// no good </span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><br>So std::array is=
 a replacement only for compile time arrays, which I agree, should always b=
e used now. I'd be happy so see a compiler flag for warning about compile t=
ime arrays and replacing them, optional of course. <br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> b</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"style=
d-by-prettify">3</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">];<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// replace with 'std=
::array&lt; int, 3 &gt; b' </span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br>make_unique serves the p=
urpose of eliminating the potential for unordered construction. <br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> unique_ptr</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">new</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Obj</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}),</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> unique_ptr</s=
pan><span style=3D"color: #660;" 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"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Obj</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">})</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br></spa=
n></div></code></div><br>If Obj's constructor, or one of the new operators,=
 throws an exception, we will most likely have a leak. <br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> make_unique</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Obj</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> make_unique</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ob=
j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">2</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: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> <br></span></div></code></div><br>No chances of =
leaks now, plus an interface that shares similarity to the already existing=
 make_shared. <br><br>The purpose of a unique_ptr is to have a single refer=
ence to an object. This breaks when an array is concerned. <br><br> <div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> arr </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> unique_ptr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=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: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">string</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #00=
0;" 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"sty=
led-by-prettify"> array</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
ring</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> <br>arr</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </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: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"1"</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// error?,=
 ah it's a pointer to an object </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"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr </sp=
an><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-by-prettify">1</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"2"</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// ok, it points to a array&lt; s=
tring, 4 &gt; </span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>arr</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>-&gt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">oper=
ator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>"3"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// convoluted, but sensi=
ble </span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr2 </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> unique_ptr</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">new</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
br>arr2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </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: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">"1"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// works now? what ha=
ppened to pointing to an object? </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"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr2 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)[</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </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: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"2"</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// error? it's not pointing =
to a string[]? </span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>arr2</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">operat=
or</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"=
3"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// convoluted, nonsensical=
 </span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><br>I believe the second shouldn't exist. In the secon=
d, unique_ptr is no longer acting like a pointer to a single object. If uni=
que_ptr was supposed to act like a naked pointer, then arr[ 0 ] would have =
referenced unallocated memory, which we don't want, so it doesn't emulate a=
 naked pointer. If you really want a reference to an array of objects, then=
 a better type is need. <br><br> <div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> arr3 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> unique_array</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> <br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">arr3 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">"0"</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// error, it's not a pointer, it's an array =
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>arr3</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </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: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"2"</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// no bounds checking </span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>arr3</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">at</span><span style=3D"col=
or: #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-by-prettify">2</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"3"</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// bounds checking </span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>This beh=
aves exactly like std::array, but for run-time fixed size arrays. shared_ar=
ray being the same, but with shared semantics. Looking at the above, I no l=
onger see a need for make_unique_array or make_shared_array, the constructo=
rs of *_array serve the original purpose of make_*_array, and perform the p=
urpose of eliminating the potential for unordered construction. I'd like *_=
array to also support allocators, then their usefulness is much higher. <br=
><br> <div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr4 </span=
><span style=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: #008;" class=3D"styled-by-prettify">new</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">4</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
In my dreams </span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//a=
rr3.reset( arr4 ); </span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br>arr3</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">reset</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">arr4</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> <br><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// In my dreams </span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//auto arr5 =3D unique_array&lt; string &gt;( arr3.=
release() ); </span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr5=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> unique_array</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> arr4</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">release</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </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"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> arr6 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> unique_array</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">string</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mo=
ve</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> arr5 </span><spa=
n 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=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> <br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> arr7 </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> shared_array</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">stri=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> move</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> arr6 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> <br></span></div></code></div><br>This completely replaces the ne=
ed for new[], although it still allows interacting with it. <br><br><i>Allo=
cation Side Bar: </i><br><br>allocator.allocation_size(p) would make unique=
_array have a cleaner interface and same size as a naked array. After the p=
revious discussion, sizeofarray  (I haven't thought of a better name) shoul=
d be like 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 class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typena=
me</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> <br>size_t sizeofarr=
ay</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> p </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
turn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">allocator</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;{}.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">allocation_size</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
<br></span></div></code></div><br>Then again, I'd like to new/delete wrap s=
td::allocator, not the other-way around.<br><br>Allocators should know the =
size of their allocations. It's an internal detail, that should have extern=
al visibility. Forcing the allocation size to be external is just increasin=
g the chance of errors, for no good reason. I may be just lazy, but I don't=
 think it's the responsibility of the user to repeatedly tell the computer =
how much ram it's used, especially when it already knows. It's playing a ca=
tch 22 with the allocator. malloc knows how big it's allocations are, thats=
 why free only needs a pointer. new knows how big it's allocations are, tha=
ts why delete only need a pointer, since it's most likely wrapping malloc. =
<br><br>As I stated before, the standard say that new T[N] allocates sizeof=
(T)*N+y, where y is the header and implementation defined. This is the same=
 for placement new[], which makes it absolutely useless because y is undefi=
ned. The header information stores the size of the array, so that the corre=
ct number of destructors are called before deallocating. This is why we nee=
ded delete instead of free in the first place. The header also typically co=
ntains padding to maintain alignment of T. If T has no destructor, the head=
er usually doesn't store the size, making y smaller. The work is already do=
ne for recording the allocation size, give me access to it, I don't need to=
 duplicate it. This would of course force new[] to record the size of the a=
rray even for types without destructors. This also makes bounds checking ea=
sier, which I seem to remember a lot a people saying was important for secu=
rity. <br><br>Failing to have allocator.allocation_size(p), unique_array wo=
uld just be sizeof(size_t) bigger, not the end of the world, but people sti=
ll complain about vector being the size of 3 pointers. If unique_array is t=
he same overhead and size as a native array, it's adoption will be similar =
to that of unique_ptr, not much resistance at all.<br><p></p>


On Monday, April 1, 2013 1:35:24 PM UTC-4, 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"><div>In the mean time, I much rather see unique_array and share_array,=
 with an interface similar to std::array.</div></blockquote><div><br>What's=
 wrong with std::unique_ptr&lt;std::array&lt;..&gt;<wbr>&gt; and std::share=
d_ptr&lt;std::array&lt;..&gt;<wbr>&gt;?<br><br>As
 far as I know the only place where std::array is not a good replacement
 to plain old arrays is when you encapsulate it into an object, as=20
std::array might add some extra fields next to the 'array' of data (e.g.
 an std::array&lt;std::array&lt;int, 2&gt;, 2&gt; might not have=20
contiguous layout of the user's ints). And that should be still no=20
problem unless you are writing something very close to the metal. But if
 you have a shared/unique pointer to it, this is not the case.<br><br>That
 said, I don't actually like std::make_shared_array, sizeofarray(), etc.
 ideas altogether: I think it is giving the wrong message to encourage=20
using boring old C style arrays instead of the awesome new C++ style=20
std::array - I would even deprecate new[] ( go new=20
std::array&lt;..&gt; - or rather, go std::make_*&lt;std::array&lt;..&gt;&gt=
; ), but that would probably go too far.<br><br>Regards, Robert<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_304_13227013.1364849263461--

.

This is a multi-part message in MIME format.
--------------060703050903050508070807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 01/04/13 21:47, phernost@gmail.com wrote:
> std::array is guaranteed to have the same layout as a c style array.
> std::array servers one purpose, to encapsulate a fixed size c style
> array in a standard container template.
>
> |
> std::array<int,2>a;
> auto&ref=*reinterpret_cast<int(*)[2]>(&a );
> ref[1]=3;// a[1] == 3
> |
>
> The above, and the reverse cast, will always work. But this won't:
>
> |
> intsize =5;
> std::array<int,size >b;// no good
> |
>
int size = 5;
int b[size];

is not valid C++ either.

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.



--------------060703050903050508070807
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/04/13 21:47, <a class="moz-txt-link-abbreviated" href="mailto:phernost@gmail.com">phernost@gmail.com</a>
      wrote:<br>
    </div>
    <blockquote
      cite="mid:63a94564-29ee-40a0-a313-387f8beb8d1f@isocpp.org"
      type="cite"> std::array is guaranteed to have the same layout as a
      c style array. std::array servers one purpose, to encapsulate a
      fixed size c style array in a standard container template. <br>
      <br>
      <div class="prettyprint" style="background-color: rgb(250, 250,
        250); border-color: rgb(187, 187, 187); border-style: solid;
        border-width: 1px; word-wrap: break-word;"><code
          class="prettyprint">
          <div class="subprettyprint"><span style="color: #000;"
              class="styled-by-prettify">std</span><span style="color:
              #660;" class="styled-by-prettify">::</span><span
              style="color: #000;" class="styled-by-prettify">array</span><span
              style="color: #660;" class="styled-by-prettify">&lt;</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #008;" class="styled-by-prettify">int</span><span
              style="color: #660;" class="styled-by-prettify">,</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #066;" class="styled-by-prettify">2</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">&gt;</span><span
              style="color: #000;" class="styled-by-prettify"> a</span><span
              style="color: #660;" class="styled-by-prettify">;</span><span
              style="color: #000;" class="styled-by-prettify"> <br>
            </span><span style="color: #008;" class="styled-by-prettify">auto</span><span
              style="color: #660;" class="styled-by-prettify">&amp;</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #008;" class="styled-by-prettify">ref</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">=</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">*</span><span
              style="color: #008;" class="styled-by-prettify">reinterpret_cast</span><span
              style="color: #660;" class="styled-by-prettify">&lt;</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #008;" class="styled-by-prettify">int</span><span
              style="color: #660;" class="styled-by-prettify">(*)[</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #066;" class="styled-by-prettify">2</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">]&gt;(</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">&amp;</span><span
              style="color: #000;" class="styled-by-prettify">a </span><span
              style="color: #660;" class="styled-by-prettify">);</span><span
              style="color: #000;" class="styled-by-prettify"><br>
            </span><span style="color: #008;" class="styled-by-prettify">ref</span><span
              style="color: #660;" class="styled-by-prettify">[</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #066;" class="styled-by-prettify">1</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">]</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #660;" class="styled-by-prettify">=</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #066;" class="styled-by-prettify">3</span><span
              style="color: #660;" class="styled-by-prettify">;</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #800;" class="styled-by-prettify">// a[1] ==
              3</span><span style="color: #000;"
              class="styled-by-prettify"><br>
            </span></div>
        </code></div>
      <br>
      The above, and the reverse cast, will always work. But this won't:
      <br>
      <br>
      <div class="prettyprint" style="background-color: rgb(250, 250,
        250); border-color: rgb(187, 187, 187); border-style: solid;
        border-width: 1px; word-wrap: break-word;"><code
          class="prettyprint">
          <div class="subprettyprint"><span style="color: #008;"
              class="styled-by-prettify">int</span><span style="color:
              #000;" class="styled-by-prettify"> size </span><span
              style="color: #660;" class="styled-by-prettify">=</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #066;" class="styled-by-prettify">5</span><span
              style="color: #660;" class="styled-by-prettify">;</span><span
              style="color: #000;" class="styled-by-prettify"> <br>
              std</span><span style="color: #660;"
              class="styled-by-prettify">::</span><span style="color:
              #000;" class="styled-by-prettify">array</span><span
              style="color: #660;" class="styled-by-prettify">&lt;</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #008;" class="styled-by-prettify">int</span><span
              style="color: #660;" class="styled-by-prettify">,</span><span
              style="color: #000;" class="styled-by-prettify"> size </span><span
              style="color: #660;" class="styled-by-prettify">&gt;</span><span
              style="color: #000;" class="styled-by-prettify"> b</span><span
              style="color: #660;" class="styled-by-prettify">;</span><span
              style="color: #000;" class="styled-by-prettify"> </span><span
              style="color: #800;" class="styled-by-prettify">// no good
            </span><span style="color: #000;" class="styled-by-prettify"><br>
            </span></div>
        </code></div>
      <br>
    </blockquote>
    int size = 5;<br>
    int b[size]; <br>
    <br>
    is not valid C++ either.<br>
    <br>
    Chris<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 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 />

--------------060703050903050508070807--

.

------=_Part_29_26839109.1364888483311
Content-Type: text/plain; charset=ISO-8859-1

Agreed, I was just using it as an example that std::array (or native
compile time fixed size arrays) cannot be used it solve all cases, as the
grandparent post seem to hint at.

On Tuesday, April 2, 2013 3:36:57 AM UTC-4, Chris Jefferson wrote:
>
>  On 01/04/13 21:47, pher...@gmail.com <javascript:> wrote:
>
> std::array is guaranteed to have the same layout as a c style array.
> std::array servers one purpose, to encapsulate a fixed size c style array
> in a standard container template.
>
>  std::array< int, 2 > a;
> auto& ref = *reinterpret_cast< int(*)[ 2 ]>( &a );
> ref[ 1 ] = 3; // a[1] == 3
>
> The above, and the reverse cast, will always work. But this won't:
>
>  int size = 5;
> std::array< int, size > b; // no good
>
>  int size = 5;
> int b[size];
>
> is not valid C++ either.
>
> 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_29_26839109.1364888483311
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Agreed, I was just using it as an example that std::array (or native compil=
e time fixed size arrays) cannot be used it solve all cases, as the grandpa=
rent post seem to hint at.<br><br>On Tuesday, April 2, 2013 3:36:57 AM UTC-=
4, Chris Jefferson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 01/04/13 21:47, <a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"-TS-_yOua48J">pher...@gmail.com</a>
      wrote:<br>
    </div>
    <blockquote type=3D"cite"> std::array is guaranteed to have the same la=
yout as a
      c style array. std::array servers one purpose, to encapsulate a
      fixed size c style array in a standard container template. <br>
      <br>
      <div 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>
          <div><span style=3D"color:#000">std</span><span style=3D"color:#6=
60">::</span><span style=3D"color:#000">array</span><span style=3D"color:#6=
60">&lt;</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">int</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
</span><span style=3D"color:#066">2</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> a</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"> <br>
            </span><span style=3D"color:#008">auto</span><span style=3D"col=
or:#660">&amp;</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">ref</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">*</span><span style=3D"color:#008">reinterpret_cast</span><span style=3D"=
color:#660">&lt;</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">int</span><span style=3D"color:#660">(*)[</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#066">2</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">]&gt;(</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">&amp;</span><span style=3D"color:#0=
00">a </span><span style=3D"color:#660">);</span><span style=3D"color:#000"=
><br>
            </span><span style=3D"color:#008">ref</span><span style=3D"colo=
r:#660">[</span><span style=3D"color:#000"> </span><span style=3D"color:#06=
6">1</span><span style=3D"color:#000"> </span><span style=3D"color:#660">]<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">3</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#800">// a[1] =3D=3D
              3</span><span style=3D"color:#000"><br>
            </span></div>
        </code></div>
      <br>
      The above, and the reverse cast, will always work. But this won't:
      <br>
      <br>
      <div 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>
          <div><span style=3D"color:#008">int</span><span style=3D"color:#0=
00"> size </span><span style=3D"color:#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>
              std</span><span style=3D"color:#660">::</span><span style=3D"=
color:#000">array</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> size </span><span style=3D=
"color:#660">&gt;</span><span style=3D"color:#000"> b</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color=
:#800">// no good
            </span><span style=3D"color:#000"><br>
            </span></div>
        </code></div>
      <br>
    </blockquote>
    int size =3D 5;<br>
    int b[size]; <br>
    <br>
    is not valid C++ either.<br>
    <br>
    Chris<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_29_26839109.1364888483311--

.

On 2 April 2013 10:36, Chris Jefferson <chris@bubblescope.net> wrote:
>> int size = 5;
>> std::array< int, size > b; // no good
> int size = 5;
> int b[size];
> is not valid C++ either.

It will likely be. Furthermore you can do
new int[size];
but you can't do
new array<int, size>
as far as I can see.

--

---
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_1689_17015097.1364895303376
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable


2013. =E1prilis 2., kedd 9:41:22 UTC+2 id=F5pontban Paul Tessier a k=F6vetk=
ez=F5t=20
=EDrta:
>
> Agreed, I was just using it as an example that std::array (or native=20
> compile time fixed size arrays) cannot be used it solve all cases, as the=
=20
> grandparent post seem to hint at.
>
> =20
Well of course, std::array<> has compile-time size. If you want run-time=20
size, there is std::vector<>. It is not perfect, but way better than old=20
arrays.

Obviously it makes no sense to do new std::vector, as the actual vector is=
=20
just a handler to the dynamically allocated array, but practically these=20
two are equivalent:
int size =3D 5;
auto x =3D new int[size];
vector<int> y(size);

In this sense, vector is a unique_ptr to a dynamically allocated array.=20
What is "missing", is a - so to say, direct - shared_ptr to a dynamically=
=20
allocated array, as the current way of std::shared_ptr<std::vector<int>>=20
has double indirection to the actual data array ( unlike=20
std::shared_ptr<std::array<int, 5>> ). And this is only a problem due to=20
the handle area of the vector (having to allocate an 'extra'=20
sizeof(std::vector<int>) ).

Another issue is vector default-initializes its elements, new[] does not.=
=20
I'm not sure what to think of this.

To solve these issues, I'd be more than happy with unique_*dynamic_*array<T=
>=20
and share_*dynamic_*array<T>, but they should be a "better" std::vector<T>=
=20
/ std::shared_ptr<std::vector<T>> (give or take interface differences), and=
=20
not a 'wrapped' unique_ptr<T[]> / shared_ptr<T[]>, it in my opinion. For *_=
*
static_*array<T>, there is still std::unique_ptr<std::array<T, n>>, like I=
=20
mentioned previously. (Please forgive me the horrible naming, and absorb=20
just the idea.)

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_1689_17015097.1364895303376
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br>2013. =E1prilis 2., kedd 9:41:22 UTC+2 id=F5pontban Paul Tessier a k=F6=
vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Agreed, I wa=
s just using it as an example that std::array (or native compile time fixed=
 size arrays) cannot be used it solve all cases, as the grandparent post se=
em to hint at.<br><br></blockquote><div>&nbsp;</div><div>Well of course, st=
d::array&lt;&gt; has compile-time size. If you want run-time size, there is=
 std::vector&lt;&gt;. It is not perfect, but way better than old arrays.<br=
><br>Obviously it makes no sense to do new std::vector, as the actual vecto=
r is just a handler to the dynamically allocated array, but practically the=
se two are equivalent:<br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> size </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">5</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=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">new</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><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"colo=
r: #000;" class=3D"styled-by-prettify"><br>vector</span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> y</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"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>In this sense, vector is a uniq=
ue_ptr to a dynamically allocated array. What is "missing", is a - so to sa=
y, direct - shared_ptr to a dynamically allocated array, as the current way=
 of std::shared_ptr&lt;std::vector&lt;int&gt;&gt; has double indirection to=
 the actual data array ( unlike std::shared_ptr&lt;std::array&lt;int, 5&gt;=
&gt; ). And this is only a problem due to the handle area of the vector (ha=
ving to allocate an 'extra' sizeof(std::vector&lt;int&gt;) ).<br><br>Anothe=
r issue is vector default-initializes its elements, new[] does not. I'm not=
 sure what to think of this.<br><br>To solve these issues, I'd be more than=
 happy with unique_<i>dynamic_</i>array&lt;T&gt; and share_<i>dynamic_</i>a=
rray&lt;T&gt;, but they should be a "better" std::vector&lt;T&gt; / std::sh=
ared_ptr&lt;std::vector&lt;T&gt;&gt; (give or take interface differences), =
and not a 'wrapped' unique_ptr&lt;T[]&gt; / shared_ptr&lt;T[]&gt;, it  in m=
y opinion. For *_<i>static_</i>array&lt;T&gt;, there is still std::unique_p=
tr&lt;std::array&lt;T, n&gt;&gt;, like I mentioned previously. (Please forg=
ive me the horrible naming, and absorb just the idea.)<br><br>Regards, Robe=
rt</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_1689_17015097.1364895303376--

.

On Sun, Mar 31, 2013 at 11:53 PM,  <phernost@gmail.com> wrote:
>> --What if it points to something not allocated by the run-time
>> What run-time?
>
>
> Weren't you the one who brought up "run-time"?

No, you did: "It's 2013 and there's still no way to query the run-time
about the size of an array,"
Getting the size of a block from a pointer to that block is actually
problematic for some allocators, there's actually a proposal related
to this (global delete with size I think).


>> What if vector is used with an allocator that doesn't (need to) store this
>> size?
>
>
> Vector with a smart allocator, wouldn't need to store the size.  Vector with
> a dumb allocator, would need to store the size.  I'm not saying this is
> worth it just to save 8 bytes off the size of a vector, I was really using
> vector as an example of duplication of an allocation's size.

You're assuming there is duplication, but this isn't always the case.

> In the mean time, I much rather see unique_array and share_array, with an
> interface similar to std::array.

shared_array?
I'd love to see one too, but AFAIK there's no proposal for these yet.



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



.

------=_Part_1253_28243339.1364896754694
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, April 2, 2013 2:43:10 AM UTC-7, Olaf van der Spek wrote:
>
> On Sun, Mar 31, 2013 at 11:53 PM,  <pher...@gmail.com <javascript:>>
> wrote:
> >> --What if it points to something not allocated by the run-time
> >> What run-time?
> >
> >
> > Weren't you the one who brought up "run-time"?
>
> No, you did: "It's 2013 and there's still no way to query the run-time
> about the size of an array,"
> Getting the size of a block from a pointer to that block is actually
> problematic for some allocators, there's actually a proposal related
> to this (global delete with size I think).
>
>
> >> What if vector is used with an allocator that doesn't (need to) store
> this
> >> size?
> >
> >
> > Vector with a smart allocator, wouldn't need to store the size.  Vector
> with
> > a dumb allocator, would need to store the size.  I'm not saying this is
> > worth it just to save 8 bytes off the size of a vector, I was really
> using
> > vector as an example of duplication of an allocation's size.
>
> You're assuming there is duplication, but this isn't always the case.
>
> > In the mean time, I much rather see unique_array and share_array, with
> an
> > interface similar to std::array.
>
> shared_array?
> I'd love to see one too, but AFAIK there's no proposal for these yet.
>

I don't really think there's much of a need for a shared_array. But we
already may get dynarray for runtime, fixed-sized arrays<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3532.html#dynarray>,
which should effectively eliminate any need for any such `unique_array`
class.

Granted, I think that proposal has some issues (like not being able to be
certain that a particular `dynarray` instance will be stack or
heap-allocated.

--

---
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_1253_28243339.1364896754694
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, April 2, 2013 2:43:10 AM UTC-7, Olaf van der Spek wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Sun, Mar 31, 2013 at 11:53 PM, &nb=
sp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6=
ffrmY3ZjccJ">pher...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; --What if it points to something not allocated by the run-time
<br>&gt;&gt; What run-time?
<br>&gt;
<br>&gt;
<br>&gt; Weren't you the one who brought up "run-time"?
<br>
<br>No, you did: "It's 2013 and there's still no way to query the run-time
<br>about the size of an array,"
<br>Getting the size of a block from a pointer to that block is actually
<br>problematic for some allocators, there's actually a proposal related
<br>to this (global delete with size I think).
<br>
<br>
<br>&gt;&gt; What if vector is used with an allocator that doesn't (need to=
) store this
<br>&gt;&gt; size?
<br>&gt;
<br>&gt;
<br>&gt; Vector with a smart allocator, wouldn't need to store the size. &n=
bsp;Vector with
<br>&gt; a dumb allocator, would need to store the size. &nbsp;I'm not sayi=
ng this is
<br>&gt; worth it just to save 8 bytes off the size of a vector, I was real=
ly using
<br>&gt; vector as an example of duplication of an allocation's size.
<br>
<br>You're assuming there is duplication, but this isn't always the case.
<br>
<br>&gt; In the mean time, I much rather see unique_array and share_array, =
with an
<br>&gt; interface similar to std::array.
<br>
<br>shared_array?
<br>I'd love to see one too, but AFAIK there's no proposal for these yet.
<br></blockquote><div><br>I don't really think there's much of a need for a=
 shared_array. But we already may get <a href=3D"http://www.open-std.org/JT=
C1/SC22/WG21/docs/papers/2013/n3532.html#dynarray">dynarray for runtime, fi=
xed-sized arrays</a>, which should effectively eliminate any need for any s=
uch `unique_array` class.<br><br>Granted, I think that proposal has some is=
sues (like not being able to be certain that a particular `dynarray` instan=
ce will be stack or heap-allocated.<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_1253_28243339.1364896754694--

.

On 2 April 2013 12:35, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> Another issue is vector default-initializes its elements, new[] does not.
> I'm not sure what to think of this.

new[] does it too, you just need to do new Foo[size](); instead of new
Foo[size];

--=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_3835_8198368.1364899538906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, April 2, 2013 3:31:38 AM UTC-7, Ville Voutilainen wrote:
>
> On 2 April 2013 12:35, R=F3bert D=E1vid <lrd...@gmail.com <javascript:>>=
=20
> wrote:=20
> > Another issue is vector default-initializes its elements, new[] does=20
> not.=20
> > I'm not sure what to think of this.=20
>
> new[] does it too, you just need to do new Foo[size](); instead of new=20
> Foo[size];=20
>

I believe the point he was trying to make is that you get a *choice* with=
=20
`new[]`. You don't get a choice with `vector`; it will be value-initialized=
=20
(not default-initialized).

--=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_3835_8198368.1364899538906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, April 2, 2013 3:31:38 AM UTC-7, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On 2 April 2013 12:35, R=F3bert D=E1v=
id &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"0=
IG0xiOm2jEJ">lrd...@gmail.com</a>&gt; wrote:
<br>&gt; Another issue is vector default-initializes its elements, new[] do=
es not.
<br>&gt; I'm not sure what to think of this.
<br>
<br>new[] does it too, you just need to do new Foo[size](); instead of new
<br>Foo[size];
<br></blockquote><div><br>I believe the point he was trying to make is that=
 you get a <i>choice</i> with `new[]`. You don't get a choice with `vector`=
; it will be value-initialized (not default-initialized).<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_3835_8198368.1364899538906--

.

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

A vector and an array have different semantics.  vectors are resizable,=20
arrays are not.  While it is possible to pass a vector const&, to fix its=
=20
size, this also locks all the elements of the vector.  An *_array could be=
=20
passed by reference, or value for shared_array, while allowing the elements=
=20
to be edited without making the *_array const.  In my opinion  std::array=
=20
was a good name, wasted on compile-time arrays. It should have been a=20
container interface for run-time arrays, like vector, but with a fixed=20
size, after creation.  That milk has already been spilled, no going back=20
now.  I guess we could have darray, for run-time fixed size arrays.  I know=
=20
this models a range, so does std::array, but a range with container=20
semantics, all the fun typedefs, allocators, etc...

Hammering make_unique and unique_ptr to support native arrays also seems to=
=20
miss the mark, especially since shared_ptr and make_shared have none of=20
these flaws.

shared_ptr<vector<T>>'s double in indirection is solved by=20
make_shared<vector<T>>.  There is no extra indirection for=20
unique_ptr<vector<T>>, just the same pointer to object interface as=20
shared_ptr<vector<T>>.  make_unique doesn't solve the indirection problem,=
=20
because it doesn't exist for unique_ptr, it solves the "unordered=20
constuction with new can lead to leaks" and creates a similar interface to=
=20
creating a unique_ptr, just like shared_ptr has.

make_shared<T[]> will work as expected, since it decays to make_shared<T*>,=
=20
unlike unique_ptr<T[]>.  Also, it will always have double indirection as=20
you said.  Which is why I suggested shared_array.  One less level of=20
indirection and array and shared semantics in one package.

unique_ptr<T[]> should have acted the same as shared_ptr<T[]>, which is to=
=20
say the same as unique_ptr<T*>.  It doesn't.  This also begins to=20
complicate the interface of make_unique<T[]>, as we've seen.  Which is why=
=20
I suggested unique_array<T>, behaving with array and unique semantics, and=
=20
similar to shared_array.  We should leave unique_ptr<T[]> behind as a bad=
=20
idea, and not carry forth that error into make_unique.

Don't worry about names, I called a function sizeofarray, and all my=20
variables in a previous post were: arr1, arr2, etc..


On Tuesday, April 2, 2013 5:35:03 AM UTC-4, R=F3bert D=E1vid wrote:
>
>
> 2013. =E1prilis 2., kedd 9:41:22 UTC+2 id=F5pontban Paul Tessier a k=F6ve=
tkez=F5t=20
> =EDrta:
>>
>> Agreed, I was just using it as an example that std::array (or native=20
>> compile time fixed size arrays) cannot be used it solve all cases, as th=
e=20
>> grandparent post seem to hint at.
>>
>> =20
> Well of course, std::array<> has compile-time size. If you want run-time=
=20
> size, there is std::vector<>. It is not perfect, but way better than old=
=20
> arrays.
>
> Obviously it makes no sense to do new std::vector, as the actual vector i=
s=20
> just a handler to the dynamically allocated array, but practically these=
=20
> two are equivalent:
> int size =3D 5;
> auto x =3D new int[size];
> vector<int> y(size);
>
> In this sense, vector is a unique_ptr to a dynamically allocated array.=
=20
> What is "missing", is a - so to say, direct - shared_ptr to a dynamically=
=20
> allocated array, as the current way of std::shared_ptr<std::vector<int>>=
=20
> has double indirection to the actual data array ( unlike=20
> std::shared_ptr<std::array<int, 5>> ). And this is only a problem due to=
=20
> the handle area of the vector (having to allocate an 'extra'=20
> sizeof(std::vector<int>) ).
>
> Another issue is vector default-initializes its elements, new[] does not.=
=20
> I'm not sure what to think of this.
>
> To solve these issues, I'd be more than happy with unique_*dynamic_*array=
<T>=20
> and share_*dynamic_*array<T>, but they should be a "better"=20
> std::vector<T> / std::shared_ptr<std::vector<T>> (give or take interface=
=20
> differences), and not a 'wrapped' unique_ptr<T[]> / shared_ptr<T[]>, it i=
n=20
> my opinion. For *_*static_*array<T>, there is still=20
> std::unique_ptr<std::array<T, n>>, like I mentioned previously. (Please=
=20
> forgive me the horrible naming, and absorb just the idea.)
>
> 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_263_27771856.1364899821900
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

A vector and an array have different semantics.&nbsp; vectors are resizable=
, arrays are not.&nbsp; While it is possible to pass a vector const&amp;, t=
o fix its size, this also locks all the elements of the vector.&nbsp; An *_=
array could be passed by reference, or value for shared_array, while allowi=
ng the elements to be edited without making the *_array const.&nbsp; In my =
opinion&nbsp; std::array was a good name, wasted on compile-time arrays. It=
 should have been a container interface for run-time arrays, like vector, b=
ut with a fixed size, after creation.&nbsp; That milk has already been spil=
led, no going back now.&nbsp; I guess we could have darray, for run-time fi=
xed size arrays.&nbsp; I know this models a range, so does std::array, but =
a range with container semantics, all the fun typedefs, allocators, etc...<=
br><br>Hammering make_unique and unique_ptr to support native arrays also s=
eems to miss the mark, especially since shared_ptr and make_shared have non=
e of these flaws.<br><br>shared_ptr&lt;vector&lt;T&gt;&gt;'s double in indi=
rection is solved by make_shared&lt;vector&lt;T&gt;&gt;.&nbsp; There is no =
extra indirection for unique_ptr&lt;vector&lt;T&gt;&gt;, just the same poin=
ter to object interface as shared_ptr&lt;vector&lt;T&gt;&gt;.&nbsp; make_un=
ique doesn't solve the indirection problem, because it doesn't exist for un=
ique_ptr, it solves the "unordered constuction with new can lead to leaks" =
and creates a similar interface to creating a unique_ptr, just like shared_=
ptr has.<br><br>make_shared&lt;T[]&gt; will work as expected, since it deca=
ys to make_shared&lt;T*&gt;, unlike unique_ptr&lt;T[]&gt;.&nbsp; Also, it w=
ill always have double indirection as you said.&nbsp; Which is why I sugges=
ted shared_array.&nbsp; One less level of indirection and array and shared =
semantics in one package.<br><br>unique_ptr&lt;T[]&gt; should have acted th=
e same as shared_ptr&lt;T[]&gt;, which is to say the same as unique_ptr&lt;=
T*&gt;.&nbsp; It doesn't.&nbsp; This also begins to complicate the interfac=
e of make_unique&lt;T[]&gt;, as we've seen.&nbsp; Which is why I suggested =
unique_array&lt;T&gt;, behaving with array and unique semantics, and simila=
r to shared_array.&nbsp; We should leave unique_ptr&lt;T[]&gt; behind as a =
bad idea, and not carry forth that error into make_unique.<br><br>Don't wor=
ry about names, I called a function sizeofarray, and all my variables in a =
previous post were: arr1, arr2, etc..<br><br><br>On Tuesday, April 2, 2013 =
5:35:03 AM UTC-4, R=F3bert D=E1vid wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><br>2013. =E1prilis 2., kedd 9:41:22 UTC+2 id=F5pontban Paul Tes=
sier a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Agreed=
, I was just using it as an example that std::array (or native compile time=
 fixed size arrays) cannot be used it solve all cases, as the grandparent p=
ost seem to hint at.<br><br></blockquote><div>&nbsp;</div><div>Well of cour=
se, std::array&lt;&gt; has compile-time size. If you want run-time size, th=
ere is std::vector&lt;&gt;. It is not perfect, but way better than old arra=
ys.<br><br>Obviously it makes no sense to do new std::vector, as the actual=
 vector is just a handler to the dynamically allocated array, but practical=
ly these two are equivalent:<br><div 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><div><span style=3D"color:#008">int</span><span sty=
le=3D"color:#000"> size </span><span style=3D"color:#660">=3D</span><span s=
tyle=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:#008">auto</span><span style=3D"color:#000"> x </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"> </span><span style=3D"co=
lor:#008">int</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>vector</span><span style=3D"color:#080">&lt;int&gt;</span><span s=
tyle=3D"color:#000"> y</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></span></div></code></div><br>In this sense, vector is =
a unique_ptr to a dynamically allocated array. What is "missing", is a - so=
 to say, direct - shared_ptr to a dynamically allocated array, as the curre=
nt way of std::shared_ptr&lt;std::vector&lt;<wbr>int&gt;&gt; has double ind=
irection to the actual data array ( unlike std::shared_ptr&lt;std::array&lt=
;<wbr>int, 5&gt;&gt; ). And this is only a problem due to the handle area o=
f the vector (having to allocate an 'extra' sizeof(std::vector&lt;int&gt;) =
).<br><br>Another issue is vector default-initializes its elements, new[] d=
oes not. I'm not sure what to think of this.<br><br>To solve these issues, =
I'd be more than happy with unique_<i>dynamic_</i>array&lt;T&gt; and share_=
<i>dynamic_</i>array&lt;T&gt;, but they should be a "better" std::vector&lt=
;T&gt; / std::shared_ptr&lt;std::vector&lt;T&gt;<wbr>&gt; (give or take int=
erface differences), and not a 'wrapped' unique_ptr&lt;T[]&gt; / shared_ptr=
&lt;T[]&gt;, it  in my opinion. For *_<i>static_</i>array&lt;T&gt;, there i=
s still std::unique_ptr&lt;std::array&lt;T, n&gt;&gt;, like I mentioned pre=
viously. (Please forgive me the horrible naming, and absorb just the idea.)=
<br><br>Regards, Robert</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_263_27771856.1364899821900--

.

On Tue, Apr 2, 2013 at 11:59 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I don't really think there's much of a need for a shared_array. But we
> already may get dynarray for runtime, fixed-sized arrays, which should
> effectively eliminate any need for any such `unique_array` class.

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.



.

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


2013. =E1prilis 2., kedd 12:45:38 UTC+2 id=F5pontban Nicol Bolas a k=F6vetk=
ez=F5t=20
=EDrta:
>
> On Tuesday, April 2, 2013 3:31:38 AM UTC-7, Ville Voutilainen wrote:
>>
>> On 2 April 2013 12:35, R=F3bert D=E1vid <lrd...@gmail.com> wrote:=20
>> > Another issue is vector default-initializes its elements, new[] does=
=20
>> not.=20
>> > I'm not sure what to think of this.=20
>>
>> new[] does it too, you just need to do new Foo[size](); instead of new=
=20
>> Foo[size];=20
>>
>
> I believe the point he was trying to make is that you get a *choice* with=
=20
> `new[]`. You don't get a choice with `vector`; it will be value-initializ=
ed=20
> (not default-initialized).
>

Exactly, thank you!

Robert=20

--=20

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



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

<br>2013. =E1prilis 2., kedd 12:45:38 UTC+2 id=F5pontban Nicol Bolas a k=F6=
vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, =
April 2, 2013 3:31:38 AM UTC-7, Ville Voutilainen wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On 2 April 2013 12:35, R=F3bert D=E1vid &lt;<a>lrd..=
..@gmail.com</a>&gt; wrote:
<br>&gt; Another issue is vector default-initializes its elements, new[] do=
es not.
<br>&gt; I'm not sure what to think of this.
<br>
<br>new[] does it too, you just need to do new Foo[size](); instead of new
<br>Foo[size];
<br></blockquote><div><br>I believe the point he was trying to make is that=
 you get a <i>choice</i> with `new[]`. You don't get a choice with `vector`=
; it will be value-initialized (not default-initialized).<br></div></blockq=
uote><div><br>Exactly, thank you!<br><br>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_307_22630221.1364900330289--

.

------=_Part_3292_32339149.1364900963681
Content-Type: text/plain; charset=ISO-8859-1

I'm sorry for my snarkiness, but since you had already used "run-time" in
your reply, I assumed a general understanding.  I was wrong, and was taken
aback by the comment.  Can I assume now that we are on the same page?

For new T[N], it is required that the run-time store the size of the array
somewhere when T has a destructor, otherwise delete[] would not work.  This
is in the standard, not explicitly, but implicitly.  I also know of no
compiler that can achieve the feat of new[]/delete[] for any T with ~T()
without storing the size somewhere.

For allocators, duplication is not always the case.  It should be, unless
the user is trusted to never make an error.  In the face of missing
sizeofarray/sizeofallocation, it was deemed not feasible for all allocators
to infer the size of the original allocation, since they were stateless.

So I agree with all your points.  I only wish the past had been more
creative/forward looking, but hindsight is always perfect.

On Tuesday, April 2, 2013 5:43:10 AM UTC-4, Olaf van der Spek wrote:
>
> On Sun, Mar 31, 2013 at 11:53 PM,  <pher...@gmail.com <javascript:>>
> wrote:
> >> --What if it points to something not allocated by the run-time
> >> What run-time?
> >
> >
> > Weren't you the one who brought up "run-time"?
>
> No, you did: "It's 2013 and there's still no way to query the run-time
> about the size of an array,"
> Getting the size of a block from a pointer to that block is actually
> problematic for some allocators, there's actually a proposal related
> to this (global delete with size I think).
>
>
> >> What if vector is used with an allocator that doesn't (need to) store
> this
> >> size?
> >
> >
> > Vector with a smart allocator, wouldn't need to store the size.  Vector
> with
> > a dumb allocator, would need to store the size.  I'm not saying this is
> > worth it just to save 8 bytes off the size of a vector, I was really
> using
> > vector as an example of duplication of an allocation's size.
>
> You're assuming there is duplication, but this isn't always the case.
>
> > In the mean time, I much rather see unique_array and share_array, with
> an
> > interface similar to std::array.
>
> shared_array?
> I'd love to see one too, but AFAIK there's no proposal for these yet.
>
>
>
> --
> 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.



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

I'm sorry for my snarkiness, but since you had already used "run-time" in y=
our reply, I assumed a general understanding.&nbsp; I was wrong, and was ta=
ken aback by the comment.&nbsp; Can I assume now that we are on the same pa=
ge?<br><br>For new T[N], it is required that the run-time store the size of=
 the=20
array somewhere when T has a destructor, otherwise delete[] would not work.=
&nbsp; This is in the standard, not explicitly, but implicitly.&nbsp; I als=
o know of no compiler that can achieve the feat of new[]/delete[] for any T=
 with ~T() without storing the size somewhere.<br><br>For allocators, dupli=
cation is not always the case.&nbsp; It should be, unless the user is trust=
ed to never make an error.&nbsp; In the face of missing sizeofarray/sizeofa=
llocation, it was deemed not feasible for all allocators to infer the size =
of the original allocation, since they were stateless.<br><br>So I agree wi=
th all your points.&nbsp; I only wish the past had been more creative/forwa=
rd looking, but hindsight is always perfect.<br><br>On Tuesday, April 2, 20=
13 5:43:10 AM UTC-4, Olaf van der Spek wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On Sun, Mar 31, 2013 at 11:53 PM, &nbsp;&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6ffrmY3ZjccJ">pher...@gm=
ail.com</a>&gt; wrote:
<br>&gt;&gt; --What if it points to something not allocated by the run-time
<br>&gt;&gt; What run-time?
<br>&gt;
<br>&gt;
<br>&gt; Weren't you the one who brought up "run-time"?
<br>
<br>No, you did: "It's 2013 and there's still no way to query the run-time
<br>about the size of an array,"
<br>Getting the size of a block from a pointer to that block is actually
<br>problematic for some allocators, there's actually a proposal related
<br>to this (global delete with size I think).
<br>
<br>
<br>&gt;&gt; What if vector is used with an allocator that doesn't (need to=
) store this
<br>&gt;&gt; size?
<br>&gt;
<br>&gt;
<br>&gt; Vector with a smart allocator, wouldn't need to store the size. &n=
bsp;Vector with
<br>&gt; a dumb allocator, would need to store the size. &nbsp;I'm not sayi=
ng this is
<br>&gt; worth it just to save 8 bytes off the size of a vector, I was real=
ly using
<br>&gt; vector as an example of duplication of an allocation's size.
<br>
<br>You're assuming there is duplication, but this isn't always the case.
<br>
<br>&gt; In the mean time, I much rather see unique_array and share_array, =
with an
<br>&gt; interface similar to std::array.
<br>
<br>shared_array?
<br>I'd love to see one too, but AFAIK there's no proposal for these yet.
<br>
<br>
<br>
<br>--=20
<br>Olaf
<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_3292_32339149.1364900963681--

.

------=_Part_3044_7059414.1364901310390
Content-Type: text/plain; charset=ISO-8859-1

Slap allocator support on that, and it's becoming good replacement for new
T[].  Hadn't seen it yet, thanks for pointing it out.

It almost eliminates the need for unique_array, as unique_ptr<dynarray>
would be close, but with double indirection.

On Tuesday, April 2, 2013 5:59:14 AM UTC-4, Nicol Bolas wrote:
>
> On Tuesday, April 2, 2013 2:43:10 AM UTC-7, Olaf van der Spek wrote:
>>
>> On Sun, Mar 31, 2013 at 11:53 PM,  <pher...@gmail.com> wrote:
>> >> --What if it points to something not allocated by the run-time
>> >> What run-time?
>> >
>> >
>> > Weren't you the one who brought up "run-time"?
>>
>> No, you did: "It's 2013 and there's still no way to query the run-time
>> about the size of an array,"
>> Getting the size of a block from a pointer to that block is actually
>> problematic for some allocators, there's actually a proposal related
>> to this (global delete with size I think).
>>
>>
>> >> What if vector is used with an allocator that doesn't (need to) store
>> this
>> >> size?
>> >
>> >
>> > Vector with a smart allocator, wouldn't need to store the size.  Vector
>> with
>> > a dumb allocator, would need to store the size.  I'm not saying this is
>> > worth it just to save 8 bytes off the size of a vector, I was really
>> using
>> > vector as an example of duplication of an allocation's size.
>>
>> You're assuming there is duplication, but this isn't always the case.
>>
>> > In the mean time, I much rather see unique_array and share_array, with
>> an
>> > interface similar to std::array.
>>
>> shared_array?
>> I'd love to see one too, but AFAIK there's no proposal for these yet.
>>
>
> I don't really think there's much of a need for a shared_array. But we
> already may get dynarray for runtime, fixed-sized arrays<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3532.html#dynarray>,
> which should effectively eliminate any need for any such `unique_array`
> class.
>
> Granted, I think that proposal has some issues (like not being able to be
> certain that a particular `dynarray` instance will be stack or
> heap-allocated.
>

--

---
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_3044_7059414.1364901310390
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Slap allocator support on that, and it's becoming good replacement for new =
T[].&nbsp; Hadn't seen it yet, thanks for pointing it out.<br><br>It almost=
 eliminates the need for unique_array, as unique_ptr&lt;dynarray&gt; would =
be close, but with double indirection.<br><br>On Tuesday, April 2, 2013 5:5=
9:14 AM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">On Tuesday, April 2, 2013 2:43:10 AM UTC-7, Olaf van der Spek wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">On Sun, Mar 31, 2013 at 11:53 PM, &nbsp=
;&lt;<a>pher...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; --What if it points to something not allocated by the run-time
<br>&gt;&gt; What run-time?
<br>&gt;
<br>&gt;
<br>&gt; Weren't you the one who brought up "run-time"?
<br>
<br>No, you did: "It's 2013 and there's still no way to query the run-time
<br>about the size of an array,"
<br>Getting the size of a block from a pointer to that block is actually
<br>problematic for some allocators, there's actually a proposal related
<br>to this (global delete with size I think).
<br>
<br>
<br>&gt;&gt; What if vector is used with an allocator that doesn't (need to=
) store this
<br>&gt;&gt; size?
<br>&gt;
<br>&gt;
<br>&gt; Vector with a smart allocator, wouldn't need to store the size. &n=
bsp;Vector with
<br>&gt; a dumb allocator, would need to store the size. &nbsp;I'm not sayi=
ng this is
<br>&gt; worth it just to save 8 bytes off the size of a vector, I was real=
ly using
<br>&gt; vector as an example of duplication of an allocation's size.
<br>
<br>You're assuming there is duplication, but this isn't always the case.
<br>
<br>&gt; In the mean time, I much rather see unique_array and share_array, =
with an
<br>&gt; interface similar to std::array.
<br>
<br>shared_array?
<br>I'd love to see one too, but AFAIK there's no proposal for these yet.
<br></blockquote><div><br>I don't really think there's much of a need for a=
 shared_array. But we already may get <a href=3D"http://www.open-std.org/JT=
C1/SC22/WG21/docs/papers/2013/n3532.html#dynarray" target=3D"_blank">dynarr=
ay for runtime, fixed-sized arrays</a>, which should effectively eliminate =
any need for any such `unique_array` class.<br><br>Granted, I think that pr=
oposal has some issues (like not being able to be certain that a particular=
 `dynarray` instance will be stack or heap-allocated.<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_3044_7059414.1364901310390--

.

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



2013. =E1prilis 2., kedd 12:50:21 UTC+2 id=F5pontban Paul Tessier a k=F6vet=
kez=F5t=20
=EDrta:
>
> A vector and an array have different semantics.  vectors are resizable,=
=20
> arrays are not.
>

That falls into the 'not perfect' category :) That said, the the linked=20
dynarray proposal models more closely what is needed here.

shared_ptr<vector<T>>'s double in indirection is solved by=20
> make_shared<vector<T>>.
>

Not exactly. Even with make_shared, you still have a shared_ptr that points=
=20
to the object, what here is a vector, that most probably has a T* begin=20
pointer inside. So if you need the 3rd element, you get the pointer from=20
the shared_ptr, dereference it to get a vector&, then you get the begin=20
pointer from the vector, add 3( *sizeof(T) ), then dereference it to get=20
what you wanted. Make_shared (at least by Stephan's / Microsoft's=20
implementation) only optimizes out the double allocation on the heap, one=
=20
for the shared_ptr's control block, another for the stored object, but if=
=20
the stored object is a vector, it will still allocate another block on the=
=20
heap. There is no way a shared_ptr to directly point the data inside the=20
vector, nor to put its control block inside the same heap allocation with=
=20
the vector's data. This is where a shared_array proposal could come in=20
handy.

Exact same issue with unique_ptr, only there is no control block present,=
=20
neither by its own on the heap, nor embedded into the same allocation of=20
the smart pointers' stored object (=3D> unique_array).

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_309_24300592.1364902902902
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. =E1prilis 2., kedd 12:50:21 UTC+2 id=F5pontban Paul Tessier 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;">A vecto=
r and an array have different semantics.&nbsp; vectors are resizable, array=
s are not.<br></blockquote><div><br>That falls into the 'not perfect' categ=
ory :) That said, the the linked dynarray proposal models more closely what=
 is needed here.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
shared_ptr&lt;vector&lt;T&gt;&gt;'s double in indirection is solved by make=
_shared&lt;vector&lt;T&gt;&gt;.<br></blockquote><div><br>Not exactly. Even =
with make_shared, you still have a shared_ptr that points to the object, wh=
at here is a vector, that most probably has a T* begin pointer inside. So i=
f you need the 3rd element, you get the pointer from the shared_ptr, derefe=
rence it to get a vector&amp;, then you get the begin pointer from the vect=
or, add 3( *sizeof(T) ), then dereference it to get what you wanted. Make_s=
hared (at least by Stephan's / Microsoft's implementation) only optimizes o=
ut the double allocation on the heap, one for the shared_ptr's control bloc=
k, another for the stored object, but if the stored object is a vector, it =
will still allocate another block on the heap. There is no way a shared_ptr=
 to directly point the data inside the vector, nor to put its control block=
 inside the same heap allocation with the vector's data. This is where a sh=
ared_array proposal could come in handy.<br><br>Exact same issue with uniqu=
e_ptr, only there is no control block present, neither by its own on the he=
ap, nor embedded into the same allocation of the smart pointers' stored obj=
ect (=3D&gt; unique_array).</div><br>Regards, Robert<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_309_24300592.1364902902902--

.

On Tue, Apr 2, 2013 at 1:09 PM, Paul Tessier <phernost@gmail.com> wrote:
> I'm sorry for my snarkiness, but since you had already used "run-time" in
> your reply, I assumed a general understanding.  I was wrong, and was taken
> aback by the comment.  Can I assume now that we are on the same page?

Maybe ;)
See below

> For new T[N], it is required that the run-time store the size of the array
> somewhere when T has a destructor, otherwise delete[] would not work.  This
> is in the standard, not explicitly, but implicitly.  I also know of no
> compiler that can achieve the feat of new[]/delete[] for any T with ~T()
> without storing the size somewhere.

True, but ...
Let's take std::vector as an example. AFAIK it allocates raw memory
and constructs object in that memory, so it doesn't use new[].
Hence requiring the run-time to store the size of the block would be
an extra requirement, essentially increasing duplication instead of
reducing it.

> For allocators, duplication is not always the case.  It should be, unless
> the user is trusted to never make an error.

Debug builds may have such checks, but for optimal performance such
checks are usually disabled.

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.



.

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

Perfect is the enemy of progress, agreed.

If dynarray makes it in (fingers crossed), we can throw unique_array right=
=20
out.  As long as it has proper move semantics, it's much better than=20
unique_array.

At the least I'd like make_unique not to support arrays with=20
unique_ptr<T[]>'s broken interface.

For make_shared<vector>, I was only pointing out that level of indirection=
=20
is the nearly the same as vector*.  The indirection is most likely to occur=
=20
on the same cache line, since shared_ptr's control block contains the=20
vector object.  This greatly decreases the chance of a cache miss. verses=
=20
shared_ptr<vector>.

Sorry for conflating likely cache misses with direct levels of=20
indirection.  I consider cache misses, the only indirection I care about,=
=20
so from a literal stand point, I'm wrong.  I don't mind a 16 byte jump to=
=20
the object, it's when the jump can be to anywhere, then I care.

For shared_array it would allocate space for the array and the control=20
block in one allocation.  Less cache misses, like make_shared does for flat=
=20
objects.

In general unique_ptr<vector> is almost useless, the vector itself handles=
=20
allocations.  I guess you could use it, if you want to push two pointers=20
worth of space off the stack/struct for the added benefit of more=20
indirection.

On Tuesday, April 2, 2013 7:41:42 AM UTC-4, R=C3=B3bert D=C3=A1vid wrote:
>
>
>
> 2013. =C3=A1prilis 2., kedd 12:50:21 UTC+2 id=C5=91pontban Paul Tessier a=
 k=C3=B6vetkez=C5=91t=20
> =C3=ADrta:
>>
>> A vector and an array have different semantics.  vectors are resizable,=
=20
>> arrays are not.
>>
>
> That falls into the 'not perfect' category :) That said, the the linked=
=20
> dynarray proposal models more closely what is needed here.
>
> shared_ptr<vector<T>>'s double in indirection is solved by=20
>> make_shared<vector<T>>.
>>
>
> Not exactly. Even with make_shared, you still have a shared_ptr that=20
> points to the object, what here is a vector, that most probably has a T*=
=20
> begin pointer inside. So if you need the 3rd element, you get the pointer=
=20
> from the shared_ptr, dereference it to get a vector&, then you get the=20
> begin pointer from the vector, add 3( *sizeof(T) ), then dereference it t=
o=20
> get what you wanted. Make_shared (at least by Stephan's / Microsoft's=20
> implementation) only optimizes out the double allocation on the heap, one=
=20
> for the shared_ptr's control block, another for the stored object, but if=
=20
> the stored object is a vector, it will still allocate another block on th=
e=20
> heap. There is no way a shared_ptr to directly point the data inside the=
=20
> vector, nor to put its control block inside the same heap allocation with=
=20
> the vector's data. This is where a shared_array proposal could come in=20
> handy.
>
> Exact same issue with unique_ptr, only there is no control block present,=
=20
> neither by its own on the heap, nor embedded into the same allocation of=
=20
> the smart pointers' stored object (=3D> unique_array).
>
> 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_3265_12725511.1364906347364
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Perfect is the enemy of progress, agreed.<br><br>If dynarray makes it in (f=
ingers crossed), we can throw unique_array=20
right out.&nbsp; As long as it has proper move semantics, it's much better =
than unique_array.<br><br>At the least I'd like make_unique not to support =
arrays with unique_ptr&lt;T[]&gt;'s broken interface.<br><br>For make_share=
d&lt;vector&gt;, I was only pointing out that level of indirection is the n=
early the same as vector*.&nbsp; The indirection is most likely to occur on=
 the same cache line, since shared_ptr's control block contains the vector =
object.&nbsp; This greatly decreases the chance of a cache miss. verses sha=
red_ptr&lt;vector&gt;.<br><br>Sorry for conflating likely cache misses with=
 direct levels of indirection.&nbsp; I consider cache misses, the only indi=
rection I care about, so from a literal stand point, I'm wrong.&nbsp; I don=
't mind a 16 byte jump to the object, it's when the jump can be to anywhere=
, then I care.<br><br>For shared_array it would allocate space for the arra=
y and the control block in one allocation.&nbsp; Less cache misses, like ma=
ke_shared does for flat objects.<br><br>In general unique_ptr&lt;vector&gt;=
 is almost useless, the vector itself handles allocations.&nbsp; I guess yo=
u could use it, if you want to push two pointers worth of space off the sta=
ck/struct for the added benefit of more indirection.<br><br>On Tuesday, Apr=
il 2, 2013 7:41:42 AM UTC-4, R=F3bert D=E1vid wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><br><br>2013. =E1prilis 2., kedd 12:50:21 UTC+2 id=F5=
pontban Paul Tessier a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">A vector and an array have different semantics.&nbsp; vectors are=
 resizable, arrays are not.<br></blockquote><div><br>That falls into the 'n=
ot perfect' category :) That said, the the linked dynarray proposal models =
more closely what is needed here.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">shared_ptr&lt;vector&lt;T&gt;&gt;'s double in indirection is so=
lved by make_shared&lt;vector&lt;T&gt;&gt;.<br></blockquote><div><br>Not ex=
actly. Even with make_shared, you still have a shared_ptr that points to th=
e object, what here is a vector, that most probably has a T* begin pointer =
inside. So if you need the 3rd element, you get the pointer from the shared=
_ptr, dereference it to get a vector&amp;, then you get the begin pointer f=
rom the vector, add 3( *sizeof(T) ), then dereference it to get what you wa=
nted. Make_shared (at least by Stephan's / Microsoft's implementation) only=
 optimizes out the double allocation on the heap, one for the shared_ptr's =
control block, another for the stored object, but if the stored object is a=
 vector, it will still allocate another block on the heap. There is no way =
a shared_ptr to directly point the data inside the vector, nor to put its c=
ontrol block inside the same heap allocation with the vector's data. This i=
s where a shared_array proposal could come in handy.<br><br>Exact same issu=
e with unique_ptr, only there is no control block present, neither by its o=
wn on the heap, nor embedded into the same allocation of the smart pointers=
' stored object (=3D&gt; unique_array).</div><br>Regards, Robert<br></block=
quote>

<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_3265_12725511.1364906347364--

.

------=_Part_3616_4970680.1364910754038
Content-Type: text/plain; charset=ISO-8859-1

I blame the C people for not having a standard way of retrieving the
allocation size from malloc.  They finally got around to add aligned_alloc,
but not alloc_size.

The only standard allocators, malloc and new, store the size of the
allocation somewhere implicitly.  new[] can end up storing the size again,
typically because malloc is the underlying base.  So that's a minimum of
one store of the allocation size, and a double store of the allocation size
for new[], if new if based off malloc and not it's own heap allocator.  The
std::allocator interface requires that everything that uses it must
explicitly store the allocation size, so three sizeof duplication at worst,
two at best.

If these allocators didn't hide the size, duplication would be reduced, for
vector and everything else that uses them, to none.  We have no control
over the malloc interface, for backwards compatibility reasons.  The
allocator used by the standard (new/delete) could at least be made not to
hide information, and allow querying the allocation size.  new/delete needs
to be overhauled anyway to support, extended alignment.  We could even
throw in some wait-free algorithms based off the new atomics for better
threading, if the compiler writer is willing to implement a new heap
allocator.

For all allocators that use the heap, the size is duplicated.  Some
suballocators, pools/freelists, the size is usually not kept, just like you
said.  So I would make a distinction between suballocators and allocators.
I was only considering allocators originally, but your comment reminded me
about suballocators.

So I guess I'd like an interface for smart_allocators (size tracking),
compared to std::allocator (suballocator).  If I hand vector a
smart_allocator, it doesn't need to track the capacity.  If I hand it a
std::allocator it needs to track it.  The default allocator should be a
smart_allocator that makes proper use of the heap storing the allocation
size.

So right now vector is suboptimal (microscopically), because it doesn't
have a way to use a smart_allocator, which can't exist because there's no
way to get the allocation size, which would make bounds checking easy for
native arrays.

On Tuesday, April 2, 2013 8:33:19 AM UTC-4, Olaf van der Spek wrote:
>
> On Tue, Apr 2, 2013 at 1:09 PM, Paul Tessier <pher...@gmail.com<javascript:>>
> wrote:
> > I'm sorry for my snarkiness, but since you had already used "run-time"
> in
> > your reply, I assumed a general understanding.  I was wrong, and was
> taken
> > aback by the comment.  Can I assume now that we are on the same page?
>
> Maybe ;)
> See below
>
> > For new T[N], it is required that the run-time store the size of the
> array
> > somewhere when T has a destructor, otherwise delete[] would not work.
>  This
> > is in the standard, not explicitly, but implicitly.  I also know of no
> > compiler that can achieve the feat of new[]/delete[] for any T with ~T()
> > without storing the size somewhere.
>
> True, but ...
> Let's take std::vector as an example. AFAIK it allocates raw memory
> and constructs object in that memory, so it doesn't use new[].
> Hence requiring the run-time to store the size of the block would be
> an extra requirement, essentially increasing duplication instead of
> reducing it.
>
> > For allocators, duplication is not always the case.  It should be,
> unless
> > the user is trusted to never make an error.
>
> Debug builds may have such checks, but for optimal performance such
> checks are usually disabled.
>
> 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.



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

I blame the C people for not having a standard way of retrieving the alloca=
tion size from malloc.&nbsp; They finally got around to add aligned_alloc, =
but not alloc_size.<br><br>The only standard allocators, malloc and new, st=
ore the size of the allocation somewhere implicitly.&nbsp; new[] can end up=
 storing the size again, typically because malloc is the underlying base.&n=
bsp; So that's a minimum of one store of the allocation size, and a double =
store of the allocation size for new[], if new if based off malloc and not =
it's own heap allocator.&nbsp; The std::allocator interface requires that e=
verything that uses it must explicitly store the allocation size, so three =
sizeof duplication at worst, two at best.<br><br>If these allocators didn't=
 hide the size, duplication would be reduced, for vector and everything els=
e that uses them, to none.&nbsp; We have no control over the malloc interfa=
ce, for backwards compatibility reasons.&nbsp; The allocator used by the st=
andard (new/delete) could at least be made not to hide information, and all=
ow querying the allocation size.&nbsp; new/delete needs to be overhauled an=
yway to support, extended alignment.&nbsp; We could even throw in some wait=
-free algorithms based off the new atomics for better threading, if the com=
piler writer is willing to implement a new heap allocator.<br><br>For all a=
llocators that use the heap, the size is duplicated.&nbsp; Some suballocato=
rs, pools/freelists, the size is usually not kept, just like you said.&nbsp=
; So I would make a distinction between suballocators and allocators.&nbsp;=
 I was only considering allocators originally, but your comment reminded me=
 about suballocators.<br><br>So I guess I'd like an interface for smart_all=
ocators (size tracking), compared to std::allocator (suballocator).&nbsp; I=
f I hand vector a smart_allocator, it doesn't need to track the capacity.&n=
bsp; If I hand it a std::allocator it needs to track it.&nbsp; The default =
allocator should be a smart_allocator that makes proper use of the heap sto=
ring the allocation size.<br><br>So right now vector is suboptimal (microsc=
opically), because it doesn't have a way to use a smart_allocator, which ca=
n't exist because there's no way to get the allocation size, which would ma=
ke bounds checking easy for native arrays.<br><br>On Tuesday, April 2, 2013=
 8:33:19 AM UTC-4, Olaf van der Spek wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">On Tue, Apr 2, 2013 at 1:09 PM, Paul Tessier &lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"n44RoTyS5c8J">pher...=
@gmail.com</a>&gt; wrote:
<br>&gt; I'm sorry for my snarkiness, but since you had already used "run-t=
ime" in
<br>&gt; your reply, I assumed a general understanding. &nbsp;I was wrong, =
and was taken
<br>&gt; aback by the comment. &nbsp;Can I assume now that we are on the sa=
me page?
<br>
<br>Maybe ;)
<br>See below
<br>
<br>&gt; For new T[N], it is required that the run-time store the size of t=
he array
<br>&gt; somewhere when T has a destructor, otherwise delete[] would not wo=
rk. &nbsp;This
<br>&gt; is in the standard, not explicitly, but implicitly. &nbsp;I also k=
now of no
<br>&gt; compiler that can achieve the feat of new[]/delete[] for any T wit=
h ~T()
<br>&gt; without storing the size somewhere.
<br>
<br>True, but ...
<br>Let's take std::vector as an example. AFAIK it allocates raw memory
<br>and constructs object in that memory, so it doesn't use new[].
<br>Hence requiring the run-time to store the size of the block would be
<br>an extra requirement, essentially increasing duplication instead of
<br>reducing it.
<br>
<br>&gt; For allocators, duplication is not always the case. &nbsp;It shoul=
d be, unless
<br>&gt; the user is trusted to never make an error.
<br>
<br>Debug builds may have such checks, but for optimal performance such
<br>checks are usually disabled.
<br>
<br>Olaf
<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_3616_4970680.1364910754038--

.