Topic: Allowing uninitialized elements in std::vector
Author: gonzalobg88@gmail.com
Date: Tue, 11 Feb 2014 06:28:45 -0800 (PST)
Raw View
------=_Part_4941_30320236.1392128925973
Content-Type: text/plain; charset=UTF-8
Hello world!
I ran into the following efficiency problem when writing a C++ wrapper
around a C library that uses raw buffers for communication (the library in
this case is MPI):
std::vector<T> wrapper_function() {
std::size_t size = native_function_get_size();
...; // allocate memory
T* data = ...; // get pointer to memory
native_function(data, size, ...)
... // return vector<T>(data);
}
Constraints on the problem: the C++ library user expects an interface using
std::vector, while the C library exposes a "unique_ptr" like interface
using the pair (T*, size).
IMHO:
- this problem is common and relevant when writing C++ wrappers around C
libraries (see example above),
- it is desirable to provide thin, safe, and efficient wrapper around C
libraries, and
- there is currently no good solution available.
To the authors best knowledge, the most efficient solution is:
std::vector<T> wrapper_function() {
std::size_t size = native_function_get_size();
std::vector<T> data_vector (size); // overhead: vector default
constructs elements!
native_function(data_vector.data(), size, ...)
return data_vector;
}
It is worth to remark that any solution considered should play well with
allocators.
Proposed solution: provide a constructor and a resize methods that do not
perform initialization.
Bikeshed 1:
struct uninitialized_t {};
const constexpr uninitialized_t uninitialized {};
std::vector<T>(size, std::uninitialized)
std::vector<T>::resize(size, std::uninitialized)
The problem could then be solved as:
std::vector<T> wrapper_function() {
std::size_t size = native_function_get_size();
std::vector<T> data_vector (size, std::uninitialized);
native_function(data_vector.data(), size, ...)
return data_vector;
}
Bikeshed 2:
std::vector<T>::uninitialized_resize(size)
The problem could then be solved as:
std::vector<T> wrapper_function() {
std::size_t size = native_function_get_size();
std::vector<T> data_vector();
data_vector.uninitialized_resize(size);
native_function(data_vector.data(), size, ...)
return data_vector;
}
Anyhow, both alternatives allow developing efficient C++ wrappers of C
libraries that maintain a native C++ interface, and discourage used of
uninitialized memory by providing a verbose interface.
What do you think?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4941_30320236.1392128925973
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello world!<div><br></div><div>I ran into the following e=
fficiency problem when writing a C++ wrapper around a C library that uses r=
aw buffers for communication (the library in this case is MPI):</div><div><=
div><br></div><div>std::vector<T> wrapper_function() {</div><div>&nbs=
p; std::size_t size =3D native_function_get_size();</div><div> ...; /=
/ allocate memory</div><div> T* data =3D ...; // get pointer to memor=
y</div><div> native_function(data, size, ...)<br></div><div> ..=
.. // return vector<T>(data);</div><div>}<br></div><div><br></div><div=
>Constraints on the problem: the C++ library user expects an interface usin=
g std::vector, while the C library exposes a "unique_ptr" like interface us=
ing the pair (T*, size).</div><div><br></div><div>IMHO:</div><div> - =
this problem is common and relevant when writing C++ wrappers around C libr=
aries (see example above), </div><div> - it is desirable =
to provide thin, safe, and efficient wrapper around C libraries, and<br></d=
iv><div> - there is currently no good solution available.<br></div><d=
iv><div>To the authors best knowledge, the most efficient solution is:</div=
></div><div><br></div><div>std::vector<T> wrapper_function() {<br></d=
iv><div> std::size_t size =3D native_function_get_size();</div><div>&=
nbsp; std::vector<T> data_vector (size); // overhead: vector de=
fault constructs elements!</div><div> native_function(data_vector.dat=
a(), size, ...)<br></div><div> return data_vector;</div><div>}</div><=
div><br></div><div>It is worth to remark that any solution considered shoul=
d play well with allocators.</div><div><br></div><div>Proposed solution: pr=
ovide a constructor and a resize methods that do not perform initialization=
..</div><div><br></div><div>Bikeshed 1: </div><div> struct uninit=
ialized_t {}; <br></div><div> const constexpr uninitialized_t un=
initialized {};</div><div> std::vector<T>(size, std::unini=
tialized)<br></div><div> std::vector<T>::resize(size, std:=
:uninitialized)<br></div><div><br></div><div>The problem could then be solv=
ed as:</div><div><br></div><div><div>std::vector<T> wrapper_function(=
) {</div><div> std::size_t size =3D native_function_get_size();</div>=
<div> std::vector<T> data_vector (size, std::uninitialized);&nb=
sp;</div><div> native_function(data_vector.data(), size, ...)<br></di=
v><div> return data_vector;</div><div>}</div></div><div><br></div><di=
v>Bikeshed 2:</div><div><div> std::vector<T>::uninitialized_res=
ize(size)</div></div><div><div><br></div><div>The problem could then be sol=
ved as:</div><div><br></div><div><div>std::vector<T> wrapper_function=
() {</div><div> std::size_t size =3D native_function_get_size();</div=
><div> std::vector<T> data_vector();</div><div> data_vect=
or.uninitialized_resize(size);</div><div> native_function(data_vector=
..data(), size, ...)<br></div><div> return data_vector;</div><div>}</d=
iv></div></div><div><br></div><div>Anyhow, both alternatives allow developi=
ng efficient C++ wrappers of C libraries that maintain a native C++ interfa=
ce, and discourage used of uninitialized memory by providing a verbose inte=
rface.</div><div><br></div></div><div>What do you think?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4941_30320236.1392128925973--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 11 Feb 2014 09:53:09 -0600
Raw View
--047d7bd902464a3d6f04f2237611
Content-Type: text/plain; charset=ISO-8859-1
On 11 February 2014 08:28, <gonzalobg88@gmail.com> wrote:
>
> It is worth to remark that any solution considered should play well with
> allocators.
>
The issue can already be solved with allocators. See <
http://stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor/15119665#15119665>
for one such method.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd902464a3d6f04f2237611
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 February 2014 08:28, <span dir=3D"ltr"><<a href=
=3D"mailto:gonzalobg88@gmail.com" target=3D"_blank">gonzalobg88@gmail.com</=
a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div><div><br></div><div>It is worth to remark that any so=
lution considered should play well with allocators.</div></div></div></bloc=
kquote><div><br></div><div>The issue can already be solved with allocators.=
=A0See <<a href=3D"http://stackoverflow.com/questions/15097783/value-in=
itialized-objects-in-c11-and-stdvector-constructor/15119665#15119665">http:=
//stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and=
-stdvector-constructor/15119665#15119665</a>> for one such method.</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd902464a3d6f04f2237611--
.
Author: gonzalobg88@gmail.com
Date: Tue, 11 Feb 2014 09:10:41 -0800 (PST)
Raw View
------=_Part_524_23593200.1392138641145
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 11, 2014 4:53:09 PM UTC+1, Nevin ":-)" Liber wrote:
>
> The issue can already be solved with allocators. See <
> http://stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor/15119665#15119665>
> for one such method.
>
Thanks for mentioning this! However the proposed approach restricts the
unsafe operations to the interface with C code and returns a safe wrapper.
AFAIK changing the behavior at the allocator level means that the vector
would _always_ do the unsafe thing (i.e. default initialization).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_524_23593200.1392138641145
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 11, 2014 4:53:09 PM UTC+1, Nevin ":-)=
" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div class=3D"gmail_quote"><div>The issue can already be solved with alloc=
ators. See <<a href=3D"http://stackoverflow.com/questions/15097783=
/value-initialized-objects-in-c11-and-stdvector-constructor/15119665#151196=
65" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F15097783%2Fvalue-initiali=
zed-objects-in-c11-and-stdvector-constructor%2F15119665%2315119665\46sa\75D=
\46sntz\0751\46usg\75AFQjCNEpqQlfTMqKCy0_tF1lcHD1YCKGEA';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflo=
w.com%2Fquestions%2F15097783%2Fvalue-initialized-objects-in-c11-and-stdvect=
or-constructor%2F15119665%2315119665\46sa\75D\46sntz\0751\46usg\75AFQjCNEpq=
QlfTMqKCy0_tF1lcHD1YCKGEA';return true;">http://stackoverflow.com/<wbr>ques=
tions/15097783/value-<wbr>initialized-objects-in-c11-<wbr>and-stdvector-con=
structor/<wbr>15119665#15119665</a>> for one such method.<br></div></div=
></div></blockquote><div><br></div><div>Thanks for mentioning this! However=
the proposed approach restricts the unsafe operations to the interface wit=
h C code and returns a safe wrapper. AFAIK changing the behavior at the all=
ocator level means that the vector would _always_ do the unsafe thing (i.e.=
default initialization). </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_524_23593200.1392138641145--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 11 Feb 2014 11:32:00 -0600
Raw View
--f46d043c7de6cd778604f224d793
Content-Type: text/plain; charset=ISO-8859-1
On 11 February 2014 11:10, <gonzalobg88@gmail.com> wrote:
> On Tuesday, February 11, 2014 4:53:09 PM UTC+1, Nevin ":-)" Liber wrote:
>>
>> The issue can already be solved with allocators. See <
>> http://stackoverflow.com/questions/15097783/value-
>> initialized-objects-in-c11-and-stdvector-constructor/15119665#15119665>
>> for one such method.
>>
>
> Thanks for mentioning this! However the proposed approach restricts the
> unsafe operations to the interface with C code and returns a safe wrapper.
>
Uninitialized PODs are not unsafe.
> AFAIK changing the behavior at the allocator level means that the vector
> would _always_ do the unsafe thing (i.e. default initialization).
>
Do you have an actual use case where you need to have both uninitialized
and initialized PODs and cannot use something like v.resize(100,
V::value_type())?
The advantages of using an allocator is that (a) you can use it right now
and (b) it can be added independently to the standard library, instead of
(i) waiting at least 4 years and (ii) revamping allocators and containers
just to support a very tiny use case.
And if you can afford to wait that long, the argument that you really need
the performance just doesn't hold much weight.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--f46d043c7de6cd778604f224d793
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 February 2014 11:10, <span dir=3D"ltr"><<a href=
=3D"mailto:gonzalobg88@gmail.com" target=3D"_blank">gonzalobg88@gmail.com</=
a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"">On Tuesday, February 11, 2014 4:53:09 PM U=
TC+1, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>The issue can already be s=
olved with allocators. =A0See <<a href=3D"http://stackoverflow.com/quest=
ions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor/15=
119665#15119665" target=3D"_blank">http://stackoverflow.com/<u></u>question=
s/15097783/value-<u></u>initialized-objects-in-c11-<u></u>and-stdvector-con=
structor/<u></u>15119665#15119665</a>> for one such method.<br>
</div></div></div></blockquote><div><br></div></div><div>Thanks for mention=
ing this! However the proposed approach restricts the unsafe operations to =
the interface with C code and returns a safe wrapper. </div></div></blockqu=
ote>
<div><br></div><div>Uninitialized PODs are not unsafe.<br></div><div>=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>AFAIK changing the =
behavior at the allocator level means that the vector would _always_ do the=
unsafe thing (i.e. default initialization).=A0</div>
</div></blockquote><div><br></div><div>Do you have an actual use case where=
you need to have both uninitialized and initialized PODs and cannot use so=
mething like v.resize(100, V::value_type())?<br><br></div><div>The advantag=
es of using an allocator is that (a) you can use it right now and (b) it ca=
n be added independently to the standard library, instead of (i) waiting at=
least 4 years and (ii) revamping allocators and containers just to support=
a very tiny use case.<br>
<br>And if you can afford to wait that long, the argument that you really n=
eed the performance just doesn't hold much weight.<br clear=3D"all"></d=
iv></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
;=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d043c7de6cd778604f224d793--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 11 Feb 2014 10:52:18 -0800 (PST)
Raw View
------=_Part_4936_10889616.1392144738358
Content-Type: text/plain; charset=UTF-8
Note that those vectors with the special allocator are not the same type as
"normal" vectors so you can't make a "vector based api" and use another
allocator inside the function, without having to copy the data one more
time.
I have suggested a trait which can be used to specify that data from a
certain pair of allocators can be interchanged (i.e. the actual allocation
is the same, it is the side task of allocator, initialization, which
differs).
Also, it would be impssible to get any level of thread safety for
uninitialized memory in the vector.
However, it would be very simple to include a resize_default_constructed()
method on vector which calls the default constructor on the elements
instead of the value constructor that resize() calls. This only differs for
built in types and pointers.
This suggestion has been met with nothing but scorn by the majority on this
list, who think that this can never be a real performance problem. This
despite the fact that the current thread is the third or fourth time this
issue has come up in the last months...
Den tisdagen den 11:e februari 2014 kl. 18:32:00 UTC+1 skrev Nevin ":-)"
Liber:
>
> On 11 February 2014 11:10, <gonza...@gmail.com <javascript:>> wrote:
>
>> On Tuesday, February 11, 2014 4:53:09 PM UTC+1, Nevin ":-)" Liber wrote:
>>>
>>> The issue can already be solved with allocators. See <
>>> http://stackoverflow.com/questions/15097783/value-
>>> initialized-objects-in-c11-and-stdvector-constructor/15119665#15119665>
>>> for one such method.
>>>
>>
>> Thanks for mentioning this! However the proposed approach restricts the
>> unsafe operations to the interface with C code and returns a safe wrapper.
>>
>
> Uninitialized PODs are not unsafe.
>
>
>> AFAIK changing the behavior at the allocator level means that the vector
>> would _always_ do the unsafe thing (i.e. default initialization).
>>
>
> Do you have an actual use case where you need to have both uninitialized
> and initialized PODs and cannot use something like v.resize(100,
> V::value_type())?
>
> The advantages of using an allocator is that (a) you can use it right now
> and (b) it can be added independently to the standard library, instead of
> (i) waiting at least 4 years and (ii) revamping allocators and containers
> just to support a very tiny use case.
>
> And if you can afford to wait that long, the argument that you really need
> the performance just doesn't hold much weight.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)
> 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4936_10889616.1392144738358
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Note that those vectors with the special allocator are not=
the same type as "normal" vectors so you can't make a "vector based api" a=
nd use another allocator inside the function, without having to copy the da=
ta one more time.<div><br></div><div>I have suggested a trait which can be =
used to specify that data from a certain pair of allocators can be intercha=
nged (i.e. the actual allocation is the same, it is the side task of alloca=
tor, initialization, which differs).</div><div><br></div><div>Also, it woul=
d be impssible to get any level of thread safety for uninitialized memory i=
n the vector.</div><div><br></div><div>However, it would be very simple to =
include a resize_default_constructed() method on vector which calls the def=
ault constructor on the elements instead of the value constructor that resi=
ze() calls. This only differs for built in types and pointers.</div><div><b=
r></div><div>This suggestion has been met with nothing but scorn by the maj=
ority on this list, who think that this can never be a real performance pro=
blem. This despite the fact that the current thread is the third or fourth =
time this issue has come up in the last months...</div><div><br>Den tisdage=
n den 11:e februari 2014 kl. 18:32:00 UTC+1 skrev Nevin ":-)" Liber:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On 11 February 2014 =
11:10, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"xRJIv06-rlMJ" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">gonza...=
@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div dir=3D"ltr"><div>On Tuesday, February 11, 2014 4:53:09 PM UTC+1, Nevin=
":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>The issue can already be s=
olved with allocators. See <<a href=3D"http://stackoverflow.com/qu=
estions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor=
/15119665#15119665" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F15097783%=
2Fvalue-initialized-objects-in-c11-and-stdvector-constructor%2F15119665%231=
5119665\46sa\75D\46sntz\0751\46usg\75AFQjCNEpqQlfTMqKCy0_tF1lcHD1YCKGEA';re=
turn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2=
F%2Fstackoverflow.com%2Fquestions%2F15097783%2Fvalue-initialized-objects-in=
-c11-and-stdvector-constructor%2F15119665%2315119665\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNEpqQlfTMqKCy0_tF1lcHD1YCKGEA';return true;">http://stackoverfl=
ow.com/<u></u>ques<wbr>tions/15097783/value-<u></u>initializ<wbr>ed-objects=
-in-c11-<u></u>and-<wbr>stdvector-constructor/<u></u>15119665<wbr>#15119665=
</a>> for one such method.<br>
</div></div></div></blockquote><div><br></div></div><div>Thanks for mention=
ing this! However the proposed approach restricts the unsafe operations to =
the interface with C code and returns a safe wrapper. </div></div></blockqu=
ote>
<div><br></div><div>Uninitialized PODs are not unsafe.<br></div><div> =
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>AFAIK changing t=
he behavior at the allocator level means that the vector would _always_ do =
the unsafe thing (i.e. default initialization). </div>
</div></blockquote><div><br></div><div>Do you have an actual use case where=
you need to have both uninitialized and initialized PODs and cannot use so=
mething like v.resize(100, V::value_type())?<br><br></div><div>The advantag=
es of using an allocator is that (a) you can use it right now and (b) it ca=
n be added independently to the standard library, instead of (i) waiting at=
least 4 years and (ii) revamping allocators and containers just to support=
a very tiny use case.<br>
<br>And if you can afford to wait that long, the argument that you really n=
eed the performance just doesn't hold much weight.<br clear=3D"all"></div><=
/div>-- <br> Nevin ":-)" Liber <mailto:<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"xRJIv06-rlMJ" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">ne...@eviloverlord.com</a><wbr>> (847) 691-1404
</div></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4936_10889616.1392144738358--
.
Author: vadim.petrochenkov@gmail.com
Date: Tue, 11 Feb 2014 13:16:32 -0800 (PST)
Raw View
------=_Part_931_19671457.1392153392421
Content-Type: text/plain; charset=UTF-8
boost::container::vector already has it.
http://www.boost.org/doc/libs/1_55_0/doc/html/container/extended_functionality.html#container.extended_functionality.default_initialialization
The feature was requested here several times but the local audience wasn't
very kind to the requests.
On Tuesday, February 11, 2014 6:28:45 PM UTC+4, gonza...@gmail.com wrote:
>
> Hello world!
>
> I ran into the following efficiency problem when writing a C++ wrapper
> around a C library that uses raw buffers for communication (the library in
> this case is MPI):
>
> std::vector<T> wrapper_function() {
> std::size_t size = native_function_get_size();
> ...; // allocate memory
> T* data = ...; // get pointer to memory
> native_function(data, size, ...)
> ... // return vector<T>(data);
> }
>
> Constraints on the problem: the C++ library user expects an interface
> using std::vector, while the C library exposes a "unique_ptr" like
> interface using the pair (T*, size).
>
> IMHO:
> - this problem is common and relevant when writing C++ wrappers around C
> libraries (see example above),
> - it is desirable to provide thin, safe, and efficient wrapper around C
> libraries, and
> - there is currently no good solution available.
> To the authors best knowledge, the most efficient solution is:
>
> std::vector<T> wrapper_function() {
> std::size_t size = native_function_get_size();
> std::vector<T> data_vector (size); // overhead: vector default
> constructs elements!
> native_function(data_vector.data(), size, ...)
> return data_vector;
> }
>
> It is worth to remark that any solution considered should play well with
> allocators.
>
> Proposed solution: provide a constructor and a resize methods that do not
> perform initialization.
>
> Bikeshed 1:
> struct uninitialized_t {};
> const constexpr uninitialized_t uninitialized {};
> std::vector<T>(size, std::uninitialized)
> std::vector<T>::resize(size, std::uninitialized)
>
> The problem could then be solved as:
>
> std::vector<T> wrapper_function() {
> std::size_t size = native_function_get_size();
> std::vector<T> data_vector (size, std::uninitialized);
> native_function(data_vector.data(), size, ...)
> return data_vector;
> }
>
> Bikeshed 2:
> std::vector<T>::uninitialized_resize(size)
>
> The problem could then be solved as:
>
> std::vector<T> wrapper_function() {
> std::size_t size = native_function_get_size();
> std::vector<T> data_vector();
> data_vector.uninitialized_resize(size);
> native_function(data_vector.data(), size, ...)
> return data_vector;
> }
>
> Anyhow, both alternatives allow developing efficient C++ wrappers of C
> libraries that maintain a native C++ interface, and discourage used of
> uninitialized memory by providing a verbose interface.
>
> What do you think?
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_931_19671457.1392153392421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">boost::container::vector already has it.<div>http://www.bo=
ost.org/doc/libs/1_55_0/doc/html/container/extended_functionality.html#cont=
ainer.extended_functionality.default_initialialization<br><br>The feature w=
as requested here several times but the local audience wasn't ver=
y kind to the requests.</div><div><br>On Tuesday, February 11, 2014 6:28:45=
PM UTC+4, gonza...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">Hello world!<div><br></div><div>I ran into the follo=
wing efficiency problem when writing a C++ wrapper around a C library that =
uses raw buffers for communication (the library in this case is MPI):</div>=
<div><div><br></div><div>std::vector<T> wrapper_function() {</div><di=
v> std::size_t size =3D native_function_get_size();</div><div> =
....; // allocate memory</div><div> T* data =3D ...; // get pointer to=
memory</div><div> native_function(data, size, ...)<br></div><div>&nb=
sp; ... // return vector<T>(data);</div><div>}<br></div><div><br></di=
v><div>Constraints on the problem: the C++ library user expects an interfac=
e using std::vector, while the C library exposes a "unique_ptr" like interf=
ace using the pair (T*, size).</div><div><br></div><div>IMHO:</div><div>&nb=
sp; - this problem is common and relevant when writing C++ wrappers around =
C libraries (see example above), </div><div> - it is desi=
rable to provide thin, safe, and efficient wrapper around C libraries, and<=
br></div><div> - there is currently no good solution available.<br></=
div><div><div>To the authors best knowledge, the most efficient solution is=
:</div></div><div><br></div><div>std::vector<T> wrapper_function() {<=
br></div><div> std::size_t size =3D native_function_get_size();</div>=
<div> std::vector<T> data_vector (size); // overhead: vec=
tor default constructs elements!</div><div> native_function(data_vect=
or.<wbr>data(), size, ...)<br></div><div> return data_vector;</div><d=
iv>}</div><div><br></div><div>It is worth to remark that any solution consi=
dered should play well with allocators.</div><div><br></div><div>Proposed s=
olution: provide a constructor and a resize methods that do not perform ini=
tialization.</div><div><br></div><div>Bikeshed 1: </div><div> st=
ruct uninitialized_t {}; <br></div><div> const constexpr uniniti=
alized_t uninitialized {};</div><div> std::vector<T>(size, =
;std::<wbr>uninitialized)<br></div><div> std::vector<T>::resize=
(size, <wbr>std::uninitialized)<br></div><div><br></div><div>The probl=
em could then be solved as:</div><div><br></div><div><div>std::vector<T&=
gt; wrapper_function() {</div><div> std::size_t size =3D native_funct=
ion_get_size();</div><div> std::vector<T> data_vector (size, st=
d::uninitialized); </div><div> native_function(data_vector.<wbr>=
data(), size, ...)<br></div><div> return data_vector;</div><div>}</di=
v></div><div><br></div><div>Bikeshed 2:</div><div><div> std::vector&l=
t;T>::uninitialized_<wbr>resize(size)</div></div><div><div><br></div><di=
v>The problem could then be solved as:</div><div><br></div><div><div>std::v=
ector<T> wrapper_function() {</div><div> std::size_t size =3D n=
ative_function_get_size();</div><div> std::vector<T> data_vecto=
r();</div><div> data_vector.uninitialized_<wbr>resize(size);</div><di=
v> native_function(data_vector.<wbr>data(), size, ...)<br></div><div>=
return data_vector;</div><div>}</div></div></div><div><br></div><div=
>Anyhow, both alternatives allow developing efficient C++ wrappers of C lib=
raries that maintain a native C++ interface, and discourage used of uniniti=
alized memory by providing a verbose interface.</div><div><br></div></div><=
div>What do you think?</div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_931_19671457.1392153392421--
.
Author: gonzalobg88@gmail.com
Date: Tue, 11 Feb 2014 16:36:13 -0800 (PST)
Raw View
------=_Part_5281_13692509.1392165373099
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 11, 2014 6:32:00 PM UTC+1, Nevin ":-)" Liber wrote:
>
> Do you have an actual use case where you need to have both uninitialized
> and initialized PODs and cannot use something like v.resize(100,
> V::value_type())?
>
Returning a vector type with some some _special_ semantics feels just
wrong. I don't know what the users of my library are going to do with the
vector but requiring them to know about default/value initialization seems
to be an unnecessary burden.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5281_13692509.1392165373099
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 11, 2014 6:32:00 PM UTC+1, Nevin ":-)=
" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bor=
der-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"g=
mail_quote">Do you have an actual use case where you need to have both unin=
itialized and initialized PODs and cannot use something like v.resize(100, =
V::value_type())?</div></div></blockquote><div><br></div><div>Returning a v=
ector type with some some _special_ semantics feels just wrong. I don't kno=
w what the users of my library are going to do with the vector but requirin=
g them to know about default/value initialization seems to be an unnecessar=
y burden. </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5281_13692509.1392165373099--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 12 Feb 2014 00:36:48 -0800 (PST)
Raw View
------=_Part_5308_32963082.1392194208025
Content-Type: text/plain; charset=UTF-8
I don't see that your users would need to know anything special, it would
be a standard vector, only when it gets filled from the C code library the
implementor of the wrapper must know to do a resize_default_constructed()
to avoid the overhead of
clearing the memory that the C function is soon to overwrite. The caller of
the wrapper just sees a vector.
The beauty of resize_default_constructed() is that it allows this type of
interfacing while NOT introducing any hazards if used on vectors of types
with constructors and destructors.
Den onsdagen den 12:e februari 2014 kl. 01:36:13 UTC+1 skrev
gonza...@gmail.com:
>
> On Tuesday, February 11, 2014 6:32:00 PM UTC+1, Nevin ":-)" Liber wrote:
>>
>> Do you have an actual use case where you need to have both uninitialized
>> and initialized PODs and cannot use something like v.resize(100,
>> V::value_type())?
>>
>
> Returning a vector type with some some _special_ semantics feels just
> wrong. I don't know what the users of my library are going to do with the
> vector but requiring them to know about default/value initialization seems
> to be an unnecessary burden.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5308_32963082.1392194208025
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't see that your users would need to know anything sp=
ecial, it would be a standard vector, only when it gets filled from the C c=
ode library the implementor of the wrapper must know to do a resize_default=
_constructed() to avoid the overhead of<div>clearing the memory that the C =
function is soon to overwrite. The caller of the wrapper just sees a vector=
..</div><div><br></div><div>The beauty of resize_default_construc=
ted() is that it allows this type of interfacing while NOT introducing any =
hazards if used on vectors of types with constructors and destructors.<br><=
br>Den onsdagen den 12:e februari 2014 kl. 01:36:13 UTC+1 skrev gonza...@gm=
ail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Tu=
esday, February 11, 2014 6:32:00 PM UTC+1, Nevin ":-)" Liber wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote">Do you have an actual =
use case where you need to have both uninitialized and initialized PODs and=
cannot use something like v.resize(100, V::value_type())?</div></div></blo=
ckquote><div><br></div><div>Returning a vector type with some some _special=
_ semantics feels just wrong. I don't know what the users of my library are=
going to do with the vector but requiring them to know about default/value=
initialization seems to be an unnecessary burden. </div></div></block=
quote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5308_32963082.1392194208025--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 12 Feb 2014 10:00:47 -0800
Raw View
--001a11c2e4589d881104f2395cd9
Content-Type: text/plain; charset=UTF-8
I think much of the "hate" that showed up in the other thread talking about
this was that in that thread, the proposal was about removing the length
check in push_back, which has negligible cost in most situations.
> The beauty of resize_default_constructed() is that it allows this type
of interfacing while NOT introducing any hazards if used on vectors of
types with constructors and destructors.
If this means that you can call it without breaking vector's other
invariants then that'd be a good candidate to add.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Wed, Feb 12, 2014 at 12:36 AM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
> I don't see that your users would need to know anything special, it would
> be a standard vector, only when it gets filled from the C code library the
> implementor of the wrapper must know to do a resize_default_constructed()
> to avoid the overhead of
> clearing the memory that the C function is soon to overwrite. The caller
> of the wrapper just sees a vector.
>
> The beauty of resize_default_constructed() is that it allows this type of
> interfacing while NOT introducing any hazards if used on vectors of types
> with constructors and destructors.
>
> Den onsdagen den 12:e februari 2014 kl. 01:36:13 UTC+1 skrev
> gonza...@gmail.com:
>
>> On Tuesday, February 11, 2014 6:32:00 PM UTC+1, Nevin ":-)" Liber wrote:
>>>
>>> Do you have an actual use case where you need to have both uninitialized
>>> and initialized PODs and cannot use something like v.resize(100,
>>> V::value_type())?
>>>
>>
>> Returning a vector type with some some _special_ semantics feels just
>> wrong. I don't know what the users of my library are going to do with the
>> vector but requiring them to know about default/value initialization seems
>> to be an unnecessary burden.
>>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2e4589d881104f2395cd9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I think much of the "hate" that showed up i=
n the other thread talking about this was that in that thread, the proposal=
was about removing the length check in push_back, which has negligible cos=
t in most situations.</div>
<div><br></div><div>> The beauty of=C2=A0=C2=A0resize_default_constructe=
d() is that it allows this type of interfacing while NOT introducing any ha=
zards if used on vectors of types with constructors and destructors.</div><=
div><br>
</div><div>If this means that you can call it without breaking vector's=
other invariants then that'd be a good candidate to add.</div></div><d=
iv class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy=
O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/8=
2320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Wed, Feb 12, 2014 at 12:36 AM, Bengt =
Gustafsson <span dir=3D"ltr"><<a href=3D"mailto:bengt.gustafsson@beamway=
s.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don't see that your u=
sers would need to know anything special, it would be a standard vector, on=
ly when it gets filled from the C code library the implementor of the wrapp=
er must know to do a resize_default_constructed() to avoid the overhead of<=
div>
clearing the memory that the C function is soon to overwrite. The caller of=
the wrapper just sees a vector.</div><div><br></div><div>The beauty of=C2=
=A0=C2=A0resize_default_constructed() is that it allows this type of interf=
acing while NOT introducing any hazards if used on vectors of types with co=
nstructors and destructors.<br>
<br>Den onsdagen den 12:e februari 2014 kl. 01:36:13 UTC+1 skrev <a href=3D=
"mailto:gonza...@gmail.com" target=3D"_blank">gonza...@gmail.com</a>:<div><=
div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid">
<div dir=3D"ltr">On Tuesday, February 11, 2014 6:32:00 PM UTC+1, Nevin &quo=
t;:-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div class=3D"gmail_quote">Do you have an actual use case =
where you need to have both uninitialized and initialized PODs and cannot u=
se something like v.resize(100, V::value_type())?</div></div></blockquote>
<div>
<br></div><div>Returning a vector type with some some _special_ semantics f=
eels just wrong. I don't know what the users of my library are going to=
do with the vector but requiring them to know about default/value initiali=
zation seems to be an unnecessary burden.=C2=A0</div>
</div></blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2e4589d881104f2395cd9--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 12 Feb 2014 11:49:40 -0800 (PST)
Raw View
------=_Part_876_30252233.1392234580294
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 11, 2014 3:28:45 PM UTC+1, gonza...@gmail.com wrote:
>
> What do you think?
>
Personally I'm using a shared_array variant for this.
shared_data wrapper_function() {
shared_data d(native_function_get_size());
native_function(d.data(), d.size(), ...);
return d;
}
The great thing is that the allocation/deallcation details aren't part of
the type. I could for example also return a managed memory mapped file. Or
a locked video surface, etc.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_876_30252233.1392234580294
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 11, 2014 3:28:45 PM UTC+1, gonza...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>What do you think?</div></div></blockquote><div><br></div><div>Perso=
nally I'm using a shared_array variant for this.</div><div><br></div><div><=
div>shared_data wrapper_function() {</div><div> shared_data d(native_=
function_get_size()); <br></div><div> native_function(d.<wbr>dat=
a(), d.size(), ...);<br></div><div> return d;</div><div>}</div></div>=
<div><br></div><div>The great thing is that the allocation/deallcation deta=
ils aren't part of the type. I could for example also return a managed memo=
ry mapped file. Or a locked video surface, etc.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_876_30252233.1392234580294--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 12 Feb 2014 13:43:10 -0800 (PST)
Raw View
------=_Part_971_1997521.1392241391021
Content-Type: text/plain; charset=UTF-8
Billy: I don't see that it would break any invariants. All elements are
initialized by their default constructors, in the same way as local scalar
variables are.
Olaf: I think you are referring to something similar to an array_view which
was recently discussed here. This works fine for generic APIs (for instance
in a range based for or to a templated algorithm) but most APIs are not
generic (yet) but instead specify a specific type for their parameter,
typically a vector<T> (with standard allocator).
Den onsdagen den 12:e februari 2014 kl. 20:49:40 UTC+1 skrev Olaf van der
Spek:
>
> On Tuesday, February 11, 2014 3:28:45 PM UTC+1, gonza...@gmail.com wrote:
>>
>> What do you think?
>>
>
> Personally I'm using a shared_array variant for this.
>
> shared_data wrapper_function() {
> shared_data d(native_function_get_size());
> native_function(d.data(), d.size(), ...);
> return d;
> }
>
> The great thing is that the allocation/deallcation details aren't part of
> the type. I could for example also return a managed memory mapped file. Or
> a locked video surface, etc.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_971_1997521.1392241391021
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Billy: I don't see that it would break any invariants. All=
elements are initialized by their default constructors, in the same way as=
local scalar variables are.<div><br></div><div>Olaf: I think you are refer=
ring to something similar to an array_view which was recently discussed her=
e. This works fine for generic APIs (for instance in a range based for or t=
o a templated algorithm) but most APIs are not generic (yet) but instead sp=
ecify a specific type for their parameter, typically a vector<T> (wit=
h standard allocator).<br><br>Den onsdagen den 12:e februari 2014 kl. 20:49=
:40 UTC+1 skrev Olaf van der Spek:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Tuesday, February 11, 2014 3:28:45 PM UTC+1, <a>g=
onza...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>What do you think?</div></div></blockquote><div><br></div><d=
iv>Personally I'm using a shared_array variant for this.</div><div><br></di=
v><div><div>shared_data wrapper_function() {</div><div> shared_data d=
(native_function_get_size());<wbr> <br></div><div> native_functi=
on(d.data(), d.size(), ...);<br></div><div> return d;</div><div>}</di=
v></div><div><br></div><div>The great thing is that the allocation/deallcat=
ion details aren't part of the type. I could for example also return a mana=
ged memory mapped file. Or a locked video surface, etc.</div></div></blockq=
uote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_971_1997521.1392241391021--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 21 Feb 2014 15:42:03 -0800 (PST)
Raw View
------=_Part_776_14946848.1393026123573
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 12, 2014 10:43:10 PM UTC+1, Bengt Gustafsson wrote:
>
> Olaf: I think you are referring to something similar to an array_view
> which was recently discussed here. This works fine for generic APIs (for
> instance in a range based for or to a templated algorithm) but most APIs
> are not generic (yet) but instead specify a specific type for their
> parameter, typically a vector<T> (with standard allocator).
>
>
I think not, though I've got such a type too. shared_data really is like
shared_ptr/array.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_776_14946848.1393026123573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 12, 2014 10:43:10 PM UTC+1, Bengt G=
ustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Olaf: I think you are referring to something similar to an array_view wh=
ich was recently discussed here. This works fine for generic APIs (for inst=
ance in a range based for or to a templated algorithm) but most APIs are no=
t generic (yet) but instead specify a specific type for their parameter, ty=
pically a vector<T> (with standard allocator).<br><br></div></blockqu=
ote><div><br></div><div>I think not, though I've got such a type too. share=
d_data really is like shared_ptr/array. </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_776_14946848.1393026123573--
.