------=_Part_726_1401208160.1418673005929
Content-Type: multipart/alternative;
 boundary="----=_Part_727_799872118.1418673005929"

------=_Part_727_799872118.1418673005929
Content-Type: text/plain; charset=UTF-8

You sometimes want to have classes with variables that cannot be changed
after the object has been created. For example:

class point_cloud {
private:
    point* const buffer_;
    const std::size_t buffer_size_;
    const std::string original_name_;

public:
    explicit point_cloud(point_cloud_reader&);
    ~point_cloud();

    ...
};

Here the buffer is allocated only once on construction, and all of its
variables cannot be changed afterwards. However it is still possible to
change the contents of the buffer. Imposing such restrictions on a class
can often simplify coding, since you don't have to define semantics for
assignment, or handling side effects of changing properties of an object
that are also defined at construction.

For example a class representing a camera in 3D space might contain both a
projection matrix and its inverse. It would have to be recalculated each
time the camera's parameters are changed. But it would also have been
possible to just create a new camera instance with new parameters. So the
class could be left immutable, avoiding overcomplicating the code without
much gain in functionality.

The only problem is that immutable objects cannot implement an assignment
operator=, since this is meant to change the object, and not create a new
one in-place. To reuse the same variable, a possible workaround currently
is to use call destructor and then use placement new:

immutable obj(1, 2);
obj.f();
//obj = immutable(2, 3);   not possible, instead:
obj.~ immutable();
new(&obj) immutable(2, 3);
obj.f();

Eigen actually recommends this for its Map class:
http://eigen.tuxfamily.org/dox/group__TutorialMapClass.html.

My idea would be to introduce reinitialization of objects as a language
feature or into the STL library. std::optional
<http://en.cppreference.com/w/cpp/experimental/optional> currently expect
the object to be assignable if an engaged optional is reassigned a new
value. If it is not engaged however, it constructs a new object as above.
Maybe introduce a class:

std::reusable<immutable> obj(1, 2);
obj->f();
obj.replace(1, 2);
obj->f();

Or maybe an alternative operator to the assignment operator that destructs
the object and creates a new one in-place.

--

---
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_727_799872118.1418673005929
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You sometimes want to have classes with variables that can=
not be changed after the object has been created. For example:<div><br></di=
v><div><font face=3D"courier new, monospace">class point_cloud {</font></di=
v><div><font face=3D"courier new, monospace">private:</font></div><div><fon=
t face=3D"courier new, monospace">&nbsp; &nbsp; point* const buffer_;</font=
></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; const std::=
size_t buffer_size_;</font></div><div><font face=3D"courier new, monospace"=
>&nbsp; &nbsp; const std::string original_name_;</font></div><div><font fac=
e=3D"courier new, monospace"><br></font></div><div><font face=3D"courier ne=
w, monospace">public:</font></div><div><font face=3D"courier new, monospace=
">&nbsp; &nbsp; explicit point_cloud(point_cloud_reader&amp;);</font></div>=
<div><font face=3D"courier new, monospace">&nbsp; &nbsp; ~point_cloud();</f=
ont></div><div><font face=3D"courier new, monospace"><br></font></div><div>=
<font face=3D"courier new, monospace">&nbsp; &nbsp; ...</font></div><div><f=
ont face=3D"courier new, monospace">};</font></div><div><br></div><div>Here=
 the buffer is allocated only once on construction, and all of its variable=
s cannot be changed afterwards. However it is still possible to change the =
contents of the buffer. Imposing such restrictions on a class can often sim=
plify coding, since you don't have to define semantics for assignment, or h=
andling side effects of changing properties of an object that are also defi=
ned at construction.</div><div><br></div><div>For example a class represent=
ing a camera in 3D space might contain both a projection matrix and its inv=
erse. It would have to be recalculated each time the camera's parameters ar=
e changed. But it would also have been possible to just create a new camera=
 instance with new parameters. So the class could be left immutable, avoidi=
