Topic: Safety utilities for aligned_storage and friends
Author: Brittany Friedman <fourthgeek@gmail.com>
Date: Wed, 23 Nov 2016 18:34:35 -0600
Raw View
--001a113b00707d8fbf0542012b4d
Content-Type: text/plain; charset=UTF-8
Hello all,
I had an idea for a simple utility to help avoid bugs when using
aligned_storage_t and aligned_union_t. I'm a big fan of avoiding any use of
the heap that I can and these classes often come in handy.
When I go to store data in these buffers it's easy to make a mistake. In
particular it's easy to accidentally store an object in the buffer that's
too big to fit or is not aligned properly.
My proposal is to add member functions to aligned_storage_t and
aligned_union_t for emplace, destroy, and get.
//stupid toy examples
std::aligned_storage_t<1,1> buffer;
new (&buffer) int(); //runtime buffer overflow
std::aligned_storage_t<1,1> buffer;
buffer.emplace<int>(); //static_assert
so the idea is to add:
aligned_storage_t
{
....
template<class U>
U& get();
template<class U, class... Args>
U& emplace(Args&& ... args);
template<class U>
void destroy();
};
//and the same for aligned_union_t
These functions would have extremely narrow contracts, so we're not storing
an extra bool to verify that an object has been constructed when we call
destroy. It's still the programmer's duty to get that right. We can at
least verify that U is a valid type to store.
I am suggesting these three functions as they are the most commonly needed
in my experience. Assignment can be done via
buf.get<T>() = y;
cppreference's page on aligned_storage has a class static_vector. The
implementation of static_vector would be a fair bit simpler with these
utilities. For example their operator[] would simply be
data[pos].get<const T>();
instead of
return *reinterpret_cast<const T*>(data+pos);
Thoughts?
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQC0Wk-XHF4dir7uXADsVK8Hk%3D-f_puusj8PC_zsGULgA%40mail.gmail.com.
--001a113b00707d8fbf0542012b4d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello all,<div><br></div><div>I had an idea for a simple u=
tility to help avoid bugs when using aligned_storage_t and aligned_union_t.=
I'm a big fan of avoiding any use of the heap that I can and these cla=
sses often come in handy.</div><div><br></div><div>When I go to store data =
in these buffers it's easy to make a mistake. In particular it's ea=
sy to accidentally store an object in the buffer that's too big to fit =
or is not aligned properly.</div><div><br></div><div>My proposal is to add =
member functions to aligned_storage_t and aligned_union_t for emplace, dest=
roy, and get.</div><div><blockquote style=3D"margin:0px 0px 0px 40px;border=
:none;padding:0px"><div><br></div></blockquote><blockquote style=3D"margin:=
0px 0px 0px 40px;border:none;padding:0px"><div>//stupid toy examples</div><=
/blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border:none;paddin=
g:0px"><div>std::aligned_storage_t<1,1> buffer;</div><div>new (&b=
uffer) int(); //runtime buffer overflow</div><div><br></div><div>std::align=
ed_storage_t<1,1> buffer;</div><div>buffer.emplace<int>(); //st=
atic_assert</div></blockquote></div><div><br></div><div>so the idea is to a=
dd:</div><div><br></div><div><br></div><blockquote style=3D"margin:0px 0px =
0px 40px;border:none;padding:0px"><div>aligned_storage_t</div><div>{</div><=
/blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"=
><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div=
>...</div></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border:=
none;padding:0px"><div>template<class U></div></blockquote><blockquot=
e style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div>U& get=
();</div></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border:n=
one;padding:0px"><div><br></div></blockquote><blockquote style=3D"margin:0p=
x 0px 0px 40px;border:none;padding:0px"><div>template<class U, class... =
Args></div></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;bor=
der:none;padding:0px"><div>U& emplace(Args&& ... args);</div></=
blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding=
:0px"><div><br></div></blockquote><blockquote style=3D"margin:0px 0px 0px 4=
0px;border:none;padding:0px"><div>template<class U></div></blockquote=
><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div=
>void destroy();</div></blockquote></blockquote><blockquote style=3D"margin=
:0px 0px 0px 40px;border:none;padding:0px"><div>};</div><div><br></div></bl=
ockquote><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px"><div>//and the same for aligned_union_t</div><div><br></div></blockquot=
e>These functions would have extremely narrow contracts, so we're not s=
toring an extra bool to verify that an object has been constructed when we =
call destroy. It's still the programmer's duty to get that right. W=
e can at least verify that U is a valid type to store.<div><br></div><div>I=
am suggesting these three functions as they are the most commonly needed i=
n my experience. Assignment can be done via</div><div><br></div><blockquote=
style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>buf.get<T>(=
) =3D y;</div></blockquote><div><div><br></div><div>cppreference's page=
on aligned_storage has a class static_vector. The implementation of static=
_vector would be a fair bit simpler with these utilities. For example their=
operator[] would simply be</div><div><br></div><div><blockquote style=3D"m=
argin:0px 0px 0px 40px;border:none;padding:0px"><div>data[pos].get<const=
T>();</div><div><br></div></blockquote>instead of</div><div><br><blockq=
uote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">return *rein=
terpret_cast<const T*>(data+pos);<br><br></blockquote>Thoughts?</div>=
</div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQC0Wk-XHF4dir7uXADsVK8Hk%3D-=
f_puusj8PC_zsGULgA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQC0W=
k-XHF4dir7uXADsVK8Hk%3D-f_puusj8PC_zsGULgA%40mail.gmail.com</a>.<br />
--001a113b00707d8fbf0542012b4d--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 23 Nov 2016 19:16:00 -0800 (PST)
Raw View
------=_Part_3162_675385686.1479957360417
Content-Type: multipart/alternative;
boundary="----=_Part_3163_1847042352.1479957360417"
------=_Part_3163_1847042352.1479957360417
Content-Type: text/plain; charset=UTF-8
Here's the thing. The moment you call that `emplace` function, the object
is no longer an `aligned_storage_t` object anymore. That object has had its
lifetime end, and the type `U` has had its lifetime begin. So any
pointers/references to the `aligned_storage_t` object are no longer valid.
So `get` and `destroy` cannot be called on it.
Now, you can certainly create a new type; call it
`aligned_storage_manager`. This type can *contain* an `aligned_storage_t`,
and therefore it can forward such calls to that internal
`aligned_storage_t` buffer. It would naturally need to do a bit of pointer
laundering, but overall, it can work.
Also, I don't think that it should `static_assert` if the storage doesn't
fit the requirements of the type. It should instead use SFINAE to detect
such things.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/960ce86a-b89d-4b07-afd9-844547411ae0%40isocpp.org.
------=_Part_3163_1847042352.1479957360417
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here's the thing. The moment you call that `emplace` f=
unction, the object is no longer an `aligned_storage_t` object anymore. Tha=
t object has had its lifetime end, and the type `U` has had its lifetime be=
gin. So any pointers/references to the `aligned_storage_t` object are no lo=
nger valid. So `get` and `destroy` cannot be called on it.<br><br>Now, you =
can certainly create a new type; call it `aligned_storage_manager`. This ty=
pe can <i>contain</i> an `aligned_storage_t`, and therefore it can forward =
such calls to that internal `aligned_storage_t` buffer. It would naturally =
need to do a bit of pointer laundering, but overall, it can work.<br><br>Al=
so, I don't think that it should `static_assert` if the storage doesn&#=
39;t fit the requirements of the type. It should instead use SFINAE to dete=
ct such things.<br></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/960ce86a-b89d-4b07-afd9-844547411ae0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/960ce86a-b89d-4b07-afd9-844547411ae0=
%40isocpp.org</a>.<br />
------=_Part_3163_1847042352.1479957360417--
------=_Part_3162_675385686.1479957360417--
.
Author: Brittany Friedman <fourthgeek@gmail.com>
Date: Wed, 23 Nov 2016 23:11:50 -0600
Raw View
--001a1144f68801ec330542050bb1
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 23, 2016 at 9:16 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Here's the thing. The moment you call that `emplace` function, the object
> is no longer an `aligned_storage_t` object anymore. That object has had its
> lifetime end, and the type `U` has had its lifetime begin. So any
> pointers/references to the `aligned_storage_t` object are no longer valid.
> So `get` and `destroy` cannot be called on it.
>
Ah, I understand what you are referring to and I don't doubt you know the
standard better than I, but I just want to make sure I understand.
Suppose that aligned_storage_t is a struct with an internal array of bytes,
and suppose that emplace() constructs the object on top of the internal
array of bytes (not on top of 'this'). By my understanding, such an
implementation would keep everything valid. The aligned_storage_t object
would still exist but its internal bytes have changed to a different type. Is
my understanding flawed?
>
> Also, I don't think that it should `static_assert` if the storage doesn't
> fit the requirements of the type. It should instead use SFINAE to detect
> such things.
>
I suggested static_assert so that we could have a nice error message. I'm
not sure that SFINAE would give a great error message here and I'm not sure
if concepts is capable of expressing the idea in question. But I would find
SFINAE reasonably satisfying if that was preferred.
Thanks~
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQwwrDbT4CeWRFc52v%3DQnh1gPGvcZj1zkz9pHUdJLnspQ%40mail.gmail.com.
--001a1144f68801ec330542050bb1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>=C2=A0</div><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">On Wed, Nov 23, 2016 at 9:16 PM, Nicol Bolas <span dir=3D"ltr"=
><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gma=
il.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr">Here's the thing. The moment you call that `emp=
lace` function, the object is no longer an `aligned_storage_t` object anymo=
re. That object has had its lifetime end, and the type `U` has had its life=
time begin. So any pointers/references to the `aligned_storage_t` object ar=
e no longer valid. So `get` and `destroy` cannot be called on it.<br></div>=
</blockquote><div><br></div><div><span style=3D"font-size:12.8px">Ah, I und=
erstand what you are referring to and I don't doubt you know the standa=
rd better than I, but I just want to make sure I understand.<br></span></di=
v><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">Suppose that aligned_storage_t is a struct with an in=
ternal array of bytes, and suppose that emplace() constructs the object on =
top of the internal array of bytes (not on top of 'this'). By my un=
derstanding, such an implementation would keep everything valid. The aligne=
d_storage_t object would still exist but its internal bytes have changed to=
a different type.</span><span style=3D"font-size:12.8px">=C2=A0Is my under=
standing flawed?</span></div><div><span style=3D"font-size:12.8px"></span>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><br>Also, I don't think that it should `static_assert` if the stora=
ge doesn't fit the requirements of the type. It should instead use SFIN=
AE to detect such things.</div></blockquote><div>=C2=A0</div><div>I suggest=
ed static_assert so that we could have a nice error message. I'm not su=
re that SFINAE would give a great error message here and I'm not sure i=
f concepts is capable of expressing the idea in question. But I would find =
SFINAE reasonably satisfying if that was preferred.</div><div><br></div><di=
v>Thanks~=C2=A0</div></div><br></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQwwrDbT4CeWRFc52v%3DQnh1gPGv=
cZj1zkz9pHUdJLnspQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADbh%2BeQwwr=
DbT4CeWRFc52v%3DQnh1gPGvcZj1zkz9pHUdJLnspQ%40mail.gmail.com</a>.<br />
--001a1144f68801ec330542050bb1--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 23 Nov 2016 21:49:07 -0800 (PST)
Raw View
------=_Part_8141_739244879.1479966547542
Content-Type: multipart/alternative;
boundary="----=_Part_8142_2010823808.1479966547542"
------=_Part_8142_2010823808.1479966547542
Content-Type: text/plain; charset=UTF-8
On Thursday, November 24, 2016 at 12:11:52 AM UTC-5, Brent Friedman wrote:
>
>
> On Wed, Nov 23, 2016 at 9:16 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> Here's the thing. The moment you call that `emplace` function, the object
>> is no longer an `aligned_storage_t` object anymore. That object has had its
>> lifetime end, and the type `U` has had its lifetime begin. So any
>> pointers/references to the `aligned_storage_t` object are no longer valid.
>> So `get` and `destroy` cannot be called on it.
>>
>
> Ah, I understand what you are referring to and I don't doubt you know the
> standard better than I, but I just want to make sure I understand.
>
> Suppose that aligned_storage_t is a struct with an internal array of
> bytes, and suppose that emplace() constructs the object on top of the
> internal array of bytes (not on top of 'this').
>
Then it wouldn't be equivalent to doing `new(&some_aligned_storage)
T(...)`, would it? Either way, you're clearly talking about a very
different kind of object. `std::aligned_storage_t` is meant to act as the
storage. What you're talking about *manages* storage without giving you
direct access to it.
> By my understanding, such an implementation would keep everything valid.
> The aligned_storage_t object would still exist but its internal bytes have
> changed to a different type. Is my understanding flawed?
>
>
>>
>> Also, I don't think that it should `static_assert` if the storage doesn't
>> fit the requirements of the type. It should instead use SFINAE to detect
>> such things.
>>
>
> I suggested static_assert so that we could have a nice error message. I'm
> not sure that SFINAE would give a great error message here and I'm not sure
> if concepts is capable of expressing the idea in question.
>
The "idea in question" is merely whether the sizeof and alignof `U` is
sufficient for the specified size and alignment for the struct in question:
template<std::size_t Len, std::size_t Align>
struct aligned_storage_manager
{
template<typename U, typename ...Args>
requires sizeof(U) <= Len && alignof(U) <= Align
U &emplace(Args ...&&args) {...}
};
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0758e6c8-ae82-4633-9e0a-eb2f1699cb0f%40isocpp.org.
------=_Part_8142_2010823808.1479966547542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, November 24, 2016 at 12:11:52 AM UTC-=
5, Brent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>=C2=A0</div><div><div class=3D"gmail_quote">On Wed, Nov 23,=
2016 at 9:16 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"Br06lUuJAwAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;">jmck...@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">Here's the thing. The moment you call that `emplace` function,=
the object is no longer an `aligned_storage_t` object anymore. That object=
has had its lifetime end, and the type `U` has had its lifetime begin. So =
any pointers/references to the `aligned_storage_t` object are no longer val=
id. So `get` and `destroy` cannot be called on it.<br></div></blockquote><d=
iv><br></div><div><span style=3D"font-size:12.8px">Ah, I understand what yo=
u are referring to and I don't doubt you know the standard better than =
I, but I just want to make sure I understand.<br></span></div><div><span st=
yle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.=
8px">Suppose that aligned_storage_t is a struct with an internal array of b=
ytes, and suppose that emplace() constructs the object on top of the intern=
al array of bytes (not on top of 'this').</span></div></div></div><=
/div></blockquote><div><br>Then it wouldn't be equivalent to doing `new=
(&some_aligned_storage) T(...)`, would it? Either way, you're clear=
ly talking about a very different kind of object. `std::aligned_storage_t` =
is meant to act as the storage. What you're talking about <i>manages</i=
> storage without giving you direct access to it.<br>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div><span style=3D"font-size:12.8px">By my understanding, such an=
implementation would keep everything valid. The aligned_storage_t object w=
ould still exist but its internal bytes have changed to a different type.</=
span><span style=3D"font-size:12.8px">=C2=A0Is my understanding flawed?</sp=
an></div><div><span style=3D"font-size:12.8px"></span>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>Also, I don&#=
39;t think that it should `static_assert` if the storage doesn't fit th=
e requirements of the type. It should instead use SFINAE to detect such thi=
ngs.</div></blockquote><div>=C2=A0</div><div>I suggested static_assert so t=
hat we could have a nice error message. I'm not sure that SFINAE would =
give a great error message here and I'm not sure if concepts is capable=
of expressing the idea in question.</div></div></div></div></blockquote><d=
iv><br>The "idea in question" is merely whether the sizeof and al=
ignof `U` is sufficient for the specified size and alignment for the struct=
in question:<br><br><div style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ove=
rflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Len</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">size_t </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Align</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> aligned_storage_manager<br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> U</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">typename</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"col=
or: #606;" class=3D"styled-by-prettify">Args</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 requires </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">U</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: #660;" class=3D"styled-by-pre=
ttify"><=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Len</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n 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: #008;" class=3D"styled-by-prettify">alignof</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">U</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-prett=
ify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Alig=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 U </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">emplace</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Args</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"c=
olor: #000;" class=3D"styled-by-prettify">args</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</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></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">};</span></div></code></div></div><br><br></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0758e6c8-ae82-4633-9e0a-eb2f1699cb0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0758e6c8-ae82-4633-9e0a-eb2f1699cb0f=
%40isocpp.org</a>.<br />
------=_Part_8142_2010823808.1479966547542--
------=_Part_8141_739244879.1479966547542--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Thu, 24 Nov 2016 07:30:16 +0100
Raw View
Why not make it non-members then?
A long time ago I wrote this header file:
https://github.com/foonathan/storage/blob/master/raw_storage.hpp
Maybe add something like that, i.e. non-member emplace() and get() and
maybe destroy().
Jonathan
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe3a343a-d797-2195-4e8d-6be9a48e6849%40gmail.com.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 24 Nov 2016 15:44:11 +0800
Raw View
--Apple-Mail=_14BFFA65-2190-4B6D-A87D-B343C9580C7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9311=E2=80=9324, at 1:49 PM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> Then it wouldn't be equivalent to doing `new(&some_aligned_storage) T(...=
)`, would it? Either way, you're clearly talking about a very different kin=
d of object. `std::aligned_storage_t` is meant to act as the storage. What =
you're talking about manages storage without giving you direct access to it=
..
The proposal is to extend aligned_storage::type with a safe object manageme=
nt interface. That interface may comprise member functions that do not clob=
ber their object. Clobbering is not essential to any functionality. Likewis=
e, the user will still be free to clobber it because it=E2=80=99ll still be=
trivially destructible.
If you have a C-style union instead of std::aligned_union, you can still cl=
obber that with placement new and access it with reinterpret_cast, and some=
people do. Its members cannot be accessed in such usage, but it=E2=80=99s =
still OK.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1C08C83E-2475-48D6-955D-D4C7A071F51B%40gmail.com=
..
--Apple-Mail=_14BFFA65-2190-4B6D-A87D-B343C9580C7B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9311=
=E2=80=9324, at 1:49 PM, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><span style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; orphans: auto; text-align: start; text-indent=
: 0px; text-transform: none; white-space: normal; widows: auto; word-spacin=
g: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !impor=
tant;" class=3D"">Then it wouldn't be equivalent to doing `new(&some_al=
igned_storage) T(...)`, would it? Either way, you're clearly talking about =
a very different kind of object. `std::aligned_storage_t` is meant to act a=
s the storage. What you're talking about<span class=3D"Apple-converted-spac=
e"> </span></span><i style=3D"font-family: Helvetica; font-size: 12px;=
font-variant: normal; font-weight: normal; letter-spacing: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-sp=
ace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0p=
x;" class=3D"">manages</i><span style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px; float: none; display: inline !important;" clas=
s=3D""><span class=3D"Apple-converted-space"> </span>storage without g=
iving you direct access to it.</span><br style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote></div>=
<br class=3D""><div class=3D"">The proposal is to extend <font face=3D"Cour=
ier" class=3D"">aligned_storage::type</font> with a safe object management =
interface. That interface may comprise member functions that do not clobber=
their object. Clobbering is not essential to any functionality. Likewise, =
the user will still be free to clobber it because it=E2=80=99ll still be tr=
ivially destructible.</div><div class=3D""><br class=3D""></div><div class=
=3D"">If you have a C-style <font face=3D"Courier" class=3D"">union</font> =
instead of <font face=3D"Courier" class=3D"">std::aligned_union</font>, you=
can still clobber that with placement new and access it with <font face=3D=
"Courier" class=3D"">reinterpret_cast</font>, and some people do. Its membe=
rs cannot be accessed in such usage, but it=E2=80=99s still OK.</div><div c=
lass=3D""><br class=3D""></div></body></html>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1C08C83E-2475-48D6-955D-D4C7A071F51B%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1C08C83E-2475-48D6-955D-D4C7A071F51B%=
40gmail.com</a>.<br />
--Apple-Mail=_14BFFA65-2190-4B6D-A87D-B343C9580C7B--
.