Topic: `box` - A container which may hold exactly
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 6 Jun 2018 09:07:30 +0100
Raw View
--00000000000036650b056df4a97b
Content-Type: text/plain; charset="UTF-8"
On Wed, 6 Jun 2018 at 07:32, <daltonmwoodard@gmail.com> wrote:
> I think reframing the discussion may be helpful. Let's *define* `X<T>` to
> be a container storing at most one object of type `T`. Let's also suppose
> that the storage for that `T` is heap allocated, and that `X<>` (I'm
> writing `X<>` as an abbreviation, not the empty template parameter list)
> takes an optional second parameter satisfying Allocator, just to continue
> the theme of "container" (remember, we're defining `X<>` to be a container *a
> priori*). What are the consequences of this? First, `X<>` should support
> the expected interface for container like objects. At a minimum this
> implies the following:
>
> - default constructible, destructible, copy constructible, copy
> assignable, swappable, and equality comparable
> - `X::[c]begin()`
> - `X::[c]end()`
> - `X::size()`
> - `X::max_size()`
> - `X::empty()`
>
> Agree, but in reality these should not be defined in terms of member
functions. Ideally all interface concepts should be available as free
function overloads. This removes all concerns about "interface bloat" and
allows any type to conform to any concept simply by providing the
appropriate overloads.
> For convenience we should also supply:
>
> - `X::[c]rbegin()`
> - `X::[c]rend()`
> - relational comparison operators with lexicographic semantics, as is
> idiomatic for many container types
>
> Since `X<>` is a container it should support efficient move semantics. It
> is, therefore, move constructible and move assignable. For similar reasons,
> it should support efficient emplacement and idiomatic assignment (for
> containers). Therefore, it has:
>
> - `X::emplace()`
> - `X::assign()`
>
> Being an allocator aware container, `X<>` should also have:
>
> - `X::get_allocator()`
> - the appropriate constructor overloads for initialization with an
> allocator instance
>
> Now, for a container of zero or one objects, it is a little cumbersome to
> always write `auto& e = *x.begin();` to obtain a reference to the contained
> object, should one exist. Hence, for closure of the expressive basis it
> seems reasonable to supply accessor methods. I nominate the following as
> the name of the accessor:
>
> - `X::get()`
>
> Since we all appreciate idiomatic and consistent design, I say `X::get()`
> ought to return a pointer, keeping with the theme that the contents are
> heap allocated. And given that at most one object can be stored at a time,
> it also seems appropriate to add:
>
> - `X::operator*()`
>
> Okay, finally, let's stand back and ask why we would want to use a type
> with these semantics.
>
> First, it fills (what I perceive to be) a gap in the the family of
> traditional container types. A container with at most one element is, in
> some real sense, the trivial container (barring an always-empty container,
> which you might as well say is not a container at all). I think this can be
> quite useful for generic programming for that reason.
>
> The fact that the contents are heap allocated and that `X<>` has value
> semantics means that `X<>` neatly solves the problem of how PIMPL idiom
> state is stored.
>
> Lastly, it also has a nice affordance for defining recursive data types,
> which is only made possible by the fact that `X<>` stores its contents on
> the heap.
>
> Notice also that I have made no mention *whatsoever* of polymorphic
> types, inheritance, or reference semantics in the above discussion, just as
> you would expect for any discussion about containers. The entirety of the
> type information about `X<T>`, both static and runtime, is captured by the
> name `X<T>` -- end of story.
>
> I can also nicely sidestep questions about why `X<T>` is a container type.
> It is because I say so, by definition!
>
> Finally, we need a good name for `X<>`. As Nicole mentioned, there are
> several programming languages with types closing modeling the semantics
> I've outlined above, each named "box". I think this name is suitable, since
> the English term box connotes storage of some object(s).
>
> So, lo and behold, we've obtained Nicole's `Box<T>` from first principles
> :)
>
> --
> 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/a6347dea-6303-4ee6-8d20-51cc6466ae17%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6347dea-6303-4ee6-8d20-51cc6466ae17%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hY%3Dj4doHffcZG9bmfek9geADV4FfdroRdNhDpi7f4hoGA%40mail.gmail.com.
--00000000000036650b056df4a97b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, 6 Jun 2018 at 07:32, <<a href=3D"mailto:daltonmwoodard@gmail.com">dalt=
onmwoodard@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">I think reframing the discussion may be helpful. Let'=
s=C2=A0<i>define</i>=C2=A0`X<T>` to be a container storing at most on=
e object of type `T`. Let's also suppose that the storage for that `T` =
is heap allocated, and that `X<>` (I'm writing `X<>` as an =
abbreviation, not the empty template parameter list) takes an optional seco=
nd parameter satisfying Allocator, just to continue the theme of "cont=
ainer" (remember, we're defining `X<>` to be a container=C2=
=A0<i>a priori</i>). What are the consequences of this? First, `X<>` =
should support the expected interface for container like objects. At a mini=
mum this implies the following:<div><ul><li>default constructible, destruct=
ible, copy constructible, copy assignable, swappable, and equality comparab=
le</li><li>`X::[c]begin()`</li><li>`X::[c]end()`</li><li>`X::size()`</li><l=
i>`X::max_size()`</li><li>`X::empty()`</li></ul></div></div></blockquote><d=
iv>Agree, but in reality these should not be defined in terms of member fun=
ctions. Ideally all interface concepts should be available as free function=
overloads. This removes all concerns about "interface bloat" and=
allows any type to conform to any concept simply by providing the appropri=
ate overloads.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>For convenience we should also supply:<br></d=
iv><div><ul><li>`X::[c]rbegin()`</li><li>`X::[c]rend()`</li><li>relational =
comparison operators with lexicographic semantics, as is idiomatic for many=
container types</li></ul><div>Since `X<>` is a container it should s=
upport efficient move semantics. It is, therefore, move constructible and m=
ove assignable. For similar reasons, it should support efficient emplacemen=
t and idiomatic assignment (for containers). Therefore, it has:</div><div><=
ul><li>`X::emplace()`</li><li>`X::assign()`</li></ul></div><div><div>Being =
an allocator aware container, `X<>` should also have:</div><div><ul><=
li>`X::get_allocator()`</li><li>the appropriate constructor overloads for i=
nitialization with an allocator instance</li></ul></div></div>Now, for a co=
ntainer of zero or one objects, it is a little cumbersome to always write `=
auto& e =3D *x.begin();` to obtain a reference to the contained object,=
should one exist. Hence, for closure of the expressive basis it seems reas=
onable to supply accessor methods. I nominate the following as the name of =
the accessor:</div><div><ul><li>`X::get()`</li></ul><div>Since we all appre=
ciate idiomatic and consistent design, I say `X::get()` ought to return a p=
ointer, keeping with the theme that the contents are heap allocated. And gi=
ven that at most one object can be stored at a time, it also seems appropri=
ate to add:</div></div><div><ul><li>`X::operator*()`</li></ul><div>Okay, fi=
nally, let's stand back and ask why we would want to use a type with th=
ese semantics.</div><div><br></div><div>First, it fills (what I perceive to=
be) a gap in the the family of traditional container types. A container wi=
th at most one element is, in some real sense, the trivial container (barri=
ng an always-empty container, which you might as well say is not a containe=
r at all). I think this can be quite useful for generic programming for tha=
t reason.</div><div><br></div><div>The fact that the contents are heap allo=
cated and that `X<>` has value semantics means that `X<>` neatl=
y solves the problem of how PIMPL idiom state is stored.=C2=A0</div><div><b=
r></div><div>Lastly, it also has a nice affordance for defining recursive d=
ata types, which is only made possible by the fact that `X<>` stores =
its contents on the heap.</div></div><div><br></div><div>Notice also that I=
have made no mention <i>whatsoever</i>=C2=A0of polymorphic types, inherita=
nce, or reference semantics in the above discussion, just as you would expe=
ct for any discussion about containers. The entirety of the type informatio=
n about `X<T>`, both static and runtime, is captured by the name `X&l=
t;T>` -- end of story.</div><div><br></div><div>I can also nicely sidest=
ep questions about why `X<T>` is a container type. It is because I sa=
y so, by definition!</div><div><br></div><div>Finally, we need a good name =
for `X<>`. As Nicole mentioned, there are several programming languag=
es with types closing modeling the semantics I've outlined above, each =
named "box". I think this name is suitable, since the English ter=
m box connotes storage of some object(s).</div><div><br></div><div>So, lo a=
nd behold, we've obtained Nicole's `Box<T>` from first princi=
ples :)</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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a6347dea-6303-4ee6-8d20-51cc6466ae17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6347dea-6303-=
4ee6-8d20-51cc6466ae17%40isocpp.org</a>.<br>
</blockquote></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/CALvx3hY%3Dj4doHffcZG9bmfek9geADV4Ffd=
roRdNhDpi7f4hoGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hY%3Dj4do=
HffcZG9bmfek9geADV4FfdroRdNhDpi7f4hoGA%40mail.gmail.com</a>.<br />
--00000000000036650b056df4a97b--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Wed, 6 Jun 2018 07:45:03 -0700
Raw View
--000000000000f82270056dfa3618
Content-Type: text/plain; charset="UTF-8"
If you want to complain about the interface for containers, go back in time
twenty-five years and rewrite the STL. This is not the thread to do it in.
On Wed, Jun 6, 2018, 01:07 Richard Hodges <hodges.r@gmail.com> wrote:
>
>
> On Wed, 6 Jun 2018 at 07:32, <daltonmwoodard@gmail.com> wrote:
>
>> I think reframing the discussion may be helpful. Let's *define* `X<T>`
>> to be a container storing at most one object of type `T`. Let's also
>> suppose that the storage for that `T` is heap allocated, and that `X<>`
>> (I'm writing `X<>` as an abbreviation, not the empty template parameter
>> list) takes an optional second parameter satisfying Allocator, just to
>> continue the theme of "container" (remember, we're defining `X<>` to be a
>> container *a priori*). What are the consequences of this? First, `X<>`
>> should support the expected interface for container like objects. At a
>> minimum this implies the following:
>>
>> - default constructible, destructible, copy constructible, copy
>> assignable, swappable, and equality comparable
>> - `X::[c]begin()`
>> - `X::[c]end()`
>> - `X::size()`
>> - `X::max_size()`
>> - `X::empty()`
>>
>> Agree, but in reality these should not be defined in terms of member
> functions. Ideally all interface concepts should be available as free
> function overloads. This removes all concerns about "interface bloat" and
> allows any type to conform to any concept simply by providing the
> appropriate overloads.
>
>
>
>> For convenience we should also supply:
>>
>> - `X::[c]rbegin()`
>> - `X::[c]rend()`
>> - relational comparison operators with lexicographic semantics, as is
>> idiomatic for many container types
>>
>> Since `X<>` is a container it should support efficient move semantics. It
>> is, therefore, move constructible and move assignable. For similar reasons,
>> it should support efficient emplacement and idiomatic assignment (for
>> containers). Therefore, it has:
>>
>> - `X::emplace()`
>> - `X::assign()`
>>
>> Being an allocator aware container, `X<>` should also have:
>>
>> - `X::get_allocator()`
>> - the appropriate constructor overloads for initialization with an
>> allocator instance
>>
>> Now, for a container of zero or one objects, it is a little cumbersome to
>> always write `auto& e = *x.begin();` to obtain a reference to the contained
>> object, should one exist. Hence, for closure of the expressive basis it
>> seems reasonable to supply accessor methods. I nominate the following as
>> the name of the accessor:
>>
>> - `X::get()`
>>
>> Since we all appreciate idiomatic and consistent design, I say `X::get()`
>> ought to return a pointer, keeping with the theme that the contents are
>> heap allocated. And given that at most one object can be stored at a time,
>> it also seems appropriate to add:
>>
>> - `X::operator*()`
>>
>> Okay, finally, let's stand back and ask why we would want to use a type
>> with these semantics.
>>
>> First, it fills (what I perceive to be) a gap in the the family of
>> traditional container types. A container with at most one element is, in
>> some real sense, the trivial container (barring an always-empty container,
>> which you might as well say is not a container at all). I think this can be
>> quite useful for generic programming for that reason.
>>
>> The fact that the contents are heap allocated and that `X<>` has value
>> semantics means that `X<>` neatly solves the problem of how PIMPL idiom
>> state is stored.
>>
>> Lastly, it also has a nice affordance for defining recursive data types,
>> which is only made possible by the fact that `X<>` stores its contents on
>> the heap.
>>
>> Notice also that I have made no mention *whatsoever* of polymorphic
>> types, inheritance, or reference semantics in the above discussion, just as
>> you would expect for any discussion about containers. The entirety of the
>> type information about `X<T>`, both static and runtime, is captured by the
>> name `X<T>` -- end of story.
>>
>> I can also nicely sidestep questions about why `X<T>` is a container
>> type. It is because I say so, by definition!
>>
>> Finally, we need a good name for `X<>`. As Nicole mentioned, there are
>> several programming languages with types closing modeling the semantics
>> I've outlined above, each named "box". I think this name is suitable, since
>> the English term box connotes storage of some object(s).
>>
>> So, lo and behold, we've obtained Nicole's `Box<T>` from first principles
>> :)
>>
>> --
>> 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/a6347dea-6303-4ee6-8d20-51cc6466ae17%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6347dea-6303-4ee6-8d20-51cc6466ae17%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Bx-M4_Qik2U/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CALvx3hY%3Dj4doHffcZG9bmfek9geADV4FfdroRdNhDpi7f4hoGA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hY%3Dj4doHffcZG9bmfek9geADV4FfdroRdNhDpi7f4hoGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEwx-OuUvjsgbrzy2AjozW7SNRM_D%2BsKKg7_aZih3DPi_nzAdg%40mail.gmail.com.
--000000000000f82270056dfa3618
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">If you want to complain about the interface for container=
s, go back in time twenty-five years and rewrite the STL. This is not the t=
hread to do it in.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Wed, Jun 6, 2018, 01:07 Richard Hodges <<a href=3D"mailto:hodges.r@gmail=
..com">hodges.r@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Wed, 6 Jun 2018 at 07:32, <<a href=3D"mailto:daltonmwoodard@gmail.com"=
target=3D"_blank" rel=3D"noreferrer">daltonmwoodard@gmail.com</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think reframi=
ng the discussion may be helpful. Let's=C2=A0<i>define</i>=C2=A0`X<T=
>` to be a container storing at most one object of type `T`. Let's a=
lso suppose that the storage for that `T` is heap allocated, and that `X<=
;>` (I'm writing `X<>` as an abbreviation, not the empty templ=
ate parameter list) takes an optional second parameter satisfying Allocator=
, just to continue the theme of "container" (remember, we're =
defining `X<>` to be a container=C2=A0<i>a priori</i>). What are the =
consequences of this? First, `X<>` should support the expected interf=
ace for container like objects. At a minimum this implies the following:<di=
v><ul><li>default constructible, destructible, copy constructible, copy ass=
ignable, swappable, and equality comparable</li><li>`X::[c]begin()`</li><li=
>`X::[c]end()`</li><li>`X::size()`</li><li>`X::max_size()`</li><li>`X::empt=
y()`</li></ul></div></div></blockquote><div>Agree, but in reality these sho=
uld not be defined in terms of member functions. Ideally all interface conc=
epts should be available as free function overloads. This removes all conce=
rns about "interface bloat" and allows any type to conform to any=
concept simply by providing the appropriate overloads.</div><div><br></div=
><div>=C2=A0</div><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>For =
convenience we should also supply:<br></div><div><ul><li>`X::[c]rbegin()`</=
li><li>`X::[c]rend()`</li><li>relational comparison operators with lexicogr=
aphic semantics, as is idiomatic for many container types</li></ul><div>Sin=
ce `X<>` is a container it should support efficient move semantics. I=
t is, therefore, move constructible and move assignable. For similar reason=
s, it should support efficient emplacement and idiomatic assignment (for co=
ntainers). Therefore, it has:</div><div><ul><li>`X::emplace()`</li><li>`X::=
assign()`</li></ul></div><div><div>Being an allocator aware container, `X&l=
t;>` should also have:</div><div><ul><li>`X::get_allocator()`</li><li>th=
e appropriate constructor overloads for initialization with an allocator in=
stance</li></ul></div></div>Now, for a container of zero or one objects, it=
is a little cumbersome to always write `auto& e =3D *x.begin();` to ob=
tain a reference to the contained object, should one exist. Hence, for clos=
ure of the expressive basis it seems reasonable to supply accessor methods.=
I nominate the following as the name of the accessor:</div><div><ul><li>`X=
::get()`</li></ul><div>Since we all appreciate idiomatic and consistent des=
ign, I say `X::get()` ought to return a pointer, keeping with the theme tha=
t the contents are heap allocated. And given that at most one object can be=
stored at a time, it also seems appropriate to add:</div></div><div><ul><l=
i>`X::operator*()`</li></ul><div>Okay, finally, let's stand back and as=
k why we would want to use a type with these semantics.</div><div><br></div=
><div>First, it fills (what I perceive to be) a gap in the the family of tr=
aditional container types. A container with at most one element is, in some=
real sense, the trivial container (barring an always-empty container, whic=
h you might as well say is not a container at all). I think this can be qui=
te useful for generic programming for that reason.</div><div><br></div><div=
>The fact that the contents are heap allocated and that `X<>` has val=
ue semantics means that `X<>` neatly solves the problem of how PIMPL =
idiom state is stored.=C2=A0</div><div><br></div><div>Lastly, it also has a=
nice affordance for defining recursive data types, which is only made poss=
ible by the fact that `X<>` stores its contents on the heap.</div></d=
iv><div><br></div><div>Notice also that I have made no mention <i>whatsoeve=
r</i>=C2=A0of polymorphic types, inheritance, or reference semantics in the=
above discussion, just as you would expect for any discussion about contai=
ners. The entirety of the type information about `X<T>`, both static =
and runtime, is captured by the name `X<T>` -- end of story.</div><di=
v><br></div><div>I can also nicely sidestep questions about why `X<T>=
` is a container type. It is because I say so, by definition!</div><div><br=
></div><div>Finally, we need a good name for `X<>`. As Nicole mention=
ed, there are several programming languages with types closing modeling the=
semantics I've outlined above, each named "box". I think thi=
s name is suitable, since the English term box connotes storage of some obj=
ect(s).</div><div><br></div><div>So, lo and behold, we've obtained Nico=
le's `Box<T>` from first principles :)</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" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/a6347dea-6303-4ee6-8d20-51cc6466ae17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/a6347dea-6303-4ee6-8d20-51cc6466ae17%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Bx-M4_Qik2U/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/Bx-M4_Qik2U/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank" rel=3D"n=
oreferrer">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" rel=3D"noreferrer">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/CALvx3hY%3Dj4doHffcZG9bmfek9geADV4Ffd=
roRdNhDpi7f4hoGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CALvx3hY%3Dj4doHffcZG9bmfek9geADV4FfdroRdNhDpi7f4=
hoGA%40mail.gmail.com</a>.<br>
</blockquote></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/CAEwx-OuUvjsgbrzy2AjozW7SNRM_D%2BsKKg=
7_aZih3DPi_nzAdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEwx-OuUvjsgbr=
zy2AjozW7SNRM_D%2BsKKg7_aZih3DPi_nzAdg%40mail.gmail.com</a>.<br />
--000000000000f82270056dfa3618--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Wed, 6 Jun 2018 07:47:20 -0700
Raw View
--00000000000014c807056dfa3f87
Content-Type: text/plain; charset="UTF-8"
This is just not true.
1) the word container does not imply anything about collection - it implies
"holds something".
2) collections of zero or one objects are entirely reasonable - the "empty
set", or the "set containing the empty set" are both very useful
collections.
On Wed, Jun 6, 2018, 00:24 <mihailnajdenov@gmail.com> wrote:
> The problem is by 'containers' we really mean 'collections', we really do.
>
> By definition a collection is something of more then one item, hence the
> debate.
>
> On Wednesday, June 6, 2018 at 9:32:52 AM UTC+3, daltonm...@gmail.com
> wrote:
>>
>> I think reframing the discussion may be helpful. Let's *define* `X<T>`
>> to be a container storing at most one object of type `T`. Let's also
>> suppose that the storage for that `T` is heap allocated, and that `X<>`
>> (I'm writing `X<>` as an abbreviation, not the empty template parameter
>> list) takes an optional second parameter satisfying Allocator, just to
>> continue the theme of "container" (remember, we're defining `X<>` to be a
>> container *a priori*). What are the consequences of this? First, `X<>`
>> should support the expected interface for container like objects. At a
>> minimum this implies the following:
>>
>> - default constructible, destructible, copy constructible, copy
>> assignable, swappable, and equality comparable
>> - `X::[c]begin()`
>> - `X::[c]end()`
>> - `X::size()`
>> - `X::max_size()`
>> - `X::empty()`
>>
>> For convenience we should also supply:
>>
>> - `X::[c]rbegin()`
>> - `X::[c]rend()`
>> - relational comparison operators with lexicographic semantics, as is
>> idiomatic for many container types
>>
>> Since `X<>` is a container it should support efficient move semantics. It
>> is, therefore, move constructible and move assignable. For similar reasons,
>> it should support efficient emplacement and idiomatic assignment (for
>> containers). Therefore, it has:
>>
>> - `X::emplace()`
>> - `X::assign()`
>>
>> Being an allocator aware container, `X<>` should also have:
>>
>> - `X::get_allocator()`
>> - the appropriate constructor overloads for initialization with an
>> allocator instance
>>
>> Now, for a container of zero or one objects, it is a little cumbersome to
>> always write `auto& e = *x.begin();` to obtain a reference to the contained
>> object, should one exist. Hence, for closure of the expressive basis it
>> seems reasonable to supply accessor methods. I nominate the following as
>> the name of the accessor:
>>
>> - `X::get()`
>>
>> Since we all appreciate idiomatic and consistent design, I say `X::get()`
>> ought to return a pointer, keeping with the theme that the contents are
>> heap allocated. And given that at most one object can be stored at a time,
>> it also seems appropriate to add:
>>
>> - `X::operator*()`
>>
>> Okay, finally, let's stand back and ask why we would want to use a type
>> with these semantics.
>>
>> First, it fills (what I perceive to be) a gap in the the family of
>> traditional container types. A container with at most one element is, in
>> some real sense, the trivial container (barring an always-empty container,
>> which you might as well say is not a container at all). I think this can be
>> quite useful for generic programming for that reason.
>>
>> The fact that the contents are heap allocated and that `X<>` has value
>> semantics means that `X<>` neatly solves the problem of how PIMPL idiom
>> state is stored.
>>
>> Lastly, it also has a nice affordance for defining recursive data types,
>> which is only made possible by the fact that `X<>` stores its contents on
>> the heap.
>>
>> Notice also that I have made no mention *whatsoever* of polymorphic
>> types, inheritance, or reference semantics in the above discussion, just as
>> you would expect for any discussion about containers. The entirety of the
>> type information about `X<T>`, both static and runtime, is captured by the
>> name `X<T>` -- end of story.
>>
>> I can also nicely sidestep questions about why `X<T>` is a container
>> type. It is because I say so, by definition!
>>
>> Finally, we need a good name for `X<>`. As Nicole mentioned, there are
>> several programming languages with types closing modeling the semantics
>> I've outlined above, each named "box". I think this name is suitable, since
>> the English term box connotes storage of some object(s).
>>
>> So, lo and behold, we've obtained Nicole's `Box<T>` from first principles
>> :)
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Bx-M4_Qik2U/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/f3d20f67-ff7c-441e-9d56-26424e639c39%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f3d20f67-ff7c-441e-9d56-26424e639c39%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEwx-OunVZ-H7UtC65mZuWxk15YiKozSdf_d6dvJ%3DPigd1Q45A%40mail.gmail.com.
--00000000000014c807056dfa3f87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">This is just not true.<div dir=3D"auto"><br></div><div di=
r=3D"auto">1) the word container does not imply anything about collection -=
it implies "holds something".</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">2) collections of zero or one objects are entirely reasona=
ble - the "empty set", or the "set containing the empty set&=
quot; are both very useful collections.</div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr">On Wed, Jun 6, 2018, 00:24 <<a href=3D"mailto:m=
ihailnajdenov@gmail.com">mihailnajdenov@gmail.com</a>> wrote:<br></div><=
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>The problem is by '=
containers' we really mean 'collections', we really do.=C2=A0</=
div><div><br></div><div>By definition a collection is something of more the=
n one item, hence the debate.</div><br>On Wednesday, June 6, 2018 at 9:32:5=
2 AM UTC+3, <a href=3D"mailto:daltonm...@gmail.com" target=3D"_blank" rel=
=3D"noreferrer">daltonm...@gmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">I think reframing the discussion may be helpfu=
l. Let's=C2=A0<i>define</i>=C2=A0`X<T>` to be a container storing=
at most one object of type `T`. Let's also suppose that the storage fo=
r that `T` is heap allocated, and that `X<>` (I'm writing `X<&=
gt;` as an abbreviation, not the empty template parameter list) takes an op=
tional second parameter satisfying Allocator, just to continue the theme of=
"container" (remember, we're defining `X<>` to be a co=
ntainer=C2=A0<i>a priori</i>). What are the consequences of this? First, `X=
<>` should support the expected interface for container like objects.=
At a minimum this implies the following:<div><ul><li>default constructible=
, destructible, copy constructible, copy assignable, swappable, and equalit=
y comparable</li><li>`X::[c]begin()`</li><li>`X::[c]end()`</li><li>`X::size=
()`</li><li>`X::max_size()`</li><li>`X::empty()`</li></ul></div><div>For co=
nvenience we should also supply:<br></div><div><ul><li>`X::[c]rbegin()`</li=
><li>`X::[c]rend()`</li><li>relational comparison operators with lexicograp=
hic semantics, as is idiomatic for many container types</li></ul><div>Since=
`X<>` is a container it should support efficient move semantics. It =
is, therefore, move constructible and move assignable. For similar reasons,=
it should support efficient emplacement and idiomatic assignment (for cont=
ainers). Therefore, it has:</div><div><ul><li>`X::emplace()`</li><li>`X::as=
sign()`</li></ul></div><div><div>Being an allocator aware container, `X<=
>` should also have:</div><div><ul><li>`X::get_allocator()`</li><li>the =
appropriate constructor overloads for initialization with an allocator inst=
ance</li></ul></div></div>Now, for a container of zero or one objects, it i=
s a little cumbersome to always write `auto& e =3D *x.begin();` to obta=
in a reference to the contained object, should one exist. Hence, for closur=
e of the expressive basis it seems reasonable to supply accessor methods. I=
nominate the following as the name of the accessor:</div><div><ul><li>`X::=
get()`</li></ul><div>Since we all appreciate idiomatic and consistent desig=
n, I say `X::get()` ought to return a pointer, keeping with the theme that =
the contents are heap allocated. And given that at most one object can be s=
tored at a time, it also seems appropriate to add:</div></div><div><ul><li>=
`X::operator*()`</li></ul><div>Okay, finally, let's stand back and ask =
why we would want to use a type with these semantics.</div><div><br></div><=
div>First, it fills (what I perceive to be) a gap in the the family of trad=
itional container types. A container with at most one element is, in some r=
eal sense, the trivial container (barring an always-empty container, which =
you might as well say is not a container at all). I think this can be quite=
useful for generic programming for that reason.</div><div><br></div><div>T=
he fact that the contents are heap allocated and that `X<>` has value=
semantics means that `X<>` neatly solves the problem of how PIMPL id=
iom state is stored.=C2=A0</div><div><br></div><div>Lastly, it also has a n=
ice affordance for defining recursive data types, which is only made possib=
le by the fact that `X<>` stores its contents on the heap.</div></div=
><div><br></div><div>Notice also that I have made no mention <i>whatsoever<=
/i>=C2=A0of polymorphic types, inheritance, or reference semantics in the a=
bove discussion, just as you would expect for any discussion about containe=
rs. The entirety of the type information about `X<T>`, both static an=
d runtime, is captured by the name `X<T>` -- end of story.</div><div>=
<br></div><div>I can also nicely sidestep questions about why `X<T>` =
is a container type. It is because I say so, by definition!</div><div><br><=
/div><div>Finally, we need a good name for `X<>`. As Nicole mentioned=
, there are several programming languages with types closing modeling the s=
emantics I've outlined above, each named "box". I think this =
name is suitable, since the English term box connotes storage of some objec=
t(s).</div><div><br></div><div>So, lo and behold, we've obtained Nicole=
's `Box<T>` from first principles :)</div></div></blockquote></di=
v>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Bx-M4_Qik2U/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/Bx-M4_Qik2U/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank" rel=3D"n=
oreferrer">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" rel=3D"noreferrer">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/f3d20f67-ff7c-441e-9d56-26424e639c39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/f3d20f67-ff7c-441e-9d56-26424e639c39%40isocpp.org</a>.<br>
</blockquote></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/CAEwx-OunVZ-H7UtC65mZuWxk15YiKozSdf_d=
6dvJ%3DPigd1Q45A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEwx-OunVZ-H7U=
tC65mZuWxk15YiKozSdf_d6dvJ%3DPigd1Q45A%40mail.gmail.com</a>.<br />
--00000000000014c807056dfa3f87--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 14 Jun 2018 08:05:40 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">It was being allocated to enable recursive data structures, whi=
ch was one of the original motivating use cases.</div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
73, 125); text-align: initial; background-color: rgb(255, 255, 255);">As t=
hat's an essential part of the design, I might include it in the name, ie h=
eaped_box or heaped_value or something like that. (Just box is too generic =
- there are many different types of boxes)</div> =
=
<div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br=
style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);">Sent from my BlackBerry =
portable Babbage Device</div> =
=
<table w=
idth=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody>=
<tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; bac=
kground-color: rgb(255, 255, 255);"> <div style=
=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223); bo=
rder-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha S=
ans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Bengt Gustafsson</=
div><div><b>Sent: </b>Thursday, June 14, 2018 3:02 AM</div><div><b>To: </b>=
ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-proposal=
s@isocpp.org</div><div><b>Subject: </b>[std-proposals] Re: `box` - A contai=
ner which may hold exactly zero or one objects</div></div></td></tr></tbody=
></table><div style=3D"border-style: solid none none; border-top-color: rgb=
(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: ini=
tial; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_original=
Content" style=3D""><div dir=3D"ltr">Can't the box<T> container be vi=
ewed as a one element instance of a general capped_vector<T, N> type?=
<div><br></div><div>A capped_vector would allocate room for N elements but =
only construct them when they are inserted. I think there are many use case=
s for such an intermediate container between std::array and std::vector, an=
d I hope that the games/realtime group is working on a proposal.</div><div>=
<br></div><div>I don't see a reason to allocate the element of box<T>=
on the heap if copy semantics is deep anyway and it is not polymorphic. If=
it is polymorphic it is similar to deep_ptr which has been proposed before=
but has severe problems with actually being able to clone the pointee if i=
t is possible to copy back and forth between deep_ptr<BASE> and deep_=
ptr<SUB>, who knows what it actually points to? This turned out to be=
a rabbit hole in the absence of a standardized way of cloning any object.<=
/div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/42c9f24d-3ea5-4752-afcc-6139c9b29be6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/42c9f24d-3ea5-4752-afcc-6139c9b2=
9be6%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></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/20180614120540.5202000.78783.55097%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20180614120540.5202000.78783.55097%40gm=
ail.com</a>.<br />
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 14 Jun 2018 13:30:14 +0100
Raw View
--000000000000bbf7ec056e99432e
Content-Type: text/plain; charset="UTF-8"
On Thu, 14 Jun 2018, 13:05 Tony V E, <tvaneerd@gmail.com> wrote:
> It was being allocated to enable recursive data structures, which was one
> of the original motivating use cases.
>
Doesn't boost.variant have a recursive_wrapper? That seems like a
reasonable and expressive name.
I can't imagine why it does not form part of the std variant.
>
> As that's an essential part of the design, I might include it in the name,
> ie heaped_box or heaped_value or something like that. (Just box is too
> generic - there are many different types of boxes)
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Bengt Gustafsson
> *Sent: *Thursday, June 14, 2018 3:02 AM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-proposals@isocpp.org
> *Subject: *[std-proposals] Re: `box` - A container which may hold exactly
> zero or one objects
>
> Can't the box<T> container be viewed as a one element instance of a
> general capped_vector<T, N> type?
>
> A capped_vector would allocate room for N elements but only construct them
> when they are inserted. I think there are many use cases for such an
> intermediate container between std::array and std::vector, and I hope that
> the games/realtime group is working on a proposal.
>
> I don't see a reason to allocate the element of box<T> on the heap if copy
> semantics is deep anyway and it is not polymorphic. If it is polymorphic it
> is similar to deep_ptr which has been proposed before but has severe
> problems with actually being able to clone the pointee if it is possible to
> copy back and forth between deep_ptr<BASE> and deep_ptr<SUB>, who knows
> what it actually points to? This turned out to be a rabbit hole in the
> absence of a standardized way of cloning any object.
>
> --
> 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/42c9f24d-3ea5-4752-afcc-6139c9b29be6%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/42c9f24d-3ea5-4752-afcc-6139c9b29be6%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
> --
> 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/20180614120540.5202000.78783.55097%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180614120540.5202000.78783.55097%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hYyRfX5uY0G0_Dk7fTMiuic1SjjsyrNaiiOmBDjRE8Log%40mail.gmail.com.
--000000000000bbf7ec056e99432e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Thu, 14 Jun 2018, 13:05 Tony V E, <<a href=3D"mailto:tvaneerd@gmail.c=
om">tvaneerd@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div lang=3D"en-US" style=3D"background-color:rgb(255,255,255);line-heig=
ht:initial"> =
<div style=3D"width:100%;font-size:initial;font-fami=
ly:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);t=
ext-align:initial;background-color:rgb(255,255,255)">It was being allocated=
to enable recursive data structures, which was one of the original motivat=
ing use cases.</div><div style=3D"width:100%;font-size:initial;font-family:=
Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text=
-align:initial;background-color:rgb(255,255,255)"></div></div></blockquote>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Doesn't boost=
..variant have a recursive_wrapper? That seems like a reasonable and express=
ive name.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I can't im=
agine why it does not form part of the std variant.=C2=A0</div><div dir=3D"=
auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=
=3D"en-US" style=3D"background-color:rgb(255,255,255);line-height:initial">=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate P=
ro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backg=
round-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:=
initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color=
:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">As th=
at's an essential part of the design, I might include it in the name, i=
e heaped_box or heaped_value or something like that. (Just box is too gener=
ic - there are many different types of boxes)</div> =
=
<div style=3D"width:100%;font-size:initia=
l;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(3=
1,73,125);text-align:initial;background-color:rgb(255,255,255)"><br style=
=3D"display:initial"></div> =
=
<di=
v style=3D"font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0B=
abbage=C2=A0Device</div> =
=
<table width=3D"100%" s=
tyle=3D"background-color:white;border-spacing:0px"> <tbody><tr><td colspan=
=3D"2" style=3D"font-size:initial;text-align:initial;background-color:rgb(2=
55,255,255)"> <div style=3D"border-style:solid no=
ne none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt =
0in 0in;font-family:Tahoma,'BB Alpha Sans','Slate Pro';font=
-size:10pt"> <div><b>From: </b>Bengt Gustafsson</div><div><b>Sent: </b>Thu=
rsday, June 14, 2018 3:02 AM</div><div><b>To: </b>ISO C++ Standard - Future=
Proposals</div><div><b>Reply To: </b><a href=3D"mailto:std-proposals@isocp=
p.org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a></d=
iv><div><b>Subject: </b>[std-proposals] Re: `box` - A container which may h=
old exactly zero or one objects</div></div></td></tr></tbody></table><div s=
tyle=3D"border-style:solid none none;border-top-color:rgb(186,188,209);bord=
er-top-width:1pt;font-size:initial;text-align:initial;background-color:rgb(=
255,255,255)"></div><br><div id=3D"m_-7053042095564998667_originalContent">=
<div dir=3D"ltr">Can't the box<T> container be viewed as a one el=
ement instance of a general capped_vector<T, N> type?<div><br></div><=
div>A capped_vector would allocate room for N elements but only construct t=
hem when they are inserted. I think there are many use cases for such an in=
termediate container between std::array and std::vector, and I hope that th=
e games/realtime group is working on a proposal.</div><div><br></div><div>I=
don't see a reason to allocate the element of box<T> on the heap=
if copy semantics is deep anyway and it is not polymorphic. If it is polym=
orphic it is similar to deep_ptr which has been proposed before but has sev=
ere problems with actually being able to clone the pointee if it is possibl=
e to copy back and forth between deep_ptr<BASE> and deep_ptr<SUB&g=
t;, who knows what it actually points to? This turned out to be a rabbit ho=
le in the absence of a standardized way of cloning any object.</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" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/42c9f24d-3ea5-4752-afcc-6139c9b29be6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/42c9f24d-3ea5-4752-afcc-6139c9b29be6%40isocpp.org</a>.<br>
<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" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/20180614120540.5202000.78783.55097%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" rel=
=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposal=
s/20180614120540.5202000.78783.55097%40gmail.com</a>.<br>
</blockquote></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/CALvx3hYyRfX5uY0G0_Dk7fTMiuic1SjjsyrN=
aiiOmBDjRE8Log%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYyRfX5uY0G=
0_Dk7fTMiuic1SjjsyrNaiiOmBDjRE8Log%40mail.gmail.com</a>.<br />
--000000000000bbf7ec056e99432e--
.