ng overcomplicating the code without much gain in functionality.</div><div>=
<br></div><div>The only problem is that immutable objects cannot implement =
an assignment operator=3D, since this is meant to change the object, and no=
t create a new one in-place. To reuse the same variable, a possible workaro=
und currently is to use call destructor and then use placement new:</div><d=
iv><br></div><div><font face=3D"courier new, monospace">immutable obj(1, 2)=
;</font></div><div><font face=3D"courier new, monospace">obj.f();</font></d=
iv><div><font face=3D"courier new, monospace">//obj =3D immutable(2, 3); &n=
bsp; not possible, instead:</font></div><div><font face=3D"courier new, mon=
ospace">obj.~ immutable();</font></div><div><font face=3D"courier new, mono=
space">new(&amp;obj) immutable(2, 3);</font></div><div><font face=3D"courie=
r new, monospace">obj.f();</font></div><div><br></div><div>Eigen actually r=
ecommends this for its Map class: <a href=3D"http://eigen.tuxfamily.org/dox=
/group__TutorialMapClass.html">http://eigen.tuxfamily.org/dox/group__Tutori=
alMapClass.html</a>.</div><div><br></div><div>My idea would be to introduce=
 reinitialization of objects as a language feature or into the STL library.=
 <a href=3D"http://en.cppreference.com/w/cpp/experimental/optional">std::op=
tional</a> currently expect the object to be assignable if an engaged optio=
nal is reassigned a new value. If it is not engaged however, it constructs =
a new object as above. Maybe introduce a class:</div><div><br></div><div><f=
ont face=3D"courier new, monospace">std::reusable&lt;immutable&gt; obj(1, 2=
);</font></div><div><font face=3D"courier new, monospace">obj-&gt;f();</fon=
t></div><div><font face=3D"courier new, monospace">obj.replace(1, 2);</font=
></div><div><font face=3D"courier new, monospace">obj-&gt;f();</font></div>=
<div><font face=3D"courier new, monospace"><br></font></div><div>Or maybe a=
n alternative operator to the assignment operator that destructs the object=
 and creates a new one in-place.<font face=3D"courier new, monospace"><br><=
/font></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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 />
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_727_799872118.1418673005929--
------=_Part_726_1401208160.1418673005929--

.

--Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would worry that references to the supposedly immutable object would be l=
ogically invalidated.



> On 15 Dec 2014, at 19:50, tl <timlenertz@gmail.com> wrote:
>=20
> You sometimes want to have classes with variables that cannot be changed =
after the object has been created. For example:
>=20
> class point_cloud {
> private:
>     point* const buffer_;
>     const std::size_t buffer_size_;
>     const std::string original_name_;
>=20
> public:
>     explicit point_cloud(point_cloud_reader&);
>     ~point_cloud();
>=20
>     ...
> };
>=20
> Here the buffer is allocated only once on construction, and all of its va=
riables cannot be changed afterwards. However it is still possible to chang=
e the contents of the buffer. Imposing such restrictions on a class can oft=
en simplify coding, since you don't have to define semantics for assignment=
, or handling side effects of changing properties of an object that are als=
o defined at construction.
>=20
> For example a class representing a camera in 3D space might contain both =
a projection matrix and its inverse. It would have to be recalculated each =
time the camera's parameters are changed. But it would also have been possi=
ble to just create a new camera instance with new parameters. So the class =
could be left immutable, avoiding overcomplicating the code without much ga=
in in functionality.
>=20
> The only problem is that immutable objects cannot implement an assignment=
 operator=3D, since this is meant to change the object, and not create a ne=
w one in-place. To reuse the same variable, a possible workaround currently=
 is to use call destructor and then use placement new:
>=20
> immutable obj(1, 2);
> obj.f();
> //obj =3D immutable(2, 3);   not possible, instead:
> obj.~ immutable();
> new(&obj) immutable(2, 3);
> obj.f();
>=20
> Eigen actually recommends this for its Map class: http://eigen.tuxfamily.=
org/dox/group__TutorialMapClass.html.
>=20
> My idea would be to introduce reinitialization of objects as a language f=
eature or into the STL library. std::optional currently expect the object t=
o be assignable if an engaged optional is reassigned a new value. If it is =
not engaged however, it constructs a new object as above. Maybe introduce a=
 class:
>=20
> std::reusable<immutable> obj(1, 2);
> obj->f();
> obj.replace(1, 2);
> obj->f();
>=20
> Or maybe an alternative operator to the assignment operator that destruct=
s the object and creates a new one in-place.
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 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-propo=
sals/.

--=20

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

--Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>I would worry that references to t=
he supposedly immutable object would be logically invalidated.<br><br><br><=
/div><div><br>On 15 Dec 2014, at 19:50, tl &lt;<a href=3D"mailto:timlenertz=
@gmail.com">timlenertz@gmail.com</a>&gt; wrote:<br><br></div><blockquote ty=
pe=3D"cite"><div><div dir=3D"ltr">You sometimes want to have classes with v=
ariables that cannot be changed after the object has been created. For exam=
ple:<div><br></div><div><font face=3D"courier new, monospace">class point_c=
loud {</font></div><div><font face=3D"courier new, monospace">private:</fon=
t></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; point* con=
st buffer_;</font></div><div><font face=3D"courier new, monospace">&nbsp; &=
nbsp; const std::size_t buffer_size_;</font></div><div><font face=3D"courie=
r new, monospace">&nbsp; &nbsp; const std::string original_name_;</font></d=
iv><div><font face=3D"courier new, monospace"><br></font></div><div><font f=
ace=3D"courier new, monospace">public:</font></div><div><font face=3D"couri=
er new, monospace">&nbsp; &nbsp; explicit point_cloud(point_cloud_reader&am=
p;);</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; ~=
point_cloud();</font></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; ...</f=
ont></div><div><font face=3D"courier new, monospace">};</font></div><div><b=
r></div><div>Here the buffer is allocated only once on construction, and al=
l of its variables cannot be changed afterwards. However it is still possib=
le to change the contents of the buffer. Imposing such restrictions on a cl=
ass can often simplify coding, since you don't have to define semantics for=
 assignment, or handling side effects of changing properties of an object t=
hat are also defined at construction.</div><div><br></div><div>For example =
a class representing a camera in 3D space might contain both a projection m=
atrix and its inverse. It would have to be recalculated each time the camer=
a's parameters are changed. But it would also have been possible to just cr=
eate a new camera instance with new parameters. So the class could be left =
immutable, avoiding overcomplicating the code without much gain in function=
ality.</div><div><br></div><div>The only problem is that immutable objects =
cannot implement an assignment operator=3D, since this is meant to change t=
he object, and not create a new one in-place. To reuse the same variable, a=
 possible workaround currently is to use call destructor and then use place=
ment new:</div><div><br></div><div><font face=3D"courier new, monospace">im=
mutable obj(1, 2);</font></div><div><font face=3D"courier new, monospace">o=
bj.f();</font></div><div><font face=3D"courier new, monospace">//obj =3D im=
mutable(2, 3); &nbsp; not possible, instead:</font></div><div><font face=3D=
"courier new, monospace">obj.~ immutable();</font></div><div><font face=3D"=
courier new, monospace">new(&amp;obj) immutable(2, 3);</font></div><div><fo=
nt face=3D"courier new, monospace">obj.f();</font></div><div><br></div><div=
>Eigen actually recommends this for its Map class: <a href=3D"http://eigen.=
tuxfamily.org/dox/group__TutorialMapClass.html">http://eigen.tuxfamily.org/=
dox/group__TutorialMapClass.html</a>.</div><div><br></div><div>My idea woul=
d be to introduce reinitialization of objects as a language feature or into=
 the STL library. <a href=3D"http://en.cppreference.com/w/cpp/experimental/=
optional">std::optional</a> currently expect the object to be assignable if=
 an engaged optional is reassigned a new value. If it is not engaged howeve=
r, it constructs a new object as above. Maybe introduce a class:</div><div>=
<br></div><div><font face=3D"courier new, monospace">std::reusable&lt;immut=
able&gt; obj(1, 2);</font></div><div><font face=3D"courier new, monospace">=
obj-&gt;f();</font></div><div><font face=3D"courier new, monospace">obj.rep=
lace(1, 2);</font></div><div><font face=3D"courier new, monospace">obj-&gt;=
f();</font></div><div><font face=3D"courier new, monospace"><br></font></di=
v><div>Or maybe an alternative operator to the assignment operator that des=
tructs the object and creates a new one in-place.<font face=3D"courier new,=
 monospace"><br></font></div></div>

<p></p>

-- <br>
<br>
--- <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>
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>
</div></blockquote></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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 />
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 />

--Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170--

.

--001a11c33fcc12090c050a48579c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> On 15 Dec 2014, at 19:50, tl <timlenertz@gmail.com> wrote:
>
> The only problem is that immutable objects cannot implement an assignment
> operator=3D, since this is meant to change the object, and not create a n=
ew
> one in-place. To reuse the same variable, a possible workaround currently
> is to use call destructor and then use placement new:
>
> immutable obj(1, 2);
> obj.f();
> //obj =3D immutable(2, 3);   not possible, instead:
> obj.~ immutable();
> new(&obj) immutable(2, 3);
> obj.f();
>
> Isn't it undefined behaviour to overwrite a const object? The Standard
says,

*Creating a new object at the storage location that a const object with
static, thread, or automatic storage duration occupies or, at the storage
location that such a const object used to occupy before its lifetime ended
results in undefined behavior.*

(=C2=A73.8/9 in C++11, same in N3936)

--=20
*Brian Bi*

--=20

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

--001a11c33fcc12090c050a48579c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"auto"><div class=3D"h5"><div>On 15 Dec 2014, at 19=
:50, tl &lt;<a href=3D"mailto:timlenertz@gmail.com" target=3D"_blank">timle=
nertz@gmail.com</a>&gt; wrote:<br></div><blockquote type=3D"cite"><div dir=
=3D"ltr"><div>The only problem is that immutable objects cannot implement a=
n assignment operator=3D, since this is meant to change the object, and not=
 create a new one in-place. To reuse the same variable, a possible workarou=
nd currently is to use call destructor and then use placement new:<br></div=
><div><br></div><div><font face=3D"courier new, monospace">immutable obj(1,=
 2);</font></div><div><font face=3D"courier new, monospace">obj.f();</font>=
</div><div><font face=3D"courier new, monospace">//obj =3D immutable(2, 3);=
 =C2=A0 not possible, instead:</font></div><div><font face=3D"courier new, =
monospace">obj.~ immutable();</font></div><div><font face=3D"courier new, m=
onospace">new(&amp;obj) immutable(2, 3);</font></div><div><font face=3D"cou=
rier new, monospace">obj.f();</font></div></div></blockquote></div></div></=
blockquote><div><div>Isn&#39;t it undefined behaviour to overwrite a const =
object? The Standard says,</div><div><br></div><div><i>Creating a new objec=
t at the storage location that a const object with static, thread, or autom=
atic storage duration occupies or, at the storage location that such a cons=
t object used to occupy before its lifetime ended results in undefined beha=
vior.</i></div><div><br></div><div>(=C2=A73.8/9 in C++11, same in N3936)<br=
></div><div class=3D"gmail_extra"><br></div></div></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"=
#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div><=
/div></div></div>
</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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 />
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 />

--001a11c33fcc12090c050a48579c--

.

------=_Part_918_1062416459.1418693987764
Content-Type: multipart/alternative;
 boundary="----=_Part_919_1854385255.1418693987764"

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

I'm not sure if this applies to const members of a non-const object.

A container like std::reusable would artificially end the lifetime of its=
=20
containing object and create a new one in its place. This would invalidate=
=20
references and pointers to the contained object (or technically make them=
=20
point to the new object), but not references or pointer to the=20
std::reusable.

The same can already be done using std::vector, by erasing one item and=20
inserting a new one. Or with std::optional, by engaging a new object. The=
=20
idea was to be able to put a non-assignable/immutable object into a spot=20
that is accessible from a variable know beforehand. Another way would be to=
=20
allocate it in the heap and then store its address into an existing pointer=
=20
variable.

It seems that std::optional provides exactly this functionality=20
(std::optional::emplace destructs the old object and creates a new one in=
=20
its place, without using the assignment operator). But here the purpose is=
=20
different (i.e. having a variable that may or may not hold a value, but the=
=20
class is still supposed to be assignable, for example by=20
std::optional::operator=3D). std::reusable would be a container that can ho=
ld=20
different objects during its lifetime and does not require them to be=20
assignable.

Maybe this would be considered a hack since it goes too much against the=20
C++ object model. But making all classes mutable can lead to a lot of code=
=20
duplication in practice (same functionality in constructor and assignment=
=20
operator), when it would be just as efficient to destroy the object and=20
create a new one. E.g. in Java the =3D operator actually does that, but the=
re=20
all objects are on the heap and garbage collected.

Being able to artificially end the lifetime of an object before the block=
=20
ends (for automatic storage) may also be useful for example it that object=
=20
was used for move constructing/assigning another object, and is now invalid=
=20
/ must not be reused anyways (though this would be a use case for=20
std::optional):

object obj;
obj.f();
object obj2( std::move(obj) );
// obj must not be used again from here



On Monday, December 15, 2014 10:58:21 PM UTC+1, Brian Bi wrote:
>
> On 15 Dec 2014, at 19:50, tl <timle...@gmail.com <javascript:>> wrote:
>>
>> The only problem is that immutable objects cannot implement an assignmen=
t=20
>> operator=3D, since this is meant to change the object, and not create a =
new=20
>> one in-place. To reuse the same variable, a possible workaround currentl=
y=20
>> is to use call destructor and then use placement new:
>>
>> immutable obj(1, 2);
>> obj.f();
>> //obj =3D immutable(2, 3);   not possible, instead:
>> obj.~ immutable();
>> new(&obj) immutable(2, 3);
>> obj.f();
>>
>> Isn't it undefined behaviour to overwrite a const object? The Standard=
=20
> says,
>
> *Creating a new object at the storage location that a const object with=
=20
> static, thread, or automatic storage duration occupies or, at the storage=
=20
> location that such a const object used to occupy before its lifetime ende=
d=20
> results in undefined behavior.*
>
> (=C2=A73.8/9 in C++11, same in N3936)
>
> --=20
> *Brian Bi*
> =20

--=20

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

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

<div dir=3D"ltr"><div>I'm not sure if this applies to const members of a no=
n-const object.</div><div><br></div><div>A container like std::reusable wou=
ld artificially end the lifetime of its containing object and create a new =
one in its place. This would invalidate references and pointers to the cont=
ained object (or technically make them point to the new object), but not re=
ferences or pointer to the std::reusable.</div><div><br></div><div>The same=
 can already be done using std::vector, by erasing one item and inserting a=
 new one. Or with std::optional, by engaging a new object. The idea was to =
be able to put a non-assignable/immutable object into a spot that is access=
ible from a variable know beforehand. Another way would be to allocate it i=
n the heap and then store its address into an existing pointer variable.</d=
iv><div><br></div><div>It seems that std::optional provides exactly this fu=
nctionality (std::optional::emplace destructs the old object and creates a =
new one in its place, without using the assignment operator). But here the =
purpose is different (i.e. having a variable that may or may not hold a val=
ue, but the class is still supposed to be assignable, for example by std::o=
ptional::operator=3D). std::reusable would be a container that can hold dif=
ferent objects during its lifetime and does not require them to be assignab=
le.</div><div><br></div><div>Maybe this would be considered a hack since it=
 goes too much against the C++ object model. But making all classes mutable=
 can lead to a lot of code duplication in practice (same functionality in c=
onstructor and assignment operator), when it would be just as efficient to =
destroy the object and create a new one. E.g. in Java the =3D operator actu=
ally does that, but there all objects are on the heap and garbage collected=
..</div><div><br></div><div><div>Being able to artificially end the lifetime=
 of an object before the block ends (for automatic storage) may also be use=
ful for example it that object was used for move constructing/assigning ano=
ther object, and is now invalid / must not be reused anyways (though this w=
ould be a use case for std::optional):</div><div><br></div><div>object obj;=
</div><div>obj.f();</div><div>object obj2( std::move(obj) );</div><div>// o=
bj must not be used again from here</div></div><div><br></div><div><br></di=
v><br>On Monday, December 15, 2014 10:58:21 PM UTC+1, Brian Bi wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"auto"><div><div>On 15 Dec 2014, a=
t 19:50, tl &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"WUOctuR9gHcJ" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">timle...@gmail.com</a>=
&gt; wrote:<br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div>The on=
ly problem is that immutable objects cannot implement an assignment operato=
r=3D, since this is meant to change the object, and not create a new one in=
-place. To reuse the same variable, a possible workaround currently is to u=
se call destructor and then use placement new:<br></div><div><br></div><div=
><font face=3D"courier new, monospace">immutable obj(1, 2);</font></div><di=
v><font face=3D"courier new, monospace">obj.f();</font></div><div><font fac=
e=3D"courier new, monospace">//obj =3D immutable(2, 3); &nbsp; not possible=
, instead:</font></div><div><font face=3D"courier new, monospace">obj.~ imm=
utable();</font></div><div><font face=3D"courier new, monospace">new(&amp;o=
bj) immutable(2, 3);</font></div><div><font face=3D"courier new, monospace"=
>obj.f();</font></div></div></blockquote></div></div></blockquote><div><div=
>Isn't it undefined behaviour to overwrite a const object? The Standard say=
s,</div><div><br></div><div><i>Creating a new object at the storage locatio=
n that a const object with static, thread, or automatic storage duration oc=
cupies or, at the storage location that such a const object used to occupy =
before its lifetime ended results in undefined behavior.</i></div><div><br>=
</div><div>(=C2=A73.8/9 in C++11, same in N3936)<br></div><div><br></div></=
div></div>-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D=
"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div>=
</div></div></div>
</div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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 />
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_919_1854385255.1418693987764--
------=_Part_918_1062416459.1418693987764--

.