On 2015-07-23 20:08, denis bider wrote:
> The language introduced noexcept to deal with a similar property for
> methods. How about introducing a class-level property to indicate
> memcpy-ability for classes?
>
> We could call the property "movable", and the keyword could appear
> contextually after class name:
>
> class A movable {};
> class B movable : public A {};

I'd consider calling it "relocatable" to avoid ambiguity with "move" as
it refers to move ctors, rvalue-refs, etc. And possibly make it an
attribute. I think it would be okay to make it an attribute since it
should not change the observable operation of a program (no more than
copy elision, anyway).

Also I'd prefer if the standard permits the compiler to infer a
relocatable type (for example, a non-pointer POD is relocatable; a class
whose members are all relocatable is itself relocatable; naturally, a
class that is trivially copyable/movable is relocatable), without
specifying how such inference is made. This way the onus is on compiler
vendors rather than the standard to make types implicitly relocatable
without false positives or to choose to be conservative and never mark
types implicitly relocatable.

(I'm going to disagree somewhat with Thiago on how compilers should
handle an attribute for this. I would rather that compilers are required
to implement a certain minimal support, which would include diagnostics
when a type annotated as relocatable in fact is not, as well as
supporting type traits, or else the attribute shall have no effect at
all, including that it cannot be queried.)

--
Matthew

--

---
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_1089_656694248.1438208326862
Content-Type: multipart/alternative;
 boundary="----=_Part_1090_2073623946.1438208326863"

------=_Part_1090_2073623946.1438208326863
Content-Type: text/plain; charset=UTF-8

Indeed - I believe there's some consensus on calling the property
"relocatable".

Of course, I would much much prefer having support for this property, than
not having it.

However, assuming there's support for this property:

* I would *much* prefer in-line syntax, i.e. class X relocatable; instead
of generalized attribute syntax, i.e. class [[ relocatable ]] X.

The attribute syntax is *ugly*. I can see the need for this compromise if
the language wants to support a variety of user-defined and
compiler-defined attribute types. It's better than no standardization.

However, for official properties defined by the standard, this syntax is an
abomination. *Please* don't make C++ look like assembly.

* I would *much* prefer standard rules for relocatable property inference,
than compiler-defined rules.

Compiler-defined rules mean I can't rely on anything being relocatable,
unless I declare it. If I get into the habit of declaring everything
as relocatable, I'll be creating bugs when I don't notice that an object
has a sub-object that is not. A non-relocatable sub-object can furthermore
be added later, either as a directed member or base, or as an inherited
member or base.

I believe it's much preferable that we have standard rules to determine how
the relocatable property is inferred. I don't think these rules need to be
very complex.

I would much rather be able to rely on this:

class X : public BelievedRelocatableBase {
private:
    BelievedRelocatableMember m_x;
};

static_assert(std::is_relocatable<X>::value, "");

.... than on this:

class [[ relocatable ]] X : public BelievedRelocatableBase {
private:
    BelievedRelocatableMember m_x;
};

The former is a cautious construction which produces an error if
BelievedRelocatableBase or BelievedRelocatableMember are in fact not.

The latter is a sledgehammer which produces bugs if one of these same
assumptions is incorrect.

I would very much like this property, but I would like the language to
allow me to reliably use the cautious construction that will detect errors,
instead of forcing use of the sledgehammer that will not.

After all, the reason we have a statically typed language is because this
helps us to work with the compiler to detect errors.


On Wednesday, July 29, 2015 at 8:48:33 AM UTC-6, Matthew Woehlke wrote:

> On 2015-07-23 20:08, denis bider wrote:
> > The language introduced noexcept to deal with a similar property for
> > methods. How about introducing a class-level property to indicate
> > memcpy-ability for classes?
> >
> > We could call the property "movable", and the keyword could appear
> > contextually after class name:
> >
> > class A movable {};
> > class B movable : public A {};
>
> I'd consider calling it "relocatable" to avoid ambiguity with "move" as
> it refers to move ctors, rvalue-refs, etc. And possibly make it an
> attribute. I think it would be okay to make it an attribute since it
> should not change the observable operation of a program (no more than
> copy elision, anyway).
>
> Also I'd prefer if the standard permits the compiler to infer a
> relocatable type (for example, a non-pointer POD is relocatable; a class
> whose members are all relocatable is itself relocatable; naturally, a
> class that is trivially copyable/movable is relocatable), without
> specifying how such inference is made. This way the onus is on compiler
> vendors rather than the standard to make types implicitly relocatable
> without false positives or to choose to be conservative and never mark
> types implicitly relocatable.
>
> (I'm going to disagree somewhat with Thiago on how compilers should
> handle an attribute for this. I would rather that compilers are required
> to implement a certain minimal support, which would include diagnostics
> when a type annotated as relocatable in fact is not, as well as
> supporting type traits, or else the attribute shall have no effect at
> all, including that it cannot be queried.)
>
> --
> Matthew
>
>

--

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

<div dir=3D"ltr"><div>Indeed -=C2=A0I believe there&#39;s some consensus on=
 calling the property &quot;relocatable&quot;.</div><div><br></div><div>Of =
course, I would much much prefer having support for this property, than not=
 having it.</div><div><br></div><div>However, assuming there&#39;s support =
for this property:</div><div><br></div><div>*=C2=A0I would <strong>much</st=
rong> prefer in-line syntax, i.e. <font face=3D"courier new,monospace">clas=
s X relocatable</font>; instead of generalized attribute syntax, i.e. <font=
 face=3D"courier new,monospace">class [[ relocatable ]] X</font>.<br></div>=
<div><br></div><div>The attribute syntax is <strong>ugly</strong>. I can se=
e the need for this compromise if the language wants to support a variety o=
f user-defined and compiler-defined attribute types.=C2=A0It&#39;s better t=
han no standardization.</div><div><br></div><div>However, for official prop=
erties defined by the standard, this syntax is an abomination. <em>Please</=
em> don&#39;t make C++ look like assembly.</div><div><br></div><div>*=C2=A0=
I would <strong>much</strong> prefer standard rules for relocatable propert=
y inference, than compiler-defined rules.</div><div><br></div><div>Compiler=
-defined rules mean I can&#39;t rely on anything being relocatable, unless =
I declare it. If I=C2=A0get into the habit of=C2=A0declaring=C2=A0everythin=
g as=C2=A0relocatable, I&#39;ll be creating bugs when I don&#39;t notice th=
at an object has a sub-object that is not. A non-relocatable sub-object can=
 furthermore be added later, either as a directed member or base, or as an =
inherited member or base.</div><div><br></div><div>I believe it&#39;s much =
preferable that we have standard rules to determine how the relocatable pro=
perty is inferred. I don&#39;t think these rules need to be very complex.</=
div><div><br></div><div>I would much rather be able to rely on this:</div><=
div><br></div><div><font face=3D"courier new,monospace">class X : public=C2=
=A0BelievedRelocatableBase {</font></div><div><font face=3D"courier new,mon=
ospace">private:</font></div><div><font face=3D"courier new,monospace">=C2=
=A0=C2=A0=C2=A0 BelievedRelocatableMember m_x;</font></div><div><font face=
=3D"courier new,monospace">};</font></div><div><font face=3D"courier new,mo=
nospace"><br></font></div><div><font face=3D"courier new,monospace">static_=
assert(std::is_relocatable&lt;X&gt;::value, &quot;&quot;);</font></div><div=
><br></div><div>... than on this:</div><div><br></div><div><div><font face=
=3D"courier new,monospace">class [[ relocatable ]]=C2=A0X : public=C2=A0Bel=
ievedRelocatableBase {</font></div><div><font face=3D"courier new,monospace=
">private:</font></div><div><font face=3D"courier new,monospace">=C2=A0=C2=
=A0=C2=A0 BelievedRelocatableMember m_x;</font></div><div><font face=3D"cou=
rier new,monospace">};</font></div></div><div><br></div><div>The former is =
a cautious construction which produces an error if <font face=3D"courier ne=
w,monospace">BelievedRelocatableBase</font> or <font face=3D"courier new,mo=
nospace">BelievedRelocatableMember</font> are in fact not.</div><div><br></=
div><div>The latter is a sledgehammer which produces bugs if one of these s=
ame assumptions is incorrect.</div><div><br></div><div>I would very much li=
ke this property, but I would like the language to allow me to reliably use=
 the cautious construction that will detect errors, instead of forcing use =
of the sledgehammer that will not.</div><div><br></div><div>After all, the =
reason we have a statically typed language is <font face=3D"courier new,mon=
ospace">because</font> this helps us to work with the compiler to detect er=
rors.</div><div><br></div><div><br>On Wednesday, July 29, 2015 at 8:48:33 A=
M UTC-6, Matthew Woehlke wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;">On 2015-0=
7-23 20:08, denis bider wrote:
<br>&gt; The language introduced noexcept to deal with a similar property f=
or=20
<br>&gt; methods. How about introducing a class-level property to indicate=
=20
<br>&gt; memcpy-ability for classes?
<br>&gt;=20
<br>&gt; We could call the property &quot;movable&quot;, and the keyword co=
uld appear=20
<br>&gt; contextually after class name:
<br>&gt;=20
<br>&gt; class A movable {};
<br>&gt; class B movable : public A {};
<br>
<br>I&#39;d consider calling it &quot;relocatable&quot; to avoid ambiguity =
with &quot;move&quot; as
<br>it refers to move ctors, rvalue-refs, etc. And possibly make it an
<br>attribute. I think it would be okay to make it an attribute since it
<br>should not change the observable operation of a program (no more than
<br>copy elision, anyway).
<br>
<br>Also I&#39;d prefer if the standard permits the compiler to infer a
<br>relocatable type (for example, a non-pointer POD is relocatable; a clas=
s
<br>whose members are all relocatable is itself relocatable; naturally, a
<br>class that is trivially copyable/movable is relocatable), without
<br>specifying how such inference is made. This way the onus is on compiler
<br>vendors rather than the standard to make types implicitly relocatable
<br>without false positives or to choose to be conservative and never mark
<br>types implicitly relocatable.
<br>
<br>(I&#39;m going to disagree somewhat with Thiago on how compilers should
<br>handle an attribute for this. I would rather that compilers are require=
d
<br>to implement a certain minimal support, which would include diagnostics
<br>when a type annotated as relocatable in fact is not, as well as
<br>supporting type traits, or else the attribute shall have no effect at
<br>all, including that it cannot be queried.)
<br>
<br>--=20
<br>Matthew
<br>
<br></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_1090_2073623946.1438208326863--
------=_Part_1089_656694248.1438208326862--

.

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

On Wed, Jul 29, 2015 at 3:18 PM, denis bider <isocppgroup@denisbider.com>
wrote:

> Indeed - I believe there's some consensus on calling the property
> "relocatable".
>
> Of course, I would much much prefer having support for this property, tha=
n
> not having it.
>
> However, assuming there's support for this property:
>
[...]

> I believe it's much preferable that we have standard rules to determine
> how the relocatable property is inferred. I don't think these rules need =
to
> be very complex.
>
> I would much rather be able to rely on this:
>
> class X : public BelievedRelocatableBase {
> private:
>     BelievedRelocatableMember m_x;
> };
>
> static_assert(std::is_relocatable<X>::value, "");
>
> ... than on this:
>
> class [[ relocatable ]] X : public BelievedRelocatableBase {
> private:
>     BelievedRelocatableMember m_x;
> };
>
> The former is a cautious construction which produces an error if
> BelievedRelocatableBase or BelievedRelocatableMember are in fact not.
>
> The latter is a sledgehammer which produces bugs if one of these same
> assumptions is incorrect.
>

Correct; this is exactly what type-traits are for.
However, I believe that if someone WANTS a sledgehammer, type-traits also
provide a sledgehammer:

namespace std {
  template<> struct is_relocatable<BelievedRelocatableBase> :
std::true_type {};
}

The above is legal (and relatively idiomatic) code that "sledgehammers" the
implementation into treating BelievedRelocatableBase as relocatable, for
all library purposes (vector::resize being the most obvious one).

That is, type-traits can be used in the "safe" manner you want; but they
can ALSO be used in the above "unsafe" manner, for people who prefer (or
require) that approach. This is the genius part of type-traits, IMO.

The default library implementation of is_relocatable can be as simple as

namespace std {
  struct relocatable {};
  template<class T> struct is_relocatable : std::bool_constant<
      (is_trivially_move_constructible_v<T> &&
is_trivially_destructible_v<T>) || is_base_of_v<relocatable, T>
  > {};
}

// Sample usage:
class SledgehammerRelocatableBase : std::relocatable { ... };

=E2=80=93Arthur

P.S.: I still prefer the spelling is_trivially_relocatable, because
obviously almost *any* type is relocatable by *some* (possibly non-trivial)
means.

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

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

<div dir=3D"ltr">On Wed, Jul 29, 2015 at 3:18 PM, denis bider <span dir=3D"=
ltr">&lt;<a href=3D"mailto:isocppgroup@denisbider.com" target=3D"_blank">is=
ocppgroup@denisbider.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>Indeed -=C2=A0I believe there&#39;s some consensus on calling the pr=
operty &quot;relocatable&quot;.</div><div><br></div><div>Of course, I would=
 much much prefer having support for this property, than not having it.</di=
v><div><br></div><div>However, assuming there&#39;s support for this proper=
ty:</div></div></blockquote><div>[...]</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div>I believe it&#39;s much preferable that we have stand=
ard rules to determine how the relocatable property is inferred. I don&#39;=
t think these rules need to be very complex.<br></div><div><br></div><div>I=
 would much rather be able to rely on this:</div><div><br></div><div><font =
face=3D"courier new,monospace">class X : public=C2=A0BelievedRelocatableBas=
e {</font></div><div><font face=3D"courier new,monospace">private:</font></=
div><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0 BelievedRe=
locatableMember m_x;</font></div><div><font face=3D"courier new,monospace">=
};</font></div><div><font face=3D"courier new,monospace"><br></font></div><=
div><font face=3D"courier new,monospace">static_assert(std::is_relocatable&=
lt;X&gt;::value, &quot;&quot;);</font></div><div><br></div><div>... than on=
 this:</div><div><br></div><div><div><font face=3D"courier new,monospace">c=
lass [[ relocatable ]]=C2=A0X : public=C2=A0BelievedRelocatableBase {</font=
></div><div><font face=3D"courier new,monospace">private:</font></div><div>=
<font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0 BelievedRelocatable=
Member m_x;</font></div><div><font face=3D"courier new,monospace">};</font>=
</div></div><div><br></div><div>The former is a cautious construction which=
 produces an error if <font face=3D"courier new,monospace">BelievedRelocata=
bleBase</font> or <font face=3D"courier new,monospace">BelievedRelocatableM=
ember</font> are in fact not.</div><div><br></div><div>The latter is a sled=
gehammer which produces bugs if one of these same assumptions is incorrect.=
</div></div></blockquote><div><br></div><div>Correct; this is exactly what =
type-traits are for.</div><div>However, I believe that if someone WANTS a s=
ledgehammer, type-traits also provide a sledgehammer:</div><div><br></div><=
div><font face=3D"monospace, monospace">namespace std {</font></div><div><f=
ont face=3D"monospace, monospace">=C2=A0 template&lt;&gt; struct is_relocat=
able&lt;BelievedRelocatableBase&gt; : std::true_type {};</font></div><div><=
font face=3D"monospace, monospace">}</font></div><div><br></div><div>The ab=
ove is legal (and relatively idiomatic) code that &quot;sledgehammers&quot;=
 the implementation into treating BelievedRelocatableBase as relocatable, f=
or all library purposes (vector::resize being the most obvious one).</div><=
div><br></div><div>That is, type-traits can be used in the &quot;safe&quot;=
 manner you want; but they can ALSO be used in the above &quot;unsafe&quot;=
 manner, for people who prefer (or require) that approach. This is the geni=
us part of type-traits, IMO.</div><div><br></div><div>The default library i=
mplementation of is_relocatable can be as simple as</div><div><br></div><di=
v><font face=3D"monospace, monospace">namespace std {</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 struct relocatable {};</font></div><=
div><font face=3D"monospace, monospace">=C2=A0 template&lt;class T&gt; stru=
ct is_relocatable : std::bool_constant&lt;</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 =C2=A0 (is_trivially_move_constructible_=
v&lt;T&gt; &amp;&amp; is_trivially_destructible_v&lt;T&gt;) || is_base_of_v=
&lt;relocatable, T&gt;</font></div><div><font face=3D"monospace, monospace"=
>=C2=A0 &gt; {};</font></div><div><font face=3D"monospace, monospace">}</fo=
nt></div><div><font face=3D"monospace, monospace"><br></font></div><div><fo=
nt face=3D"monospace, monospace">// Sample usage:</font></div><div><font fa=
ce=3D"monospace, monospace">class SledgehammerRelocatableBase : std::reloca=
table { ... };</font></div><div><br></div><div>=E2=80=93Arthur</div><div><b=
r></div><div>P.S.: I still prefer the spelling <font face=3D"monospace, mon=
ospace">is_trivially_relocatable</font>, because obviously almost <i>any</i=
> type is relocatable by <i>some</i> (possibly non-trivial) means.</div></d=
iv></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 />

--001a11c26a6af5c406051c0cf2ab--

.

On 7/29/2015 9:40 PM, Arthur O'Dwyer wrote:
> However, I believe that if someone WANTS a sledgehammer, type-traits
> also provide a sledgehammer:
>
> namespace std {
>    template<> struct is_relocatable<BelievedRelocatableBase> :
> std::true_type {};
> }
>
> The above is legal (and relatively idiomatic) code that "sledgehammers"
> the implementation into treating BelievedRelocatableBase as relocatable,
> for all library purposes (vector::resize being the most obvious one).

This is only legal if whomever defines the trait says that it is.

As far as the standard cares, for its own type traits:

20.10.2 [meta.type.synop]/1 The behavior of a program that adds=20
specializations for any of the class templates defined in this subclause=20
is undefined unless otherwise specified.

I'm only aware of `common_type` specializations being allowed (otherwise=20
specified), there might be others.

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

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

.

On 2015-07-29 18:18, denis bider wrote:
> * I would *much* prefer standard rules for relocatable property inference,
> than compiler-defined rules.

I'll claim an amount of pragmatism here; leaving it to the vendors
allows us to figure out over time what inferences are safe (and imposes
less penalty - at least in terms of strict standards conformance - on
vendors that are slow on the uptake) rather than needing to get it right
up front (and follow up with DR's when it isn't), in effect growing
organically into "the right way". A bottom up approach as opposed to a
top down approach.

That said, it's not a philosophical stance. I have no philosophical
objection to standardizing the rules from the get-go; I just think from
a practical perspective that may be much harder. If you can overcome the
practical difficulties, then go for it :-).

> Compiler-defined rules mean I can't rely on anything being relocatable,
> unless I declare it. If I get into the habit of declaring everything
> as relocatable, I'll be creating bugs when I don't notice that an object
> has a sub-object that is not.

No, because as you previously indicated (and with which I clearly stated
agreement), the compiler should diagnose entities labeled relocatable
that in fact are not. In that sense, this may be better, because you'll
*know* that an entity is relocatable or not, because if you are in the
habit of marking everything relocatable, the absence of such mark is
meaningful.

If you rely on implicit marking, you have to actually test.

> I would much rather be able to rely on this:
>
> class X : public BelievedRelocatableBase {
> private:
>     BelievedRelocatableMember m_x;
> };
>
> static_assert(std::is_relocatable<X>::value, "");
>
> ... than on this:
>
> class [[ relocatable ]] X : public BelievedRelocatableBase {
> private:
>     BelievedRelocatableMember m_x;
> };

Per above, the label is equivalent to the static assertion. (Nearly; a
compiler that simply does not support the attribute will ignore it
entirely. Note however that the static assertion would also fail for
such a compiler, which is a potential point in favor of the latter.)

The "sledgehammer" comes into play when you mark a pointer member as
relocatable. You'll need that ability in either case, to override the
usual compiler determination that a pointer means that its containing
entity is not relocatable.

--
Matthew

--

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

.

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

Let me backtrack to a previous statement: compilers don't have enough
information to infer whether a type is relocatable or not, and the decision
should not be left to the compiler.

The cases mentioned: non-pointer POD, a class whose members are all
relocatable=E2=80=A6 In the case of a POD, it is already bitwise-movable wh=
ich is a
stronger constrain than relocatable.  We don't need to work on PODs, we can
already do it with those.

On the other hand, a class whose members are relocatable need not be
relocatable itself.  For example, std::list<T*> would be relocatable, but
an object could hold a T member and a std::list<T*> including one pointer
to the member making the type self-referencing and thus not-relocatable.

On the suggestion of using a sledgehammer and marking by default types as
relocatable, that is too dangerous. When the type is relocatable, and the
trait informs us we have an optimization advantage, but if the type is not
relocatable and the traits claims it we break the program.

Reviewing the destructive move proposals by Pablo Halpern I found that N415=
8
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf> already
covers what is being discussed here in the form of a trait and additionally
provides mechanisms to make use of the trait. Additionally N4393
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf> propose=
s
the creation of a mechanism to handle the coming into existence (starting
the lifetime) of objects, which is from the point of view of the core
language the sticky point of what is being discussed.

   David

On Thu, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-07-29 18:18, denis bider wrote:
> > * I would *much* prefer standard rules for relocatable property
> inference,
> > than compiler-defined rules.
>
> I'll claim an amount of pragmatism here; leaving it to the vendors
> allows us to figure out over time what inferences are safe (and imposes
> less penalty - at least in terms of strict standards conformance - on
> vendors that are slow on the uptake) rather than needing to get it right
> up front (and follow up with DR's when it isn't), in effect growing
> organically into "the right way". A bottom up approach as opposed to a
> top down approach.
>
> That said, it's not a philosophical stance. I have no philosophical
> objection to standardizing the rules from the get-go; I just think from
> a practical perspective that may be much harder. If you can overcome the
> practical difficulties, then go for it :-).
>
> > Compiler-defined rules mean I can't rely on anything being relocatable,
> > unless I declare it. If I get into the habit of declaring everything
> > as relocatable, I'll be creating bugs when I don't notice that an objec=
t
> > has a sub-object that is not.
>
> No, because as you previously indicated (and with which I clearly stated
> agreement), the compiler should diagnose entities labeled relocatable
> that in fact are not. In that sense, this may be better, because you'll
> *know* that an entity is relocatable or not, because if you are in the
> habit of marking everything relocatable, the absence of such mark is
> meaningful.
>
> If you rely on implicit marking, you have to actually test.
>
> > I would much rather be able to rely on this:
> >
> > class X : public BelievedRelocatableBase {
> > private:
> >     BelievedRelocatableMember m_x;
> > };
> >
> > static_assert(std::is_relocatable<X>::value, "");
> >
> > ... than on this:
> >
> > class [[ relocatable ]] X : public BelievedRelocatableBase {
> > private:
> >     BelievedRelocatableMember m_x;
> > };
>
> Per above, the label is equivalent to the static assertion. (Nearly; a
> compiler that simply does not support the attribute will ignore it
> entirely. Note however that the static assertion would also fail for
> such a compiler, which is a potential point in favor of the latter.)
>
> The "sledgehammer" comes into play when you mark a pointer member as
> relocatable. You'll need that ability in either case, to override the
> usual compiler determination that a pointer means that its containing
> entity is not relocatable.
>
> --
> Matthew
>
> --
>
> ---
> 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/.
>

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

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

<div dir=3D"ltr">Let me backtrack to a previous statement: compilers don&#3=
9;t have enough information to infer whether a type is relocatable or not, =
and the decision should not be left to the compiler.<div><br></div><div>The=
 cases mentioned: non-pointer POD, a class whose members are all relocatabl=
e=E2=80=A6 In the case of a POD, it is already bitwise-movable which is a s=
tronger constrain than relocatable.=C2=A0 We don&#39;t need to work on PODs=
, we can already do it with those.=C2=A0</div><div><br></div><div>On the ot=
her hand, a class whose members are relocatable need not be relocatable its=
elf.=C2=A0 For example, std::list&lt;T*&gt; would be relocatable, but an ob=
ject could hold a T member and a std::list&lt;T*&gt; including one pointer =
to the member making the type self-referencing and thus not-relocatable.</d=
iv><div><br></div><div>On the suggestion of using a sledgehammer and markin=
g by default types as relocatable, that is too dangerous. When the type is =
relocatable, and the trait informs us we have an optimization advantage, bu=
t if the type is not relocatable and the traits claims it we break the prog=
ram.</div><div><br></div><div>Reviewing the destructive move proposals by P=
ablo Halpern I found that=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2014/n4158.pdf">N4158</a>=C2=A0already covers what is bei=
ng discussed here in the form of a trait and additionally provides mechanis=
ms to make use of the trait. Additionally=C2=A0<a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf">N4393</a>=C2=A0proposes t=
he creation of a mechanism to handle the coming into existence (starting th=
e lifetime) of objects, which is from the point of view of the core languag=
e the sticky point of what is being discussed.</div><div><br></div><div>=C2=
=A0 =C2=A0David</div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Thu, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <span dir=3D"ltr=
">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlk=
e.floss@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">O=
n 2015-07-29 18:18, denis bider wrote:<br>
&gt; * I would *much* prefer standard rules for relocatable property infere=
nce,<br>
&gt; than compiler-defined rules.<br>
<br>
I&#39;ll claim an amount of pragmatism here; leaving it to the vendors<br>
allows us to figure out over time what inferences are safe (and imposes<br>
less penalty - at least in terms of strict standards conformance - on<br>
vendors that are slow on the uptake) rather than needing to get it right<br=
>
up front (and follow up with DR&#39;s when it isn&#39;t), in effect growing=
<br>
organically into &quot;the right way&quot;. A bottom up approach as opposed=
 to a<br>
top down approach.<br>
<br>
That said, it&#39;s not a philosophical stance. I have no philosophical<br>
objection to standardizing the rules from the get-go; I just think from<br>
a practical perspective that may be much harder. If you can overcome the<br=
>
practical difficulties, then go for it :-).<br>
<span class=3D""><br>
&gt; Compiler-defined rules mean I can&#39;t rely on anything being relocat=
able,<br>
&gt; unless I declare it. If I get into the habit of declaring everything<b=
r>
&gt; as relocatable, I&#39;ll be creating bugs when I don&#39;t notice that=
 an object<br>
&gt; has a sub-object that is not.<br>
<br>
</span>No, because as you previously indicated (and with which I clearly st=
ated<br>
agreement), the compiler should diagnose entities labeled relocatable<br>
that in fact are not. In that sense, this may be better, because you&#39;ll=
<br>
*know* that an entity is relocatable or not, because if you are in the<br>
habit of marking everything relocatable, the absence of such mark is<br>
meaningful.<br>
<br>
If you rely on implicit marking, you have to actually test.<br>
<span class=3D""><br>
&gt; I would much rather be able to rely on this:<br>
&gt;<br>
&gt; class X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
&gt;<br>
&gt; static_assert(std::is_relocatable&lt;X&gt;::value, &quot;&quot;);<br>
&gt;<br>
&gt; ... than on this:<br>
&gt;<br>
&gt; class [[ relocatable ]] X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
<br>
</span>Per above, the label is equivalent to the static assertion. (Nearly;=
 a<br>
compiler that simply does not support the attribute will ignore it<br>
entirely. Note however that the static assertion would also fail for<br>
such a compiler, which is a potential point in favor of the latter.)<br>
<br>
The &quot;sledgehammer&quot; comes into play when you mark a pointer member=
 as<br>
relocatable. You&#39;ll need that ability in either case, to override the<b=
r>
usual compiler determination that a pointer means that its containing<br>
entity is not relocatable.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Matthew<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a11c37f46732867051c1d02f8--

.

------=_Part_222_1981001329.1438323082476
Content-Type: multipart/alternative;
 boundary="----=_Part_223_1089373457.1438323082476"

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

The crucial rule that I would like to see implemented (and standardized) is=
=20
that a class:

(1) not explicitly marked relocatable (nor marked not-relocatable);

(2) with members and bases that are all relocatable;

(3) that has a trivial or defaulted copy constructor and destructor;

.... is relocatable.

This is crucial for this feature to fulfill its full potential.

If I have a string type that is relocatable, I should be able to do this:

struct A { StringType x; };

and expect A to also be relocatable.

Without this rule, code written to take advantage of the relocatable=20
property will be brittle, and littered with relocatable declarations that=
=20
*should* be inferred.


On Thursday, July 30, 2015 at 1:50:07 PM UTC-6, David Rodr=C3=ADguez Ibeas =
wrote:

> Let me backtrack to a previous statement: compilers don't have enough=20
> information to infer whether a type is relocatable or not, and the decisi=
on=20
> should not be left to the compiler.
>
> The cases mentioned: non-pointer POD, a class whose members are all=20
> relocatable=E2=80=A6 In the case of a POD, it is already bitwise-movable =
which is a=20
> stronger constrain than relocatable.  We don't need to work on PODs, we c=
an=20
> already do it with those.=20
>
> On the other hand, a class whose members are relocatable need not be=20
> relocatable itself.  For example, std::list<T*> would be relocatable, but=
=20
> an object could hold a T member and a std::list<T*> including one pointer=
=20
> to the member making the type self-referencing and thus not-relocatable.
>
> On the suggestion of using a sledgehammer and marking by default types as=
=20
> relocatable, that is too dangerous. When the type is relocatable, and the=
=20
> trait informs us we have an optimization advantage, but if the type is no=
t=20
> relocatable and the traits claims it we break the program.
>
> Reviewing the destructive move proposals by Pablo Halpern I found that=20
> N4158 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf>=
 already=20
> covers what is being discussed here in the form of a trait and additional=
ly=20
> provides mechanisms to make use of the trait. Additionally N4393=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf> propo=
ses=20
> the creation of a mechanism to handle the coming into existence (starting=
=20
> the lifetime) of objects, which is from the point of view of the core=20
> language the sticky point of what is being discussed.
>
>    David
>
> On Thu, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <mwoehlk...@gmail.com=20
> <javascript:>> wrote:
>
>> On 2015-07-29 18:18, denis bider wrote:
>> > * I would *much* prefer standard rules for relocatable property=20
>> inference,
>> > than compiler-defined rules.
>>
>> I'll claim an amount of pragmatism here; leaving it to the vendors
>> allows us to figure out over time what inferences are safe (and imposes
>> less penalty - at least in terms of strict standards conformance - on
>> vendors that are slow on the uptake) rather than needing to get it right
>> up front (and follow up with DR's when it isn't), in effect growing
>> organically into "the right way". A bottom up approach as opposed to a
>> top down approach.
>>
>> That said, it's not a philosophical stance. I have no philosophical
>> objection to standardizing the rules from the get-go; I just think from
>> a practical perspective that may be much harder. If you can overcome the
>> practical difficulties, then go for it :-).
>>
>> > Compiler-defined rules mean I can't rely on anything being relocatable=
,
>> > unless I declare it. If I get into the habit of declaring everything
>> > as relocatable, I'll be creating bugs when I don't notice that an obje=
ct
>> > has a sub-object that is not.
>>
>> No, because as you previously indicated (and with which I clearly stated
>> agreement), the compiler should diagnose entities labeled relocatable
>> that in fact are not. In that sense, this may be better, because you'll
>> *know* that an entity is relocatable or not, because if you are in the
>> habit of marking everything relocatable, the absence of such mark is
>> meaningful.
>>
>> If you rely on implicit marking, you have to actually test.
>>
>> > I would much rather be able to rely on this:
>> >
>> > class X : public BelievedRelocatableBase {
>> > private:
>> >     BelievedRelocatableMember m_x;
>> > };
>> >
>> > static_assert(std::is_relocatable<X>::value, "");
>> >
>> > ... than on this:
>> >
>> > class [[ relocatable ]] X : public BelievedRelocatableBase {
>> > private:
>> >     BelievedRelocatableMember m_x;
>> > };
>>
>> Per above, the label is equivalent to the static assertion. (Nearly; a
>> compiler that simply does not support the attribute will ignore it
>> entirely. Note however that the static assertion would also fail for
>> such a compiler, which is a potential point in favor of the latter.)
>>
>> The "sledgehammer" comes into play when you mark a pointer member as
>> relocatable. You'll need that ability in either case, to override the
>> usual compiler determination that a pointer means that its containing
>> entity is not relocatable.
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

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

<div dir=3D"ltr"><div>The crucial rule that I would like to see implemented=
 (and standardized) is that a class:</div><div><br></div><div>(1)=C2=A0not =
explicitly marked relocatable (nor marked not-relocatable);</div><div><br><=
/div><div>(2)=C2=A0with members=C2=A0and bases=C2=A0that are all relocatabl=
e;</div><div><br></div><div>(3)=C2=A0that has a trivial or defaulted copy c=
onstructor and destructor;</div><div><br></div><div>... is relocatable.</di=
v><div><br></div><div>This is crucial for this feature to fulfill its full =
potential.</div><div><br></div><div>If I have a string type that is relocat=
able, I should be able to do this:</div><div><br></div><div><font face=3D"c=
ourier new,monospace">struct A { StringType x; };</font></div><div><br></di=
v><div>and expect=C2=A0A to also be relocatable.</div><div><br></div><div>W=
ithout this rule, code written=C2=A0to take advantage of=C2=A0the relocatab=
le property will be brittle, and littered with <font face=3D"courier new,mo=
nospace">relocatable</font> declarations that <em>should</em>=C2=A0be=C2=A0=
inferred.</div><div><br><br>On Thursday, July 30, 2015 at 1:50:07 PM UTC-6,=
 David Rodr=C3=ADguez Ibeas wrote:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr">Let me backtrack to a previous statement: compilers don&#39;t ha=
ve enough information to infer whether a type is relocatable or not, and th=
e decision should not be left to the compiler.<div><br></div><div>The cases=
 mentioned: non-pointer POD, a class whose members are all relocatable=E2=
=80=A6 In the case of a POD, it is already bitwise-movable which is a stron=
ger constrain than relocatable.=C2=A0 We don&#39;t need to work on PODs, we=
 can already do it with those.=C2=A0</div><div><br></div><div>On the other =
hand, a class whose members are relocatable need not be relocatable itself.=
=C2=A0 For example, std::list&lt;T*&gt; would be relocatable, but an object=
 could hold a T member and a std::list&lt;T*&gt; including one pointer to t=
he member making the type self-referencing and thus not-relocatable.</div><=
div><br></div><div>On the suggestion of using a sledgehammer and marking by=
 default types as relocatable, that is too dangerous. When the type is relo=
catable, and the trait informs us we have an optimization advantage, but if=
 the type is not relocatable and the traits claims it we break the program.=
</div><div><br></div><div>Reviewing the destructive move proposals by Pablo=
 Halpern I found that=C2=A0<a onmousedown=3D"this.href=3D&#39;http://www.go=
ogle.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%=
2Fpapers%2F2014%2Fn4158.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFSMQjXX1FT4Q=
HQxCpy1JdEdqJMdg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.=
google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdoc=
s%2Fpapers%2F2014%2Fn4158.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFSMQjXX1FT=
4QHQxCpy1JdEdqJMdg&#39;;return true;" href=3D"http://www.open-std.org/jtc1/=
sc22/wg21/docs/papers/2014/n4158.pdf" target=3D"_blank" rel=3D"nofollow">N4=
158</a>=C2=A0already covers what is being discussed here in the form of a t=
rait and additionally provides mechanisms to make use of the trait. Additio=
nally=C2=A0<a onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%=
2Fn4393.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHy-dO5ahTiHM5x-mdfsHGpGeFumw=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q=
\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F201=
5%2Fn4393.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHy-dO5ahTiHM5x-mdfsHGpGeFu=
mw&#39;;return true;" href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2015/n4393.pdf" target=3D"_blank" rel=3D"nofollow">N4393</a>=C2=A0pro=
poses the creation of a mechanism to handle the coming into existence (star=
ting the lifetime) of objects, which is from the point of view of the core =
language the sticky point of what is being discussed.</div><div><br></div><=
div>=C2=A0 =C2=A0David</div></div><div><br><div class=3D"gmail_quote">On Th=
u, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=3D"_bl=
ank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"wZ-YJNVuDgAJ">mwoehlk...@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;">On 2015-07-29 =
18:18, denis bider wrote:<br>
&gt; * I would *much* prefer standard rules for relocatable property infere=
nce,<br>
&gt; than compiler-defined rules.<br>
<br>
I&#39;ll claim an amount of pragmatism here; leaving it to the vendors<br>
allows us to figure out over time what inferences are safe (and imposes<br>
less penalty - at least in terms of strict standards conformance - on<br>
vendors that are slow on the uptake) rather than needing to get it right<br=
>
up front (and follow up with DR&#39;s when it isn&#39;t), in effect growing=
<br>
organically into &quot;the right way&quot;. A bottom up approach as opposed=
 to a<br>
top down approach.<br>
<br>
That said, it&#39;s not a philosophical stance. I have no philosophical<br>
objection to standardizing the rules from the get-go; I just think from<br>
a practical perspective that may be much harder. If you can overcome the<br=
>
practical difficulties, then go for it :-).<br>
<span><br>
&gt; Compiler-defined rules mean I can&#39;t rely on anything being relocat=
able,<br>
&gt; unless I declare it. If I get into the habit of declaring everything<b=
r>
&gt; as relocatable, I&#39;ll be creating bugs when I don&#39;t notice that=
 an object<br>
&gt; has a sub-object that is not.<br>
<br>
</span>No, because as you previously indicated (and with which I clearly st=
ated<br>
agreement), the compiler should diagnose entities labeled relocatable<br>
that in fact are not. In that sense, this may be better, because you&#39;ll=
<br>
*know* that an entity is relocatable or not, because if you are in the<br>
habit of marking everything relocatable, the absence of such mark is<br>
meaningful.<br>
<br>
If you rely on implicit marking, you have to actually test.<br>
<span><br>
&gt; I would much rather be able to rely on this:<br>
&gt;<br>
&gt; class X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
&gt;<br>
&gt; static_assert(std::is_<wbr>relocatable&lt;X&gt;::value, &quot;&quot;);=
<br>
&gt;<br>
&gt; ... than on this:<br>
&gt;<br>
&gt; class [[ relocatable ]] X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
<br>
</span>Per above, the label is equivalent to the static assertion. (Nearly;=
 a<br>
compiler that simply does not support the attribute will ignore it<br>
entirely. Note however that the static assertion would also fail for<br>
such a compiler, which is a potential point in favor of the latter.)<br>
<br>
The &quot;sledgehammer&quot; comes into play when you mark a pointer member=
 as<br>
relocatable. You&#39;ll need that ability in either case, to override the<b=
r>
usual compiler determination that a pointer means that its containing<br>
entity is not relocatable.<br>
<div><div><br>
--<br>
Matthew<br>
<br>
--<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 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"wZ-YJNVuDgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"wZ-YJNVuDgAJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a onmousedown=3D"this.href=3D&#39;http://groups.google=
..com/a/isocpp.org/group/std-proposals/&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;=
return true;" href=3D"http://groups.google.com/a/isocpp.org/group/std-propo=
sals/" target=3D"_blank" rel=3D"nofollow">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></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_223_1089373457.1438323082476--
------=_Part_222_1981001329.1438323082476--

.

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

>
> If I have a string type that is relocatable, I should be able to do this:
>
> struct A { StringType x; };
>
> and expect A to also be relocatable.
>

What if StringType contains an A*? In that scenario StringType was
relocatable on its own but when placed inside of an A it lost its
relocatability.

On Fri, Jul 31, 2015 at 1:11 AM, denis bider <isocppgroup@denisbider.com>
wrote:

> The crucial rule that I would like to see implemented (and standardized)
> is that a class:
>
> (1) not explicitly marked relocatable (nor marked not-relocatable);
>
> (2) with members and bases that are all relocatable;
>
> (3) that has a trivial or defaulted copy constructor and destructor;
>
> ... is relocatable.
>
> This is crucial for this feature to fulfill its full potential.
>
> If I have a string type that is relocatable, I should be able to do this:
>
> struct A { StringType x; };
>
> and expect A to also be relocatable.
>
> Without this rule, code written to take advantage of the relocatable
> property will be brittle, and littered with relocatable declarations that
> *should* be inferred.
>
>
> On Thursday, July 30, 2015 at 1:50:07 PM UTC-6, David Rodr=C3=ADguez Ibea=
s
> wrote:
>
>> Let me backtrack to a previous statement: compilers don't have enough
>> information to infer whether a type is relocatable or not, and the decis=
ion
>> should not be left to the compiler.
>>
>> The cases mentioned: non-pointer POD, a class whose members are all
>> relocatable=E2=80=A6 In the case of a POD, it is already bitwise-movable=
 which is a
>> stronger constrain than relocatable.  We don't need to work on PODs, we =
can
>> already do it with those.
>>
>> On the other hand, a class whose members are relocatable need not be
>> relocatable itself.  For example, std::list<T*> would be relocatable, bu=
t
>> an object could hold a T member and a std::list<T*> including one pointe=
r
>> to the member making the type self-referencing and thus not-relocatable.
>>
>> On the suggestion of using a sledgehammer and marking by default types a=
s
>> relocatable, that is too dangerous. When the type is relocatable, and th=
e
>> trait informs us we have an optimization advantage, but if the type is n=
ot
>> relocatable and the traits claims it we break the program.
>>
>> Reviewing the destructive move proposals by Pablo Halpern I found that
>> N4158 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf=
> already
>> covers what is being discussed here in the form of a trait and additiona=
lly
>> provides mechanisms to make use of the trait. Additionally N4393
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf> prop=
oses
>> the creation of a mechanism to handle the coming into existence (startin=
g
>> the lifetime) of objects, which is from the point of view of the core
>> language the sticky point of what is being discussed.
>>
>>    David
>>
>> On Thu, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <mwoehlk...@gmail.com>
>> wrote:
>>
>>> On 2015-07-29 18:18, denis bider wrote:
>>> > * I would *much* prefer standard rules for relocatable property
>>> inference,
>>> > than compiler-defined rules.
>>>
>>> I'll claim an amount of pragmatism here; leaving it to the vendors
>>> allows us to figure out over time what inferences are safe (and imposes
>>> less penalty - at least in terms of strict standards conformance - on
>>> vendors that are slow on the uptake) rather than needing to get it righ=
t
>>> up front (and follow up with DR's when it isn't), in effect growing
>>> organically into "the right way". A bottom up approach as opposed to a
>>> top down approach.
>>>
>>> That said, it's not a philosophical stance. I have no philosophical
>>> objection to standardizing the rules from the get-go; I just think from
>>> a practical perspective that may be much harder. If you can overcome th=
e
>>> practical difficulties, then go for it :-).
>>>
>>> > Compiler-defined rules mean I can't rely on anything being relocatabl=
e,
>>> > unless I declare it. If I get into the habit of declaring everything
>>> > as relocatable, I'll be creating bugs when I don't notice that an
>>> object
>>> > has a sub-object that is not.
>>>
>>> No, because as you previously indicated (and with which I clearly state=
d
>>> agreement), the compiler should diagnose entities labeled relocatable
>>> that in fact are not. In that sense, this may be better, because you'll
>>> *know* that an entity is relocatable or not, because if you are in the
>>> habit of marking everything relocatable, the absence of such mark is
>>> meaningful.
>>>
>>> If you rely on implicit marking, you have to actually test.
>>>
>>> > I would much rather be able to rely on this:
>>> >
>>> > class X : public BelievedRelocatableBase {
>>> > private:
>>> >     BelievedRelocatableMember m_x;
>>> > };
>>> >
>>> > static_assert(std::is_relocatable<X>::value, "");
>>> >
>>> > ... than on this:
>>> >
>>> > class [[ relocatable ]] X : public BelievedRelocatableBase {
>>> > private:
>>> >     BelievedRelocatableMember m_x;
>>> > };
>>>
>>> Per above, the label is equivalent to the static assertion. (Nearly; a
>>> compiler that simply does not support the attribute will ignore it
>>> entirely. Note however that the static assertion would also fail for
>>> such a compiler, which is a potential point in favor of the latter.)
>>>
>>> The "sledgehammer" comes into play when you mark a pointer member as
>>> relocatable. You'll need that ability in either case, to override the
>>> usual compiler determination that a pointer means that its containing
>>> entity is not relocatable.
>>>
>>> --
>>> Matthew
>>>
>>> --
>>>
>>> ---
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

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

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

<div dir=3D"ltr"><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-l=
eft-style:solid;padding-left:1ex"><div style=3D"font-size:12.8000001907349p=
x">If I have a string type that is relocatable, I should be able to do this=
:</div><div style=3D"font-size:12.8000001907349px"><br></div><div style=3D"=
font-size:12.8000001907349px"><font face=3D"courier new,monospace">struct A=
 { StringType x; };</font></div><div style=3D"font-size:12.8000001907349px"=
><br></div><div style=3D"font-size:12.8000001907349px">and expect=C2=A0A to=
 also be relocatable.</div></blockquote><div><br></div><div>What if StringT=
ype contains an A*? In that scenario StringType was relocatable on its own =
but when placed inside of an A it lost its relocatability.</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 31, 2015 a=
t 1:11 AM, denis bider <span dir=3D"ltr">&lt;<a href=3D"mailto:isocppgroup@=
denisbider.com" target=3D"_blank">isocppgroup@denisbider.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The crucial=
 rule that I would like to see implemented (and standardized) is that a cla=
ss:</div><div><br></div><div>(1)=C2=A0not explicitly marked relocatable (no=
r marked not-relocatable);</div><div><br></div><div>(2)=C2=A0with members=
=C2=A0and bases=C2=A0that are all relocatable;</div><div><br></div><div>(3)=
=C2=A0that has a trivial or defaulted copy constructor and destructor;</div=
><div><br></div><div>... is relocatable.</div><div><br></div><div>This is c=
rucial for this feature to fulfill its full potential.</div><div><br></div>=
<div>If I have a string type that is relocatable, I should be able to do th=
is:</div><div><br></div><div><font face=3D"courier new,monospace">struct A =
{ StringType x; };</font></div><div><br></div><div>and expect=C2=A0A to als=
o be relocatable.</div><div><br></div><div>Without this rule, code written=
=C2=A0to take advantage of=C2=A0the relocatable property will be brittle, a=
nd littered with <font face=3D"courier new,monospace">relocatable</font> de=
clarations that <em>should</em>=C2=A0be=C2=A0inferred.</div><span class=3D"=
"><div><br><br>On Thursday, July 30, 2015 at 1:50:07 PM UTC-6, David Rodr=
=C3=ADguez Ibeas wrote:</div></span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><span class=3D""><div =
dir=3D"ltr">Let me backtrack to a previous statement: compilers don&#39;t h=
ave enough information to infer whether a type is relocatable or not, and t=
he decision should not be left to the compiler.<div><br></div><div>The case=
s mentioned: non-pointer POD, a class whose members are all relocatable=E2=
=80=A6 In the case of a POD, it is already bitwise-movable which is a stron=
ger constrain than relocatable.=C2=A0 We don&#39;t need to work on PODs, we=
 can already do it with those.=C2=A0</div><div><br></div><div>On the other =
hand, a class whose members are relocatable need not be relocatable itself.=
=C2=A0 For example, std::list&lt;T*&gt; would be relocatable, but an object=
 could hold a T member and a std::list&lt;T*&gt; including one pointer to t=
he member making the type self-referencing and thus not-relocatable.</div><=
div><br></div><div>On the suggestion of using a sledgehammer and marking by=
 default types as relocatable, that is too dangerous. When the type is relo=
catable, and the trait informs us we have an optimization advantage, but if=
 the type is not relocatable and the traits claims it we break the program.=
</div><div><br></div><div>Reviewing the destructive move proposals by Pablo=
 Halpern I found that=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2014/n4158.pdf" rel=3D"nofollow" target=3D"_blank">N4158</a>=
=C2=A0already covers what is being discussed here in the form of a trait an=
d additionally provides mechanisms to make use of the trait. Additionally=
=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4=
393.pdf" rel=3D"nofollow" target=3D"_blank">N4393</a>=C2=A0proposes the cre=
ation of a mechanism to handle the coming into existence (starting the life=
time) of objects, which is from the point of view of the core language the =
sticky point of what is being discussed.</div><div><br></div><div>=C2=A0 =
=C2=A0David</div></div></span><div><br><div class=3D"gmail_quote"><div><div=
 class=3D"h5">On Thu, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <span dir=3D=
"ltr">&lt;<a rel=3D"nofollow">mwoehlk...@gmail.com</a>&gt;</span> wrote:<br=
></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid"><div><div class=3D"h5">On 2015-07-29 18:18, d=
enis bider wrote:<br>
&gt; * I would *much* prefer standard rules for relocatable property infere=
nce,<br>
&gt; than compiler-defined rules.<br>
<br>
I&#39;ll claim an amount of pragmatism here; leaving it to the vendors<br>
allows us to figure out over time what inferences are safe (and imposes<br>
less penalty - at least in terms of strict standards conformance - on<br>
vendors that are slow on the uptake) rather than needing to get it right<br=
>
up front (and follow up with DR&#39;s when it isn&#39;t), in effect growing=
<br>
organically into &quot;the right way&quot;. A bottom up approach as opposed=
 to a<br>
top down approach.<br>
<br>
That said, it&#39;s not a philosophical stance. I have no philosophical<br>
objection to standardizing the rules from the get-go; I just think from<br>
a practical perspective that may be much harder. If you can overcome the<br=
>
practical difficulties, then go for it :-).<br>
<span><br>
&gt; Compiler-defined rules mean I can&#39;t rely on anything being relocat=
able,<br>
&gt; unless I declare it. If I get into the habit of declaring everything<b=
r>
&gt; as relocatable, I&#39;ll be creating bugs when I don&#39;t notice that=
 an object<br>
&gt; has a sub-object that is not.<br>
<br>
</span>No, because as you previously indicated (and with which I clearly st=
ated<br>
agreement), the compiler should diagnose entities labeled relocatable<br>
that in fact are not. In that sense, this may be better, because you&#39;ll=
<br>
*know* that an entity is relocatable or not, because if you are in the<br>
habit of marking everything relocatable, the absence of such mark is<br>
meaningful.<br>
<br>
If you rely on implicit marking, you have to actually test.<br>
<span><br>
&gt; I would much rather be able to rely on this:<br>
&gt;<br>
&gt; class X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
&gt;<br>
&gt; static_assert(std::is_relocatable&lt;X&gt;::value, &quot;&quot;);<br>
&gt;<br>
&gt; ... than on this:<br>
&gt;<br>
&gt; class [[ relocatable ]] X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
<br>
</span>Per above, the label is equivalent to the static assertion. (Nearly;=
 a<br>
compiler that simply does not support the attribute will ignore it<br>
entirely. Note however that the static assertion would also fail for<br>
such a compiler, which is a potential point in favor of the latter.)<br>
<br>
The &quot;sledgehammer&quot; comes into play when you mark a pointer member=
 as<br>
relocatable. You&#39;ll need that ability in either case, to override the<b=
r>
usual compiler determination that a pointer means that its containing<br>
entity is not relocatable.<br>
</div></div><div><div><div><div class=3D"h5"><br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--e89a8f83a83b62d01a051c2663ae--

.

------=_Part_285_1363801742.1438327280888
Content-Type: multipart/alternative;
 boundary="----=_Part_286_69224838.1438327280888"

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

What rules do you assume were used to determine that StringType is=20
relocatable? Do you assume that this trait was inferred somehow?

My assumption is that StringType was explicitly declared relocatable by the=
=20
developer. It would need to be so declared given that it's likely a complex=
=20
class that owns resources and implements copy constructors and a destructor=
..

I'm not proposing to *eliminate* the developer's role in marking types=20
relocatable. I'm proposing a mechanism to naturally infer the developer's=
=20
intent, based on classes he has *already* marked.

This follows the principle that the developer should express *core*=20
decisions (e.g. I'm going to develop a string type with explicit intent=20
that it's going to be relocatable), as opposed to trivial decisions.


On Friday, July 31, 2015 at 1:01:26 AM UTC-6, Brent Friedman wrote:

> If I have a string type that is relocatable, I should be able to do this:
>>
>> struct A { StringType x; };
>>
>> and expect A to also be relocatable.
>>
>
> What if StringType contains an A*? In that scenario StringType was=20
> relocatable on its own but when placed inside of an A it lost its=20
> relocatability.
>
> On Fri, Jul 31, 2015 at 1:11 AM, denis bider <isocp...@denisbider.com=20
> <javascript:>> wrote:
>
>> The crucial rule that I would like to see implemented (and standardized)=
=20
>> is that a class:
>>
>> (1) not explicitly marked relocatable (nor marked not-relocatable);
>>
>> (2) with members and bases that are all relocatable;
>>
>> (3) that has a trivial or defaulted copy constructor and destructor;
>>
>> ... is relocatable.
>>
>> This is crucial for this feature to fulfill its full potential.
>>
>> If I have a string type that is relocatable, I should be able to do this=
:
>>
>> struct A { StringType x; };
>>
>> and expect A to also be relocatable.
>>
>> Without this rule, code written to take advantage of the relocatable=20
>> property will be brittle, and littered with relocatable declarations=20
>> that *should* be inferred.
>>
>>
>> On Thursday, July 30, 2015 at 1:50:07 PM UTC-6, David Rodr=C3=ADguez Ibe=
as=20
>> wrote:
>>
>>> Let me backtrack to a previous statement: compilers don't have enough=
=20
>>> information to infer whether a type is relocatable or not, and the deci=
sion=20
>>> should not be left to the compiler.
>>>
>>> The cases mentioned: non-pointer POD, a class whose members are all=20
>>> relocatable=E2=80=A6 In the case of a POD, it is already bitwise-movabl=
e which is a=20
>>> stronger constrain than relocatable.  We don't need to work on PODs, we=
 can=20
>>> already do it with those.=20
>>>
>>> On the other hand, a class whose members are relocatable need not be=20
>>> relocatable itself.  For example, std::list<T*> would be relocatable, b=
ut=20
>>> an object could hold a T member and a std::list<T*> including one point=
er=20
>>> to the member making the type self-referencing and thus not-relocatable=
..
>>>
>>> On the suggestion of using a sledgehammer and marking by default types=
=20
>>> as relocatable, that is too dangerous. When the type is relocatable, an=
d=20
>>> the trait informs us we have an optimization advantage, but if the type=
 is=20
>>> not relocatable and the traits claims it we break the program.
>>>
>>> Reviewing the destructive move proposals by Pablo Halpern I found that=
=20
>>> N4158=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf> alr=
eady=20
>>> covers what is being discussed here in the form of a trait and addition=
ally=20
>>> provides mechanisms to make use of the trait. Additionally N4393=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf> pro=
poses=20
>>> the creation of a mechanism to handle the coming into existence (starti=
ng=20
>>> the lifetime) of objects, which is from the point of view of the core=
=20
>>> language the sticky point of what is being discussed.
>>>
>>>    David
>>>
>>> On Thu, Jul 30, 2015 at 5:02 PM, Matthew Woehlke <mwoehlk...@gmail.com>=
=20
>>> wrote:
>>>
>>>> On 2015-07-29 18:18, denis bider wrote:
>>>> > * I would *much* prefer standard rules for relocatable property=20
>>>> inference,
>>>> > than compiler-defined rules.
>>>>
>>>> I'll claim an amount of pragmatism here; leaving it to the vendors
>>>> allows us to figure out over time what inferences are safe (and impose=
s
>>>> less penalty - at least in terms of strict standards conformance - on
>>>> vendors that are slow on the uptake) rather than needing to get it rig=
ht
>>>> up front (and follow up with DR's when it isn't), in effect growing
>>>> organically into "the right way". A bottom up approach as opposed to a
>>>> top down approach.
>>>>
>>>> That said, it's not a philosophical stance. I have no philosophical
>>>> objection to standardizing the rules from the get-go; I just think fro=
m
>>>> a practical perspective that may be much harder. If you can overcome t=
he
>>>> practical difficulties, then go for it :-).
>>>>
>>>> > Compiler-defined rules mean I can't rely on anything being=20
>>>> relocatable,
>>>> > unless I declare it. If I get into the habit of declaring everything
>>>> > as relocatable, I'll be creating bugs when I don't notice that an=20
>>>> object
>>>> > has a sub-object that is not.
>>>>
>>>> No, because as you previously indicated (and with which I clearly stat=
ed
>>>> agreement), the compiler should diagnose entities labeled relocatable
>>>> that in fact are not. In that sense, this may be better, because you'l=
l
>>>> *know* that an entity is relocatable or not, because if you are in the
>>>> habit of marking everything relocatable, the absence of such mark is
>>>> meaningful.
>>>>
>>>> If you rely on implicit marking, you have to actually test.
>>>>
>>>> > I would much rather be able to rely on this:
>>>> >
>>>> > class X : public BelievedRelocatableBase {
>>>> > private:
>>>> >     BelievedRelocatableMember m_x;
>>>> > };
>>>> >
>>>> > static_assert(std::is_relocatable<X>::value, "");
>>>> >
>>>> > ... than on this:
>>>> >
>>>> > class [[ relocatable ]] X : public BelievedRelocatableBase {
>>>> > private:
>>>> >     BelievedRelocatableMember m_x;
>>>> > };
>>>>
>>>> Per above, the label is equivalent to the static assertion. (Nearly; a
>>>> compiler that simply does not support the attribute will ignore it
>>>> entirely. Note however that the static assertion would also fail for
>>>> such a compiler, which is a potential point in favor of the latter.)
>>>>
>>>> The "sledgehammer" comes into play when you mark a pointer member as
>>>> relocatable. You'll need that ability in either case, to override the
>>>> usual compiler determination that a pointer means that its containing
>>>> entity is not relocatable.
>>>>
>>>> --
>>>> Matthew
>>>>
>>>> --
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> Visit this group at=20
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

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

<div dir=3D"ltr"><div>What rules do you assume=C2=A0were used to=C2=A0deter=
mine that StringType is relocatable? Do you assume that this trait was infe=
rred somehow?</div><div><br></div><div>My assumption is=C2=A0that StringTyp=
e was explicitly declared relocatable by the developer. It would need to be=
 so declared=C2=A0given that it&#39;s likely=C2=A0a complex class that owns=
 resources and implements copy constructors and a destructor.</div><div><br=
></div><div>I&#39;m not proposing to <em>eliminate</em> the developer&#39;s=
 role in marking types relocatable.=C2=A0I&#39;m proposing a mechanism to n=
aturally infer the developer&#39;s intent, based on classes he has <em>alre=
ady</em> marked.</div><div><br></div><div>This follows the principle that t=
he developer should=C2=A0express <em>core</em> decisions (e.g. I&#39;m goin=
g to develop a string type=C2=A0with explicit intent that it&#39;s going to=
 be=C2=A0relocatable), as opposed to trivial decisions.</div><div><br><br>O=
n Friday, July 31, 2015 at 1:01:26 AM UTC-6, Brent Friedman wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v style=3D"font-size: 12.8px;">If I have a string type that is relocatable,=
 I should be able to do this:</div><div style=3D"font-size: 12.8px;"><br></=
div><div style=3D"font-size: 12.8px;"><font face=3D"courier new,monospace">=
struct A { StringType x; };</font></div><div style=3D"font-size: 12.8px;"><=
br></div><div style=3D"font-size: 12.8px;">and expect=C2=A0A to also be rel=
ocatable.</div></blockquote><div><br></div><div>What if StringType contains=
 an A*? In that scenario StringType was relocatable on its own but when pla=
ced inside of an A it lost its relocatability.</div></div><div><br><div cla=
ss=3D"gmail_quote">On Fri, Jul 31, 2015 at 1:11 AM, denis bider <span dir=
=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Xw96YX=
eTDgAJ">isocp...@denisbider.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div>The crucial rule that I would like to see=
 implemented (and standardized) is that a class:</div><div><br></div><div>(=
1)=C2=A0not explicitly marked relocatable (nor marked not-relocatable);</di=
v><div><br></div><div>(2)=C2=A0with members=C2=A0and bases=C2=A0that are al=
l relocatable;</div><div><br></div><div>(3)=C2=A0that has a trivial or defa=
ulted copy constructor and destructor;</div><div><br></div><div>... is relo=
catable.</div><div><br></div><div>This is crucial for this feature to fulfi=
ll its full potential.</div><div><br></div><div>If I have a string type tha=
t is relocatable, I should be able to do this:</div><div><br></div><div><fo=
nt face=3D"courier new,monospace">struct A { StringType x; };</font></div><=
div><br></div><div>and expect=C2=A0A to also be relocatable.</div><div><br>=
</div><div>Without this rule, code written=C2=A0to take advantage of=C2=A0t=
he relocatable property will be brittle, and littered with <font face=3D"co=
urier new,monospace">relocatable</font> declarations that <em>should</em>=
=C2=A0be=C2=A0inferred.</div><span><div><br><br>On Thursday, July 30, 2015 =
at 1:50:07 PM UTC-6, David Rodr=C3=ADguez Ibeas wrote:</div></span><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><span><div dir=3D"ltr">Let me backtrack to a previous =
statement: compilers don&#39;t have enough information to infer whether a t=
ype is relocatable or not, and the decision should not be left to the compi=
ler.<div><br></div><div>The cases mentioned: non-pointer POD, a class whose=
 members are all relocatable=E2=80=A6 In the case of a POD, it is already b=
itwise-movable which is a stronger constrain than relocatable.=C2=A0 We don=
&#39;t need to work on PODs, we can already do it with those.=C2=A0</div><d=
iv><br></div><div>On the other hand, a class whose members are relocatable =
need not be relocatable itself.=C2=A0 For example, std::list&lt;T*&gt; woul=
d be relocatable, but an object could hold a T member and a std::list&lt;T*=
&gt; including one pointer to the member making the type self-referencing a=
nd thus not-relocatable.</div><div><br></div><div>On the suggestion of usin=
g a sledgehammer and marking by default types as relocatable, that is too d=
angerous. When the type is relocatable, and the trait informs us we have an=
 optimization advantage, but if the type is not relocatable and the traits =
claims it we break the program.</div><div><br></div><div>Reviewing the dest=
ructive move proposals by Pablo Halpern I found that=C2=A0<a onmousedown=3D=
"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4158.pdf\46sa\75D\46sntz\=
0751\46usg\75AFQjCNFSMQjXX1FT4QHQxCpy1JdEdqJMdg&#39;;return true;" onclick=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4158.pdf\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNFSMQjXX1FT4QHQxCpy1JdEdqJMdg&#39;;return true;" href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf" targ=
et=3D"_blank" rel=3D"nofollow">N4158</a>=C2=A0already covers what is being =
discussed here in the form of a trait and additionally provides mechanisms =
to make use of the trait. Additionally=C2=A0<a onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4393.pdf\46sa\75D\46sntz\0751\46usg\75A=
FQjCNHy-dO5ahTiHM5x-mdfsHGpGeFumw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4393.pdf\46sa\75D\46sntz\0751\46usg=
\75AFQjCNHy-dO5ahTiHM5x-mdfsHGpGeFumw&#39;;return true;" href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf" target=3D"_blank" =
rel=3D"nofollow">N4393</a>=C2=A0proposes the creation of a mechanism to han=
dle the coming into existence (starting the lifetime) of objects, which is =
from the point of view of the core language the sticky point of what is bei=
ng discussed.</div><div><br></div><div>=C2=A0 =C2=A0David</div></div></span=
><div><br><div class=3D"gmail_quote"><div><div>On Thu, Jul 30, 2015 at 5:02=
 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a rel=3D"nofollow">mwoehlk...@g=
mail.com</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div><div>On 2015-07-29 18:18, denis bider wrote:<br>
&gt; * I would *much* prefer standard rules for relocatable property infere=
nce,<br>
&gt; than compiler-defined rules.<br>
<br>
I&#39;ll claim an amount of pragmatism here; leaving it to the vendors<br>
allows us to figure out over time what inferences are safe (and imposes<br>
less penalty - at least in terms of strict standards conformance - on<br>
vendors that are slow on the uptake) rather than needing to get it right<br=
>
up front (and follow up with DR&#39;s when it isn&#39;t), in effect growing=
<br>
organically into &quot;the right way&quot;. A bottom up approach as opposed=
 to a<br>
top down approach.<br>
<br>
That said, it&#39;s not a philosophical stance. I have no philosophical<br>
objection to standardizing the rules from the get-go; I just think from<br>
a practical perspective that may be much harder. If you can overcome the<br=
>
practical difficulties, then go for it :-).<br>
<span><br>
&gt; Compiler-defined rules mean I can&#39;t rely on anything being relocat=
able,<br>
&gt; unless I declare it. If I get into the habit of declaring everything<b=
r>
&gt; as relocatable, I&#39;ll be creating bugs when I don&#39;t notice that=
 an object<br>
&gt; has a sub-object that is not.<br>
<br>
</span>No, because as you previously indicated (and with which I clearly st=
ated<br>
agreement), the compiler should diagnose entities labeled relocatable<br>
that in fact are not. In that sense, this may be better, because you&#39;ll=
<br>
*know* that an entity is relocatable or not, because if you are in the<br>
habit of marking everything relocatable, the absence of such mark is<br>
meaningful.<br>
<br>
If you rely on implicit marking, you have to actually test.<br>
<span><br>
&gt; I would much rather be able to rely on this:<br>
&gt;<br>
&gt; class X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
&gt;<br>
&gt; static_assert(std::is_<wbr>relocatable&lt;X&gt;::value, &quot;&quot;);=
<br>
&gt;<br>
&gt; ... than on this:<br>
&gt;<br>
&gt; class [[ relocatable ]] X : public BelievedRelocatableBase {<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0 =C2=A0BelievedRelocatableMember m_x;<br>
&gt; };<br>
<br>
</span>Per above, the label is equivalent to the static assertion. (Nearly;=
 a<br>
compiler that simply does not support the attribute will ignore it<br>
entirely. Note however that the static assertion would also fail for<br>
such a compiler, which is a potential point in favor of the latter.)<br>
<br>
The &quot;sledgehammer&quot; comes into play when you mark a pointer member=
 as<br>
relocatable. You&#39;ll need that ability in either case, to override the<b=
r>
usual compiler determination that a pointer means that its containing<br>
entity is not relocatable.<br>
</div></div><div><div><div><div><br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
Visit this group at <a onmousedown=3D"this.href=3D&#39;http://groups.google=
..com/a/isocpp.org/group/std-proposals/&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;=
return true;" href=3D"http://groups.google.com/a/isocpp.org/group/std-propo=
sals/" target=3D"_blank" rel=3D"nofollow">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></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 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Xw96YXeTDgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"Xw96YXeTDgAJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a onmousedown=3D"this.href=3D&#39;http://groups.google=
..com/a/isocpp.org/group/std-proposals/&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;=
return true;" href=3D"http://groups.google.com/a/isocpp.org/group/std-propo=
sals/" target=3D"_blank" rel=3D"nofollow">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></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_286_69224838.1438327280888--
------=_Part_285_1363801742.1438327280888--

.

On Thursday 30 July 2015 23:11:22 denis bider wrote:
> (1) not explicitly marked relocatable (nor marked not-relocatable);
>
> (2) with members and bases that are all relocatable;
>
> (3) that has a trivial or defaulted copy constructor and destructor;

#3 alone is enough. A class with a trivial copy constructor and a trivial
destructor can already be optimised.

The attribute is not needed for those cases.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--001a11c2588eb81ac8051c2851f6
Content-Type: text/plain; charset=UTF-8

I am not sure that Denis' rules are sufficient, but note that (3) refers to
a trivial or *defaulted* copy-constructor.  A defaulted copy constructor
may not be trivial and (3) is aiming to extend the inferred
"relocatability" to those.  Since all trivial copy-constructors are
implicitly defined, we can rewrite that in a, possibly, less misleading way
as:

(3) has an implicitly defined or defaulted copy constructor and destructor.

I am not sure whether the rules are sufficient but it probably is. Rule 3
is clearly necessary as if a type is [potentially, consider the NullObject
pattern] self-referencing the copy-constructor would have to handle that
case and cannot be compiler defined.  The members themselves cannot be
self-referencing as that would make them not relocatable and break rule 2,
so the compiler generated copy constructor cannot "fix" the
self-references, if any.

I am not sure whether the destructor need be "defaulted" or not, I believe
this is not necessary. The compiler can be non-trivial, which is the whole
point of the exercise. A 'unique_ptr' is clearly relocatable and has a
non-trivial destructor. In general, a "relocatable" type whose destructor
is trivial would be bitwise copyable (stronger guarantee: it does not
matter if the destructor is run or not, it doesn't do anything).

So the question is: what could possibly be added to a destructor body in
the complete object to make it not relocatable? And I believe the answer to
be: nothing that would not have forced the user to define a
copy-constructor.

    David




On Fri, Jul 31, 2015 at 9:33 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Thursday 30 July 2015 23:11:22 denis bider wrote:
> > (1) not explicitly marked relocatable (nor marked not-relocatable);
> >
> > (2) with members and bases that are all relocatable;
> >
> > (3) that has a trivial or defaulted copy constructor and destructor;
>
> #3 alone is enough. A class with a trivial copy constructor and a trivial
> destructor can already be optimised.
>
> The attribute is not needed for those cases.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">I am not sure that Denis&#39; rules are sufficient, but no=
te that (3) refers to a trivial or *defaulted* copy-constructor.=C2=A0 A de=
faulted copy constructor may not be trivial and (3) is aiming to extend the=
 inferred &quot;relocatability&quot; to those.=C2=A0 Since all trivial copy=
-constructors are implicitly defined, we can rewrite that in a, possibly, l=
ess misleading way as:<br><br>(3) has an implicitly defined or defaulted co=
py constructor and destructor.<br><br>I am not sure whether the rules are s=
ufficient but it probably is. Rule 3 is clearly necessary as if a type is [=
potentially, consider the NullObject pattern] self-referencing the copy-con=
structor would have to handle that case and cannot be compiler defined.=C2=
=A0 The members themselves cannot be self-referencing as that would make th=
em not relocatable and break rule 2, so the compiler generated copy constru=
ctor cannot &quot;fix&quot; the self-references, if any. =C2=A0<br><br>I am=
 not sure whether the destructor need be &quot;defaulted&quot; or not, I be=
lieve this is not necessary. The compiler can be non-trivial, which is the =
whole point of the exercise. A &#39;unique_ptr&#39; is clearly relocatable =
and has a non-trivial destructor. In general, a &quot;relocatable&quot; typ=
e whose destructor is trivial would be bitwise copyable (stronger guarantee=
: it does not matter if the destructor is run or not, it doesn&#39;t do any=
thing). <br><br>So the question is: what could possibly be added to a destr=
uctor body in the complete object to make it not relocatable? And I believe=
 the answer to be: nothing that would not have forced the user to define a =
copy-constructor.<br><br>=C2=A0 =C2=A0 David<br><br><br><br></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 31, 2015 at 9:=
33 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macie=
ira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><span class=3D"">On Thursday 30 July 2015 23:11=
:22 denis bider wrote:<br>
&gt; (1) not explicitly marked relocatable (nor marked not-relocatable);<br=
>
&gt;<br>
&gt; (2) with members and bases that are all relocatable;<br>
&gt;<br>
&gt; (3) that has a trivial or defaulted copy constructor and destructor;<b=
r>
<br>
</span>#3 alone is enough. A class with a trivial copy constructor and a tr=
ivial<br>
destructor can already be optimised.<br>
<br>
The attribute is not needed for those cases.<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a11c2588eb81ac8051c2851f6--

.

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

Still, before arguing about the rules that a compiler could use to
implicitly mark a type as relocatable we would need to have the feature in
the language.  Pablo's papers (specifically N4158) aim to get that, we
shall see how it fares/fared in the committee.

On Fri, Jul 31, 2015 at 10:19 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.o=
rg>
wrote:

> I am not sure that Denis' rules are sufficient, but note that (3) refers
> to a trivial or *defaulted* copy-constructor.  A defaulted copy construct=
or
> may not be trivial and (3) is aiming to extend the inferred
> "relocatability" to those.  Since all trivial copy-constructors are
> implicitly defined, we can rewrite that in a, possibly, less misleading w=
ay
> as:
>
> (3) has an implicitly defined or defaulted copy constructor and destructo=
r.
>
> I am not sure whether the rules are sufficient but it probably is. Rule 3
> is clearly necessary as if a type is [potentially, consider the NullObjec=
t
> pattern] self-referencing the copy-constructor would have to handle that
> case and cannot be compiler defined.  The members themselves cannot be
> self-referencing as that would make them not relocatable and break rule 2=
,
> so the compiler generated copy constructor cannot "fix" the
> self-references, if any.
>
> I am not sure whether the destructor need be "defaulted" or not, I believ=
e
> this is not necessary. The compiler can be non-trivial, which is the whol=
e
> point of the exercise. A 'unique_ptr' is clearly relocatable and has a
> non-trivial destructor. In general, a "relocatable" type whose destructor
> is trivial would be bitwise copyable (stronger guarantee: it does not
> matter if the destructor is run or not, it doesn't do anything).
>
> So the question is: what could possibly be added to a destructor body in
> the complete object to make it not relocatable? And I believe the answer =
to
> be: nothing that would not have forced the user to define a
> copy-constructor.
>
>     David
>
>
>
>
> On Fri, Jul 31, 2015 at 9:33 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> On Thursday 30 July 2015 23:11:22 denis bider wrote:
>> > (1) not explicitly marked relocatable (nor marked not-relocatable);
>> >
>> > (2) with members and bases that are all relocatable;
>> >
>> > (3) that has a trivial or defaulted copy constructor and destructor;
>>
>> #3 alone is enough. A class with a trivial copy constructor and a trivia=
l
>> destructor can already be optimised.
>>
>> The attribute is not needed for those cases.
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>       PGP/GPG: 0x6EF45358; fingerprint:
>>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>

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

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

<div dir=3D"ltr">Still, before arguing about the rules that a compiler coul=
d use to implicitly mark a type as relocatable we would need to have the fe=
ature in the language.=C2=A0 Pablo&#39;s papers (specifically N4158) aim to=
 get that, we shall see how it fares/fared in the committee.</div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 31, 2015 at 10=
:19 AM, David Rodr=C3=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am not sure that Denis&#=
39; rules are sufficient, but note that (3) refers to a trivial or *default=
ed* copy-constructor.=C2=A0 A defaulted copy constructor may not be trivial=
 and (3) is aiming to extend the inferred &quot;relocatability&quot; to tho=
se.=C2=A0 Since all trivial copy-constructors are implicitly defined, we ca=
n rewrite that in a, possibly, less misleading way as:<br><br>(3) has an im=
plicitly defined or defaulted copy constructor and destructor.<br><br>I am =
not sure whether the rules are sufficient but it probably is. Rule 3 is cle=
arly necessary as if a type is [potentially, consider the NullObject patter=
n] self-referencing the copy-constructor would have to handle that case and=
 cannot be compiler defined.=C2=A0 The members themselves cannot be self-re=
ferencing as that would make them not relocatable and break rule 2, so the =
compiler generated copy constructor cannot &quot;fix&quot; the self-referen=
ces, if any. =C2=A0<br><br>I am not sure whether the destructor need be &qu=
ot;defaulted&quot; or not, I believe this is not necessary. The compiler ca=
n be non-trivial, which is the whole point of the exercise. A &#39;unique_p=
tr&#39; is clearly relocatable and has a non-trivial destructor. In general=
, a &quot;relocatable&quot; type whose destructor is trivial would be bitwi=
se copyable (stronger guarantee: it does not matter if the destructor is ru=
n or not, it doesn&#39;t do anything). <br><br>So the question is: what cou=
ld possibly be added to a destructor body in the complete object to make it=
 not relocatable? And I believe the answer to be: nothing that would not ha=
ve forced the user to define a copy-constructor.<span class=3D"HOEnZb"><fon=
t color=3D"#888888"><br><br>=C2=A0 =C2=A0 David<br><br><br><br></font></spa=
n></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Fri, Jul 31, 2015 at 9:33 AM, Thiago Maci=
eira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D=
"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span>On Thursday 30 July 2015 23:11:22 denis bider wrote:<br>
&gt; (1) not explicitly marked relocatable (nor marked not-relocatable);<br=
>
&gt;<br>
&gt; (2) with members and bases that are all relocatable;<br>
&gt;<br>
&gt; (3) that has a trivial or defaulted copy constructor and destructor;<b=
r>
<br>
</span>#3 alone is enough. A class with a trivial copy constructor and a tr=
ivial<br>
destructor can already be optimised.<br>
<br>
The attribute is not needed for those cases.<br>
<span><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div><div><br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a113492b8435114051c2885ef--

.

On 2015-07-31 05:19, David Rodr=C3=ADguez Ibeas wrote:
> I am not sure that Denis' rules are sufficient, but note that (3) refers =
to
> a trivial or *defaulted* copy-constructor.  A defaulted copy constructor
> may not be trivial and (3) is aiming to extend the inferred
> "relocatability" to those.

Right. Although...

> I am not sure whether the destructor need be "defaulted" or not, I believ=
e
> this is not necessary. The compiler can be non-trivial, which is the whol=
e
> point of the exercise. A 'unique_ptr' is clearly relocatable and has a
> non-trivial destructor. In general, a "relocatable" type whose destructor
> is trivial would be bitwise copyable (stronger guarantee: it does not
> matter if the destructor is run or not, it doesn't do anything).

....thinking about that example (well, the case of a class containing a
unique_ptr), I'm not sure the *copy* ctor is the relevant one, but
rather it needs a default *move* ctor. (Note "default", not "defaulted";
a ctor may be "default" because it was explicitly "defaulted", or
because it is implicit.)

--=20
Matthew

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

.

<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"" dir=3D"auto"><br c=
lass=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=
=E2=80=9307=E2=80=9331, at 5:34 PM, David Rodr=C3=ADguez Ibeas &lt;<a href=
=3D"mailto:dibeas@ieee.org" class=3D"">dibeas@ieee.org</a>&gt; wrote:</div>=
<br class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" cl=
ass=3D"">Still, before arguing about the rules that a compiler could use to=
 implicitly mark a type as relocatable we would need to have the feature in=
 the language.&nbsp; Pablo's papers (specifically N4158) aim to get that, w=
e shall see how it fares/fared in the committee.</div></div></blockquote></=
div><br class=3D""><div class=3D"">The committee agreed that the destructiv=
e moves are useful but they were against adding complexity to destruction, =
or alternative means of destruction besides destructors. The subsequent pap=
er, N4393 <i class=3D"">Noop Constructors and Destructors</i>, is not marke=
d as a revision of N4158. It addresses only the troublesome aspect of destr=
uctive moving, and also covers some new territory in obtaining objects from=
 (e.g. deserialized) object representation.</div><div class=3D""><br class=
=3D""></div><div class=3D"">I=E2=80=99ve&nbsp;<a href=3D"https://github.com=
/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4b89f4b7e8dc7/cxx_func=
tion.hpp#L415" class=3D"">worked</a>&nbsp;<a href=3D"https://github.com/pot=
swa/cxx_function/blob/6de095a2a190fcc202bd55650ca4b89f4b7e8dc7/cxx_function=
..hpp#L706">around</a>&nbsp;the issue. I think destructive move should still=
 work if the class has nontrivially-destructible members: in the case of <f=
ont face=3D"Courier" class=3D"">std::list</font>, the embedded allocator an=
d the potentially fancy <font face=3D"Courier" class=3D"">allocator_type::p=
ointer</font> objects. What=E2=80=99s really needed is to eliminate the <i =
class=3D"">body</i>&nbsp;of the destructor while keeping the destruction of=
 members intact. This is a finer point and the solution can be less sledgeh=
ammer-ish. For example=E2=80=A6</div><div class=3D""><br class=3D""></div><=
div class=3D"">Bless destructor calls on base subobjects, when the base con=
tains all the nonstatic members of the most-derived object, to end the most=
-derived object=E2=80=99s lifetime. Such destructor invocation is already w=
ell-formed ([class.dtor] =C2=A712.4/13), and once you=E2=80=99ve done such =
a thing, you=E2=80=99re not allowed to regenerate the base subobject nor to=
 call the derived destructor. So, sanitizers shouldn=E2=80=99t need to chan=
ge much. For something like <font face=3D"Courier" class=3D"">std::list</fo=
nt>, the base will usually but not necessarily be trivially destructible. E=
ven when nontrivial, there may still be a win.</div><div class=3D""><br></d=
iv><div class=3D"">For a generic mechanism, define a type trait <font face=
=3D"Courier">destructive_move_base_of</font> (perhaps auto-populated by a m=
ember typedef, defaulting to the derived class). Let&nbsp;<span style=3D"fo=
nt-family: Courier;">uninitialized_destructive_move</span>&nbsp;construct t=
he new object by passing a base reference to the old object; for a triviall=
y-movable base it should do nothing more than <font face=3D"Courier">memcpy=
</font>. Then it destroys the old object through the same base class refere=
nce; for a trivially-destructible base this is a no-op.</div><div class=3D"=
"><br class=3D""></div><div class=3D"">Ville, you=E2=80=99re the resident d=
estructor connoisseur=E2=80=A6 what do you think?</div><div class=3D""><br>=
</div></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 />

.

------=_Part_32_1589783630.1438362058695
Content-Type: multipart/alternative;
 boundary="----=_Part_33_1681908692.1438362058696"

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

I also cannot think of a situation where the implicit-or-defaulted copy=20
constructor criterion would not on its own be sufficient. It may in fact be=
=20
sufficient.

I mostly added "destructor" out of caution, and because Thiago included=20
this criterion in a previous exchange. In that case, the conversation went=
=20
like this:


> Hmm... interesting. You're saying that an aggregate with
> public, implicit copy constructors and destructors
> (though not necessarily trivial) should automatically be
> marked movable if it is composed only of movable
> sub-objects? Makes sense.


I thought Thiago could think of cases that would require the destructor=20
criterion also.

However, I can't actually think of a case where the copy constructor=20
criterion alone would not be sufficient.


On Friday, July 31, 2015 at 3:19:41 AM UTC-6, David Rodr=C3=ADguez Ibeas wr=
ote:

> I am not sure that Denis' rules are sufficient, but note that (3) refers=
=20
> to a trivial or *defaulted* copy-constructor.  A defaulted copy construct=
or=20
> may not be trivial and (3) is aiming to extend the inferred=20
> "relocatability" to those.  Since all trivial copy-constructors are=20
> implicitly defined, we can rewrite that in a, possibly, less misleading w=
ay=20
> as:
>
> (3) has an implicitly defined or defaulted copy constructor and destructo=
r.
>
> I am not sure whether the rules are sufficient but it probably is. Rule 3=
=20
> is clearly necessary as if a type is [potentially, consider the NullObjec=
t=20
> pattern] self-referencing the copy-constructor would have to handle that=
=20
> case and cannot be compiler defined.  The members themselves cannot be=20
> self-referencing as that would make them not relocatable and break rule 2=
,=20
> so the compiler generated copy constructor cannot "fix" the=20
> self-references, if any. =20
>
> I am not sure whether the destructor need be "defaulted" or not, I believ=
e=20
> this is not necessary. The compiler can be non-trivial, which is the whol=
e=20
> point of the exercise. A 'unique_ptr' is clearly relocatable and has a=20
> non-trivial destructor. In general, a "relocatable" type whose destructor=
=20
> is trivial would be bitwise copyable (stronger guarantee: it does not=20
> matter if the destructor is run or not, it doesn't do anything).=20
>
> So the question is: what could possibly be added to a destructor body in=
=20
> the complete object to make it not relocatable? And I believe the answer =
to=20
> be: nothing that would not have forced the user to define a=20
> copy-constructor.
>
>     David
>
>
>
>
> On Fri, Jul 31, 2015 at 9:33 AM, Thiago Macieira <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> On Thursday 30 July 2015 23:11:22 denis bider wrote:
>> > (1) not explicitly marked relocatable (nor marked not-relocatable);
>> >
>> > (2) with members and bases that are all relocatable;
>> >
>> > (3) that has a trivial or defaulted copy constructor and destructor;
>>
>> #3 alone is enough. A class with a trivial copy constructor and a trivia=
l
>> destructor can already be optimised.
>>
>> The attribute is not needed for those cases.
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>       PGP/GPG: 0x6EF45358; fingerprint:
>>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

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

<div dir=3D"ltr"><div>I also cannot think of a=C2=A0situation where the imp=
licit-or-defaulted copy constructor criterion would not on its own be suffi=
cient. It may in fact be sufficient.</div><div><br></div><div>I mostly adde=
d &quot;destructor&quot; out of caution, and because Thiago included this c=
riterion in a previous exchange. In that case, the conversation went like t=
his:</div><div><br></div><div><br></div><div>&gt; Hmm... interesting. You&#=
39;re saying that an aggregate with</div><div>&gt; public, implicit copy co=
nstructors and destructors</div><div>&gt; (though not necessarily trivial) =
should automatically be</div><div>&gt; marked=C2=A0movable if it is compose=
d only of movable</div><div>&gt; sub-objects? Makes sense.<br></div><div><b=
r></div><div><br></div><div>I thought Thiago=C2=A0could think of cases=C2=
=A0that would require the destructor criterion also.</div><div><br></div><d=
iv>However,=C2=A0I can&#39;t actually think of a case where the copy constr=
uctor criterion alone would not be sufficient.</div><div><br><br>On Friday,=
 July 31, 2015 at 3:19:41 AM UTC-6, David Rodr=C3=ADguez Ibeas wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr">I am not sure that Denis&#39;=
 rules are sufficient, but note that (3) refers to a trivial or *defaulted*=
 copy-constructor.=C2=A0 A defaulted copy constructor may not be trivial an=
d (3) is aiming to extend the inferred &quot;relocatability&quot; to those.=
=C2=A0 Since all trivial copy-constructors are implicitly defined, we can r=
ewrite that in a, possibly, less misleading way as:<br><br>(3) has an impli=
citly defined or defaulted copy constructor and destructor.<br><br>I am not=
 sure whether the rules are sufficient but it probably is. Rule 3 is clearl=
y necessary as if a type is [potentially, consider the NullObject pattern] =
self-referencing the copy-constructor would have to handle that case and ca=
nnot be compiler defined.=C2=A0 The members themselves cannot be self-refer=
encing as that would make them not relocatable and break rule 2, so the com=
piler generated copy constructor cannot &quot;fix&quot; the self-references=
, if any. =C2=A0<br><br>I am not sure whether the destructor need be &quot;=
defaulted&quot; or not, I believe this is not necessary. The compiler can b=
e non-trivial, which is the whole point of the exercise. A &#39;unique_ptr&=
#39; is clearly relocatable and has a non-trivial destructor. In general, a=
 &quot;relocatable&quot; type whose destructor is trivial would be bitwise =
copyable (stronger guarantee: it does not matter if the destructor is run o=
r not, it doesn&#39;t do anything). <br><br>So the question is: what could =
possibly be added to a destructor body in the complete object to make it no=
t relocatable? And I believe the answer to be: nothing that would not have =
forced the user to define a copy-constructor.<br><br>=C2=A0 =C2=A0 David<br=
><br><br><br></div><div><br><div class=3D"gmail_quote">On Fri, Jul 31, 2015=
 at 9:33 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nof=
ollow" gdf-obfuscated-mailto=3D"Pod0rAKbDgAJ">thi...@macieira.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><span>On Thursday 30 July 2015=
 23:11:22 denis bider wrote:<br>
&gt; (1) not explicitly marked relocatable (nor marked not-relocatable);<br=
>
&gt;<br>
&gt; (2) with members and bases that are all relocatable;<br>
&gt;<br>
&gt; (3) that has a trivial or defaulted copy constructor and destructor;<b=
r>
<br>
</span>#3 alone is enough. A class with a trivial copy constructor and a tr=
ivial<br>
destructor can already be optimised.<br>
<br>
The attribute is not needed for those cases.<br>
<span><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" hr=
ef=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira.inf=
o</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_J=
YG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http://w=
ww.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" href=3D"http://kde.org" =
target=3D"_blank" rel=3D"nofollow">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div><div><br>
--<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 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Pod0rAKbDgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"Pod0rAKbDgAJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a onmousedown=3D"this.href=3D&#39;http://groups.google=
..com/a/isocpp.org/group/std-proposals/&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;=
return true;" href=3D"http://groups.google.com/a/isocpp.org/group/std-propo=
sals/" target=3D"_blank" rel=3D"nofollow">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></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_33_1681908692.1438362058696--
------=_Part_32_1589783630.1438362058695--

.

------=_Part_23_81886774.1438362423119
Content-Type: multipart/alternative;
 boundary="----=_Part_24_2067155838.1438362423120"

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

Honestly - approaching destructive move from that angle seems more like a=
=20
workaround for the committee's inflexibility, than the most obvious way one=
=20
would have chosen to implement this, given freedom. :-/

It truly seems unfortunate if the committee prefers to force libraries and=
=20
users to rely on undefined behavior, instead of defining it.

The inability of the language to move things, when all of the underlying=20
platforms can, should be seen as a defect, not a feature.


On Friday, July 31, 2015 at 7:47:29 AM UTC-6, David Krauss wrote:

>
> On 2015=E2=80=9307=E2=80=9331, at 5:34 PM, David Rodr=C3=ADguez Ibeas <di=
b...@ieee.org=20
> <javascript:>> wrote:
>
> Still, before arguing about the rules that a compiler could use to=20
> implicitly mark a type as relocatable we would need to have the feature i=
n=20
> the language.  Pablo's papers (specifically N4158) aim to get that, we=20
> shall see how it fares/fared in the committee.
>
>
> The committee agreed that the destructive moves are useful but they were=
=20
> against adding complexity to destruction, or alternative means of=20
> destruction besides destructors. The subsequent paper, N4393 *Noop=20
> Constructors and Destructors*, is not marked as a revision of N4158. It=
=20
> addresses only the troublesome aspect of destructive moving, and also=20
> covers some new territory in obtaining objects from (e.g. deserialized)=
=20
> object representation.
>
> I=E2=80=99ve worked=20
> <https://github.com/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4=
b89f4b7e8dc7/cxx_function.hpp#L415>
>  around=20
> <https://github.com/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4=
b89f4b7e8dc7/cxx_function.hpp#L706> the=20
> issue. I think destructive move should still work if the class has=20
> nontrivially-destructible members: in the case of std::list, the embedded=
=20
> allocator and the potentially fancy allocator_type::pointer objects.=20
> What=E2=80=99s really needed is to eliminate the *body* of the destructor=
 while=20
> keeping the destruction of members intact. This is a finer point and the=
=20
> solution can be less sledgehammer-ish. For example=E2=80=A6
>
> Bless destructor calls on base subobjects, when the base contains all the=
=20
> nonstatic members of the most-derived object, to end the most-derived=20
> object=E2=80=99s lifetime. Such destructor invocation is already well-for=
med=20
> ([class.dtor] =C2=A712.4/13), and once you=E2=80=99ve done such a thing, =
you=E2=80=99re not=20
> allowed to regenerate the base subobject nor to call the derived=20
> destructor. So, sanitizers shouldn=E2=80=99t need to change much. For som=
ething=20
> like std::list, the base will usually but not necessarily be trivially=20
> destructible. Even when nontrivial, there may still be a win.
>
> For a generic mechanism, define a type trait destructive_move_base_of=20
> (perhaps auto-populated by a member typedef, defaulting to the derived=20
> class). Let uninitialized_destructive_move construct the new object by=20
> passing a base reference to the old object; for a trivially-movable base =
it=20
> should do nothing more than memcpy. Then it destroys the old object=20
> through the same base class reference; for a trivially-destructible base=
=20
> this is a no-op.
>
> Ville, you=E2=80=99re the resident destructor connoisseur=E2=80=A6 what d=
o you think?
>
>

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

<div dir=3D"ltr"><div>Honestly -=C2=A0approaching=C2=A0destructive move fro=
m that angle seems more=C2=A0like a workaround for the committee&#39;s infl=
exibility, than=C2=A0the most=C2=A0obvious way one would have chosen to imp=
lement this, given freedom. :-/</div><div><br></div><div>It truly seems unf=
ortunate if the committee prefers to force libraries and users to rely on u=
ndefined behavior, instead of defining it.</div><div><br></div><div>The ina=
bility of the language to move things, when all of the underlying platforms=
 can, should be seen as a defect, not a feature.</div><div><br></div><div><=
br>On Friday, July 31, 2015 at 7:47:29 AM UTC-6, David Krauss wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;"><div style=3D"-ms-word-wrap: break-word;" dir=
=3D"auto"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=80=
=9331, at 5:34 PM, David Rodr=C3=ADguez Ibeas &lt;<a onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofo=
llow" gdf-obfuscated-mailto=3D"2vcXqZ-pDgAJ">dib...@ieee.org</a>&gt; wrote:=
</div><br><div><div dir=3D"ltr">Still, before arguing about the rules that =
a compiler could use to implicitly mark a type as relocatable we would need=
 to have the feature in the language.=C2=A0 Pablo&#39;s papers (specificall=
y N4158) aim to get that, we shall see how it fares/fared in the committee.=
</div></div></blockquote></div><br><div>The committee agreed that the destr=
uctive moves are useful but they were against adding complexity to destruct=
ion, or alternative means of destruction besides destructors. The subsequen=
t paper, N4393 <i>Noop Constructors and Destructors</i>, is not marked as a=
 revision of N4158. It addresses only the troublesome aspect of destructive=
 moving, and also covers some new territory in obtaining objects from (e.g.=
 deserialized) object representation.</div><div><br></div><div>I=E2=80=99ve=
=C2=A0<a onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75htt=
ps%3A%2F%2Fgithub.com%2Fpotswa%2Fcxx_function%2Fblob%2F6de095a2a190fcc202bd=
55650ca4b89f4b7e8dc7%2Fcxx_function.hpp%23L415\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNESli6eOjaZOwnOnEtXuIl5ziuk3g&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fpotswa%2F=
cxx_function%2Fblob%2F6de095a2a190fcc202bd55650ca4b89f4b7e8dc7%2Fcxx_functi=
on.hpp%23L415\46sa\75D\46sntz\0751\46usg\75AFQjCNESli6eOjaZOwnOnEtXuIl5ziuk=
3g&#39;;return true;" href=3D"https://github.com/potswa/cxx_function/blob/6=
de095a2a190fcc202bd55650ca4b89f4b7e8dc7/cxx_function.hpp#L415" target=3D"_b=
lank" rel=3D"nofollow">worked</a>=C2=A0<a onmousedown=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fpotswa%2Fcxx_funct=
ion%2Fblob%2F6de095a2a190fcc202bd55650ca4b89f4b7e8dc7%2Fcxx_function.hpp%23=
L706\46sa\75D\46sntz\0751\46usg\75AFQjCNEmb7F98id90deMdR5tuPx_BZgx7Q&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75htt=
ps%3A%2F%2Fgithub.com%2Fpotswa%2Fcxx_function%2Fblob%2F6de095a2a190fcc202bd=
55650ca4b89f4b7e8dc7%2Fcxx_function.hpp%23L706\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEmb7F98id90deMdR5tuPx_BZgx7Q&#39;;return true;" href=3D"https://gith=
ub.com/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4b89f4b7e8dc7/cx=
x_function.hpp#L706" target=3D"_blank" rel=3D"nofollow">around</a>=C2=A0the=
 issue. I think destructive move should still work if the class has nontriv=
ially-destructible members: in the case of <font face=3D"Courier">std::list=
</font>, the embedded allocator and the potentially fancy <font face=3D"Cou=
rier">allocator_type::pointer</font> objects. What=E2=80=99s really needed =
is to eliminate the <i>body</i>=C2=A0of the destructor while keeping the de=
struction of members intact. This is a finer point and the solution can be =
less sledgehammer-ish. For example=E2=80=A6</div><div><br></div><div>Bless =
destructor calls on base subobjects, when the base contains all the nonstat=
ic members of the most-derived object, to end the most-derived object=E2=80=
=99s lifetime. Such destructor invocation is already well-formed ([class.dt=
or] =C2=A712.4/13), and once you=E2=80=99ve done such a thing, you=E2=80=99=
re not allowed to regenerate the base subobject nor to call the derived des=
tructor. So, sanitizers shouldn=E2=80=99t need to change much. For somethin=
g like <font face=3D"Courier">std::list</font>, the base will usually but n=
ot necessarily be trivially destructible. Even when nontrivial, there may s=
till be a win.</div><div><br></div><div>For a generic mechanism, define a t=
ype trait <font face=3D"Courier">destructive_move_base_of</font> (perhaps a=
uto-populated by a member typedef, defaulting to the derived class). Let=C2=
=A0<span style=3D"font-family: Courier;">uninitialized_destructive_<wbr>mov=
e</span>=C2=A0construct the new object by passing a base reference to the o=
ld object; for a trivially-movable base it should do nothing more than <fon=
t face=3D"Courier">memcpy</font>. Then it destroys the old object through t=
he same base class reference; for a trivially-destructible base this is a n=
o-op.</div><div><br></div><div>Ville, you=E2=80=99re the resident destructo=
r connoisseur=E2=80=A6 what do you think?</div><div><br></div></div></block=
quote></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_24_2067155838.1438362423120--
------=_Part_23_81886774.1438362423119--

.

------=_Part_37_377750488.1438363088488
Content-Type: multipart/alternative;
 boundary="----=_Part_38_1329582403.1438363088488"

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

Perhaps there would be more success if we stop focusing on the=20
"destructive" aspect of this.

"Destructive move" is a language fiction, and possibly an=20
inappropriate language fiction.

What we're talking about is not destroying an object at one address, and=20
recreating it at another address using memcpy.

What we are *really* talking about is the object *continuing* its lifetime=
=20
at the new address.

This does not involve destruction. Nothing is being destroyed.


On Friday, July 31, 2015 at 7:47:29 AM UTC-6, David Krauss wrote:

>
> On 2015=E2=80=9307=E2=80=9331, at 5:34 PM, David Rodr=C3=ADguez Ibeas <di=
b...@ieee.org=20
> <javascript:>> wrote:
>
> Still, before arguing about the rules that a compiler could use to=20
> implicitly mark a type as relocatable we would need to have the feature i=
n=20
> the language.  Pablo's papers (specifically N4158) aim to get that, we=20
> shall see how it fares/fared in the committee.
>
>
> The committee agreed that the destructive moves are useful but they were=
=20
> against adding complexity to destruction, or alternative means of=20
> destruction besides destructors. The subsequent paper, N4393 *Noop=20
> Constructors and Destructors*, is not marked as a revision of N4158. It=
=20
> addresses only the troublesome aspect of destructive moving, and also=20
> covers some new territory in obtaining objects from (e.g. deserialized)=
=20
> object representation.
>
> I=E2=80=99ve worked=20
> <https://github.com/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4=
b89f4b7e8dc7/cxx_function.hpp#L415>
>  around=20
> <https://github.com/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4=
b89f4b7e8dc7/cxx_function.hpp#L706> the=20
> issue. I think destructive move should still work if the class has=20
> nontrivially-destructible members: in the case of std::list, the embedded=
=20
> allocator and the potentially fancy allocator_type::pointer objects.=20
> What=E2=80=99s really needed is to eliminate the *body* of the destructor=
 while=20
> keeping the destruction of members intact. This is a finer point and the=
=20
> solution can be less sledgehammer-ish. For example=E2=80=A6
>
> Bless destructor calls on base subobjects, when the base contains all the=
=20
> nonstatic members of the most-derived object, to end the most-derived=20
> object=E2=80=99s lifetime. Such destructor invocation is already well-for=
med=20
> ([class.dtor] =C2=A712.4/13), and once you=E2=80=99ve done such a thing, =
you=E2=80=99re not=20
> allowed to regenerate the base subobject nor to call the derived=20
> destructor. So, sanitizers shouldn=E2=80=99t need to change much. For som=
ething=20
> like std::list, the base will usually but not necessarily be trivially=20
> destructible. Even when nontrivial, there may still be a win.
>
> For a generic mechanism, define a type trait destructive_move_base_of=20
> (perhaps auto-populated by a member typedef, defaulting to the derived=20
> class). Let uninitialized_destructive_move construct the new object by=20
> passing a base reference to the old object; for a trivially-movable base =
it=20
> should do nothing more than memcpy. Then it destroys the old object=20
> through the same base class reference; for a trivially-destructible base=
=20
> this is a no-op.
>
> Ville, you=E2=80=99re the resident destructor connoisseur=E2=80=A6 what d=
o you think?
>
>

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

<div dir=3D"ltr"><div>Perhaps there would be more success if we stop focusi=
ng on the &quot;destructive&quot; aspect of this.</div><div><br></div><div>=
&quot;Destructive move&quot; is a language fiction, and possibly an inappro=
priate=C2=A0language fiction.</div><div><br></div><div>What we&#39;re talki=
ng about is not destroying an object at one address, and recreating it at a=
nother address using memcpy.</div><div><br></div><div>What we are <em>reall=
y</em> talking about is the object <em>continuing</em> its lifetime at the =
new address.</div><div><br></div><div>This does not involve destruction. No=
thing is being destroyed.</div><div><br><br>On Friday, July 31, 2015 at 7:4=
7:29 AM UTC-6, David Krauss wrote:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div s=
tyle=3D"-ms-word-wrap: break-word;" dir=3D"auto"><br><div><blockquote type=
=3D"cite"><div>On 2015=E2=80=9307=E2=80=9331, at 5:34 PM, David Rodr=C3=ADg=
uez Ibeas &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"jav=
ascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"2vcXq=
Z-pDgAJ">dib...@ieee.org</a>&gt; wrote:</div><br><div><div dir=3D"ltr">Stil=
l, before arguing about the rules that a compiler could use to implicitly m=
ark a type as relocatable we would need to have the feature in the language=
..=C2=A0 Pablo&#39;s papers (specifically N4158) aim to get that, we shall s=
ee how it fares/fared in the committee.</div></div></blockquote></div><br><=
div>The committee agreed that the destructive moves are useful but they wer=
e against adding complexity to destruction, or alternative means of destruc=
tion besides destructors. The subsequent paper, N4393 <i>Noop Constructors =
and Destructors</i>, is not marked as a revision of N4158. It addresses onl=
y the troublesome aspect of destructive moving, and also covers some new te=
rritory in obtaining objects from (e.g. deserialized) object representation=
..</div><div><br></div><div>I=E2=80=99ve=C2=A0<a onmousedown=3D"this.href=3D=
&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fpotswa%2Fcxx=
_function%2Fblob%2F6de095a2a190fcc202bd55650ca4b89f4b7e8dc7%2Fcxx_function.=
hpp%23L415\46sa\75D\46sntz\0751\46usg\75AFQjCNESli6eOjaZOwnOnEtXuIl5ziuk3g&=
#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q=
\75https%3A%2F%2Fgithub.com%2Fpotswa%2Fcxx_function%2Fblob%2F6de095a2a190fc=
c202bd55650ca4b89f4b7e8dc7%2Fcxx_function.hpp%23L415\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNESli6eOjaZOwnOnEtXuIl5ziuk3g&#39;;return true;" href=3D"https:=
//github.com/potswa/cxx_function/blob/6de095a2a190fcc202bd55650ca4b89f4b7e8=
dc7/cxx_function.hpp#L415" target=3D"_blank" rel=3D"nofollow">worked</a>=C2=
=A0<a onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%=
3A%2F%2Fgithub.com%2Fpotswa%2Fcxx_function%2Fblob%2F6de095a2a190fcc202bd556=
50ca4b89f4b7e8dc7%2Fcxx_function.hpp%23L706\46sa\75D\46sntz\0751\46usg\75AF=
QjCNEmb7F98id90deMdR5tuPx_BZgx7Q&#39;;return true;" onclick=3D"this.href=3D=
&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fpotswa%2Fcxx=
_function%2Fblob%2F6de095a2a190fcc202bd55650ca4b89f4b7e8dc7%2Fcxx_function.=
hpp%23L706\46sa\75D\46sntz\0751\46usg\75AFQjCNEmb7F98id90deMdR5tuPx_BZgx7Q&=
#39;;return true;" href=3D"https://github.com/potswa/cxx_function/blob/6de0=
95a2a190fcc202bd55650ca4b89f4b7e8dc7/cxx_function.hpp#L706" target=3D"_blan=
k" rel=3D"nofollow">around</a>=C2=A0the issue. I think destructive move sho=
uld still work if the class has nontrivially-destructible members: in the c=
ase of <font face=3D"Courier">std::list</font>, the embedded allocator and =
the potentially fancy <font face=3D"Courier">allocator_type::pointer</font>=
 objects. What=E2=80=99s really needed is to eliminate the <i>body</i>=C2=
=A0of the destructor while keeping the destruction of members intact. This =
is a finer point and the solution can be less sledgehammer-ish. For example=
=E2=80=A6</div><div><br></div><div>Bless destructor calls on base subobject=
s, when the base contains all the nonstatic members of the most-derived obj=
ect, to end the most-derived object=E2=80=99s lifetime. Such destructor inv=
ocation is already well-formed ([class.dtor] =C2=A712.4/13), and once you=
=E2=80=99ve done such a thing, you=E2=80=99re not allowed to regenerate the=
 base subobject nor to call the derived destructor. So, sanitizers shouldn=
=E2=80=99t need to change much. For something like <font face=3D"Courier">s=
td::list</font>, the base will usually but not necessarily be trivially des=
tructible. Even when nontrivial, there may still be a win.</div><div><br></=
div><div>For a generic mechanism, define a type trait <font face=3D"Courier=
">destructive_move_base_of</font> (perhaps auto-populated by a member typed=
ef, defaulting to the derived class). Let=C2=A0<span style=3D"font-family: =
Courier;">uninitialized_destructive_<wbr>move</span>=C2=A0construct the new=
 object by passing a base reference to the old object; for a trivially-mova=
ble base it should do nothing more than <font face=3D"Courier">memcpy</font=
>. Then it destroys the old object through the same base class reference; f=
or a trivially-destructible base this is a no-op.</div><div><br></div><div>=
Ville, you=E2=80=99re the resident destructor connoisseur=E2=80=A6 what do =
you think?</div><div><br></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_38_1329582403.1438363088488--
------=_Part_37_377750488.1438363088488--

.

On 31 July 2015 at 20:07, denis bider <isocppgroup@denisbider.com> wrote:
> Honestly - approaching destructive move from that angle seems more like a
> workaround for the committee's inflexibility, than the most obvious way o=
ne
> would have chosen to implement this, given freedom. :-/
>
> It truly seems unfortunate if the committee prefers to force libraries an=
d
> users to rely on undefined behavior, instead of defining it.
>
> The inability of the language to move things, when all of the underlying
> platforms can, should be seen as a defect, not a feature.

Huh? What do you mean by "inability of the language to move things when
all of the underlying platforms can"? It's never been a question about
"being able to move", it's always been a question of how the lifetime
of an object can be ended.


> On Friday, July 31, 2015 at 7:47:29 AM UTC-6, David Krauss wrote:
>> Bless destructor calls on base subobjects, when the base contains all th=
e
>> nonstatic members of the most-derived object, to end the most-derived
>> object=E2=80=99s lifetime. Such destructor invocation is already well-fo=
rmed
>> ([class.dtor] =C2=A712.4/13), and once you=E2=80=99ve done such a thing,=
 you=E2=80=99re not
>> allowed to regenerate the base subobject nor to call the derived destruc=
tor.
>> So, sanitizers shouldn=E2=80=99t need to change much. For something like=
 std::list,
>> the base will usually but not necessarily be trivially destructible. Eve=
n
>> when nontrivial, there may still be a win.

I presume this also requires that the destructor of the derived type is
trivial purely from the point of view of the derived type, aka is not
user-provided.

>> For a generic mechanism, define a type trait destructive_move_base_of
>> (perhaps auto-populated by a member typedef, defaulting to the derived
>> class). Let uninitialized_destructive_move construct the new object by
>> passing a base reference to the old object; for a trivially-movable base=
 it
>> should do nothing more than memcpy. Then it destroys the old object thro=
ugh
>> the same base class reference; for a trivially-destructible base this is=
 a
>> no-op.
>> Ville, you=E2=80=99re the resident destructor connoisseur=E2=80=A6 what =
do you think?

I wonder what use cases we are really trying to support here, as the latest
discussion about destructive move suggested that it might be necessary at
all for the use cases enumerated in that paper.

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

.

On 31 July 2015 at 20:18, denis bider <isocppgroup@denisbider.com> wrote:
> Perhaps there would be more success if we stop focusing on the "destructive"
> aspect of this.
>
> "Destructive move" is a language fiction, and possibly an inappropriate
> language fiction.
>
> What we're talking about is not destroying an object at one address, and
> recreating it at another address using memcpy.
>
> What we are really talking about is the object continuing its lifetime at
> the new address.
>
> This does not involve destruction. Nothing is being destroyed.


Perhaps so, but the lifetime of the object at the old address is
supposed to end,
that object's type does not have a trivial destructor, and that
destructor is not called.
That is a fairly intrusive change to the lifetime rules of C++.

--

---
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_68_1938553712.1438363666596
Content-Type: multipart/alternative;
 boundary="----=_Part_69_1166859506.1438363666596"

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

> Perhaps so, but the lifetime of the object at the old address
> is supposed to end, that object's type does not have a
> trivial destructor, and that destructor is not called.


But the lifetime of the object is *not* being ended.

Given that the committee has frowned on trivially_destructive_movable, on=
=20
the basis that it complicates the concept of destruction, I think the=20
proper way to progress would be to instead request that the language=20
recognize that *some* objects can be moved around, and that this does not=
=20
involve destruction.


On Friday, July 31, 2015 at 11:23:07 AM UTC-6, Ville Voutilainen wrote:

> On 31 July 2015 at 20:07, denis bider <isocp...@denisbider.com=20
> <javascript:>> wrote:=20
> > Honestly - approaching destructive move from that angle seems more like=
=20
> a=20
> > workaround for the committee's inflexibility, than the most obvious way=
=20
> one=20
> > would have chosen to implement this, given freedom. :-/=20
> >=20
> > It truly seems unfortunate if the committee prefers to force libraries=
=20
> and=20
> > users to rely on undefined behavior, instead of defining it.=20
> >=20
> > The inability of the language to move things, when all of the underlyin=
g=20
> > platforms can, should be seen as a defect, not a feature.=20
>
> Huh? What do you mean by "inability of the language to move things when=
=20
> all of the underlying platforms can"? It's never been a question about=20
> "being able to move", it's always been a question of how the lifetime=20
> of an object can be ended.=20
>
>
> > On Friday, July 31, 2015 at 7:47:29 AM UTC-6, David Krauss wrote:=20
> >> Bless destructor calls on base subobjects, when the base contains all=
=20
> the=20
> >> nonstatic members of the most-derived object, to end the most-derived=
=20
> >> object=E2=80=99s lifetime. Such destructor invocation is already well-=
formed=20
> >> ([class.dtor] =C2=A712.4/13), and once you=E2=80=99ve done such a thin=
g, you=E2=80=99re not=20
> >> allowed to regenerate the base subobject nor to call the derived=20
> destructor.=20
> >> So, sanitizers shouldn=E2=80=99t need to change much. For something li=
ke=20
> std::list,=20
> >> the base will usually but not necessarily be trivially destructible.=
=20
> Even=20
> >> when nontrivial, there may still be a win.=20
>
> I presume this also requires that the destructor of the derived type is=
=20
> trivial purely from the point of view of the derived type, aka is not=20
> user-provided.=20
>
> >> For a generic mechanism, define a type trait destructive_move_base_of=
=20
> >> (perhaps auto-populated by a member typedef, defaulting to the derived=
=20
> >> class). Let uninitialized_destructive_move construct the new object by=
=20
> >> passing a base reference to the old object; for a trivially-movable=20
> base it=20
> >> should do nothing more than memcpy. Then it destroys the old object=20
> through=20
> >> the same base class reference; for a trivially-destructible base this=
=20
> is a=20
> >> no-op.=20
> >> Ville, you=E2=80=99re the resident destructor connoisseur=E2=80=A6 wha=
t do you think?=20
>
> I wonder what use cases we are really trying to support here, as the=20
> latest=20
> discussion about destructive move suggested that it might be necessary at=
=20
> all for the use cases enumerated in that paper.=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_69_1166859506.1438363666596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; Perhaps so, but the lifetime of the object at th=
e old address</div><div>&gt; is supposed to end, that object&#39;s type doe=
s not have a</div><div>&gt; trivial destructor, and that destructor is not =
called.</div><div><br></div><div><br></div><div>But the lifetime of the obj=
ect is <em>not</em> being ended.</div><div><br></div><div>Given that the co=
mmittee has frowned on=C2=A0trivially_destructive_movable,=C2=A0on the basi=
s that it complicates the concept of destruction, I think the proper way to=
 progress would be to instead request that the language recognize that <em>=
some</em> objects can be moved around, and that this does not involve destr=
uction.</div><div><br><br>On Friday, July 31, 2015 at 11:23:07 AM UTC-6, Vi=
lle Voutilainen wrote:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">On 31 July 2015 at=
 20:07, denis bider &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;=
;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" h=
ref=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailt=
o=3D"uPFYFWS1DgAJ">isocp...@denisbider.com</a>&gt; wrote:
<br>&gt; Honestly - approaching destructive move from that angle seems more=
 like a
<br>&gt; workaround for the committee&#39;s inflexibility, than the most ob=
vious way one
<br>&gt; would have chosen to implement this, given freedom. :-/
<br>&gt;
<br>&gt; It truly seems unfortunate if the committee prefers to force libra=
ries and
<br>&gt; users to rely on undefined behavior, instead of defining it.
<br>&gt;
<br>&gt; The inability of the language to move things, when all of the unde=
rlying
<br>&gt; platforms can, should be seen as a defect, not a feature.
<br>
<br>Huh? What do you mean by &quot;inability of the language to move things=
 when
<br>all of the underlying platforms can&quot;? It&#39;s never been a questi=
on about
<br>&quot;being able to move&quot;, it&#39;s always been a question of how =
the lifetime
<br>of an object can be ended.
<br>
<br>
<br>&gt; On Friday, July 31, 2015 at 7:47:29 AM UTC-6, David Krauss wrote:
<br>&gt;&gt; Bless destructor calls on base subobjects, when the base conta=
ins all the
<br>&gt;&gt; nonstatic members of the most-derived object, to end the most-=
derived
<br>&gt;&gt; object=E2=80=99s lifetime. Such destructor invocation is alrea=
dy well-formed
<br>&gt;&gt; ([class.dtor] =C2=A712.4/13), and once you=E2=80=99ve done suc=
h a thing, you=E2=80=99re not
<br>&gt;&gt; allowed to regenerate the base subobject nor to call the deriv=
ed destructor.
<br>&gt;&gt; So, sanitizers shouldn=E2=80=99t need to change much. For some=
thing like std::list,
<br>&gt;&gt; the base will usually but not necessarily be trivially destruc=
tible. Even
<br>&gt;&gt; when nontrivial, there may still be a win.
<br>
<br>I presume this also requires that the destructor of the derived type is
<br>trivial purely from the point of view of the derived type, aka is not
<br>user-provided.
<br>
<br>&gt;&gt; For a generic mechanism, define a type trait destructive_move_=
base_of
<br>&gt;&gt; (perhaps auto-populated by a member typedef, defaulting to the=
 derived
<br>&gt;&gt; class). Let uninitialized_destructive_move construct the new o=
bject by
<br>&gt;&gt; passing a base reference to the old object; for a trivially-mo=
vable base it
<br>&gt;&gt; should do nothing more than memcpy. Then it destroys the old o=
bject through
<br>&gt;&gt; the same base class reference; for a trivially-destructible ba=
se this is a
<br>&gt;&gt; no-op.
<br>&gt;&gt; Ville, you=E2=80=99re the resident destructor connoisseur=E2=
=80=A6 what do you think?
<br>
<br>I wonder what use cases we are really trying to support here, as the la=
test
<br>discussion about destructive move suggested that it might be necessary =
at
<br>all for the use cases enumerated in that paper.
<br></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_69_1166859506.1438363666596--
------=_Part_68_1938553712.1438363666596--

.

On 31 July 2015 at 20:27, denis bider <isocppgroup@denisbider.com> wrote:
>> Perhaps so, but the lifetime of the object at the old address
>> is supposed to end, that object's type does not have a
>> trivial destructor, and that destructor is not called.
>
>
> But the lifetime of the object is not being ended.

In that case I don't know what we're discussing here, and I haven't
been following
this thread.

>
> Given that the committee has frowned on trivially_destructive_movable, on
> the basis that it complicates the concept of destruction, I think the proper
> way to progress would be to instead request that the language recognize that
> some objects can be moved around, and that this does not involve
> destruction.

I have no idea what that means. The language already recognizes that objects
can be moved around, and so does the library.

--

---
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_57_1545978236.1438364226718
Content-Type: multipart/alternative;
 boundary="----=_Part_58_522816509.1438364226718"

------=_Part_58_522816509.1438364226718
Content-Type: text/plain; charset=UTF-8

We are discussing relocatability of objects in memory via memcpy.

The intent is to standardize a concept that's already implemented by a
number of libraries. Containers of such libraries support objects that
declare a library-specific relocatable trait. For objects with this trait
- which turns out to be a large proportion of C++ objects - the library's
containers can then move objects in memory much more efficiently using
memcpy. This makes for e.g. more efficient vector resizing.

Existing move semantics are movement of content between objects, while the
objects themselves remain fixed.

Relocatability, as a language supported trait, would formalize trivially
moving *objects*, as opposed to their *content*.


On Friday, July 31, 2015 at 11:29:33 AM UTC-6, Ville Voutilainen wrote:

> On 31 July 2015 at 20:27, denis bider <isocp...@denisbider.com
> <javascript:>> wrote:
> >> Perhaps so, but the lifetime of the object at the old address
> >> is supposed to end, that object's type does not have a
> >> trivial destructor, and that destructor is not called.
> >
> >
> > But the lifetime of the object is not being ended.
>
> In that case I don't know what we're discussing here, and I haven't
> been following
> this thread.
>
> >
> > Given that the committee has frowned on trivially_destructive_movable,
> on
> > the basis that it complicates the concept of destruction, I think the
> proper
> > way to progress would be to instead request that the language recognize
> that
> > some objects can be moved around, and that this does not involve
> > destruction.
>
> I have no idea what that means. The language already recognizes that
> objects
> can be moved around, and so does the library.
>

--

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

<div dir=3D"ltr"><div>We are discussing relocatability of objects in memory=
 via memcpy.</div><div><br></div><div>The intent is to=C2=A0standardize=C2=
=A0a concept that&#39;s already implemented by a number of libraries.=C2=A0=
Containers=C2=A0of such libraries support=C2=A0objects that declare a libra=
ry-specific relocatable trait. For objects with this trait -=C2=A0which tur=
ns out to be=C2=A0a large proportion of C++ objects - the library&#39;s con=
tainers can then move objects in memory much more efficiently using memcpy.=
 This makes for e.g. more efficient vector resizing.</div><div><br></div><d=
iv>Existing move semantics are movement of content between objects, while t=
he objects themselves remain fixed.</div><div><br></div><div>Relocatability=
, as a language supported trait, would formalize trivially moving <em>objec=
ts</em>, as opposed to their=C2=A0<em>content</em>.</div><div><br><br>On Fr=
iday, July 31, 2015 at 11:29:33 AM UTC-6, Ville Voutilainen wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;">On 31 July 2015 at 20:27, denis bider &lt;<a onmo=
usedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.=
href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=3D"_=
blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"OgnH_721DgAJ">isocp...@den=
isbider.com</a>&gt; wrote:
<br>&gt;&gt; Perhaps so, but the lifetime of the object at the old address
<br>&gt;&gt; is supposed to end, that object&#39;s type does not have a
<br>&gt;&gt; trivial destructor, and that destructor is not called.
<br>&gt;
<br>&gt;
<br>&gt; But the lifetime of the object is not being ended.
<br>
<br>In that case I don&#39;t know what we&#39;re discussing here, and I hav=
en&#39;t
<br>been following
<br>this thread.
<br>
<br>&gt;
<br>&gt; Given that the committee has frowned on trivially_destructive_mova=
ble, on
<br>&gt; the basis that it complicates the concept of destruction, I think =
the proper
<br>&gt; way to progress would be to instead request that the language reco=
gnize that
<br>&gt; some objects can be moved around, and that this does not involve
<br>&gt; destruction.
<br>
<br>I have no idea what that means. The language already recognizes that ob=
jects
<br>can be moved around, and so does the library.
<br></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_58_522816509.1438364226718--
------=_Part_57_1545978236.1438364226718--

.

------=_Part_102_279321088.1438365372132
Content-Type: multipart/alternative;
 boundary="----=_Part_103_693092240.1438365372132"

------=_Part_103_693092240.1438365372132
Content-Type: text/plain; charset=UTF-8

Thinking about this critically, the following seems to be the crux of the
issue:

> the library's containers can then move objects in memory *much more
efficiently*

Maybe this is not true. I don't know.

If it is not true, then we don't need relocatable.

For it to be true, at least one of the following needs to be true:

(1) There have to be realistic scenarios where a contained
class cannot implement is_nothrow_move_constructible and
is_nothrow_destructible, but could implement is_relocatable. In the absence
of is_relocatable, the container has to resort to deep copy, which is an
obvious handbrake.

(2) There have to be realistic scenarios where the performance of move
construction, followed by destruction of left-behind object, is
substantially worse than memcpy. If the object has resources, the
destructor would most likely check whether there are resources to be freed;
find that there aren't any (they have been moved); and the move continues
with the next object. The main cost of this is running unnecessary branch
instructions which may or may not clog the CPU - depending on the CPU's
branch prediction.

I personally don't have situations in my code where (1) is true. To be in
harmony with the spirit of C++ as-is, I've switched all my stuff to nothrow
move constructible and nothrow destructible. That doesn't mean there isn't
code that cannot do this, and would benefit in this case from is_relocatable
..

Situation (2) is one that my code "suffers" from. There's branching
involved in unnecessary object destruction. It may turn out to be that - at
least on *my* target platform - CPU branch prediction is good enough that
the impact of this is trivial. But there may be realistic cases where it's
not trivial, and there may be platforms where it is never trivial.


On Friday, July 31, 2015 at 11:37:06 AM UTC-6, denis bider wrote:

> We are discussing relocatability of objects in memory via memcpy.
>
> The intent is to standardize a concept that's already implemented by a
> number of libraries. Containers of such libraries support objects that
> declare a library-specific relocatable trait. For objects with this trait
> - which turns out to be a large proportion of C++ objects - the library's
> containers can then move objects in memory much more efficiently using
> memcpy. This makes for e.g. more efficient vector resizing.
>
> Existing move semantics are movement of content between objects, while the
> objects themselves remain fixed.
>
> Relocatability, as a language supported trait, would formalize trivially
> moving *objects*, as opposed to their *content*.
>
>
> On Friday, July 31, 2015 at 11:29:33 AM UTC-6, Ville Voutilainen wrote:
>
>> On 31 July 2015 at 20:27, denis bider <isocp...@denisbider.com> wrote:
>> >> Perhaps so, but the lifetime of the object at the old address
>> >> is supposed to end, that object's type does not have a
>> >> trivial destructor, and that destructor is not called.
>> >
>> >
>> > But the lifetime of the object is not being ended.
>>
>> In that case I don't know what we're discussing here, and I haven't
>> been following
>> this thread.
>>
>> >
>> > Given that the committee has frowned on trivially_destructive_movable,
>> on
>> > the basis that it complicates the concept of destruction, I think the
>> proper
>> > way to progress would be to instead request that the language recognize
>> that
>> > some objects can be moved around, and that this does not involve
>> > destruction.
>>
>> I have no idea what that means. The language already recognizes that
>> objects
>> can be moved around, and so does the library.
>>
>

--

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

<div dir=3D"ltr"><div>Thinking about this critically, the following seems t=
o be the crux of the issue:</div><div><br></div><div>&gt; the library&#39;s=
 containers can then move objects in memory <strong>much more efficiently</=
strong></div><div><br></div><div>Maybe this is not true. I don&#39;t know.<=
/div><div><br></div><div>If it is not true, then we don&#39;t need <font fa=
ce=3D"courier new,monospace">relocatable</font>.</div><div><br></div><div>F=
or it to be true, at least one of the following needs to be true:</div><div=
><br></div><div>(1)=C2=A0There have to be realistic scenarios=C2=A0where a =
contained class=C2=A0cannot=C2=A0implement <font face=3D"courier new,monosp=
ace">is_nothrow_move_constructible</font> and <font face=3D"courier new,mon=
ospace">is_nothrow_destructible</font>, but could implement <font face=3D"c=
ourier new,monospace">is_relocatable</font>. In the absence of <font face=
=3D"courier new,monospace">is_relocatable</font>, the container has to reso=
rt to deep copy, which is an obvious handbrake.</div><div><br></div><div>(2=
)=C2=A0There have to be realistic scenarios where the=C2=A0performance of m=
ove construction, followed by destruction of left-behind object, is substan=
tially worse than memcpy. If the object has resources, the destructor would=
 most likely check whether there are resources to be freed; find that there=
 aren&#39;t any (they have been moved); and the move continues with the nex=
t object.=C2=A0The main cost of this is running unnecessary branch instruct=
ions which may or may not clog the CPU -=C2=A0depending on the CPU&#39;s br=
anch prediction.</div><div><br></div><div>I personally don&#39;t have situa=
tions in my code where (1) is true. To be in harmony with the spirit of C++=
 as-is, I&#39;ve switched all my stuff to nothrow move constructible and no=
throw destructible. That doesn&#39;t mean there isn&#39;t code that cannot =
do this, and would benefit in this=C2=A0case from <font face=3D"courier new=
,monospace">is_relocatable</font>.</div><div><br></div><div>Situation (2) i=
s one that my code &quot;suffers&quot; from. There&#39;s branching involved=
 in unnecessary object destruction. It may turn out to be that -=C2=A0at le=
ast on <em>my</em> target platform -=C2=A0CPU branch prediction is good eno=
ugh that the impact of this is trivial. But there may be realistic cases wh=
ere it&#39;s not trivial, and there may be platforms where it is never triv=
ial.</div><div><br><br>On Friday, July 31, 2015 at 11:37:06 AM UTC-6, denis=
 bider wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">We are dis=
cussing relocatability of objects in memory via memcpy.</div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr">The intent is to=C2=A0standardize=C2=A0a conc=
ept that&#39;s already implemented by a number of libraries.=C2=A0Container=
s=C2=A0of such libraries support=C2=A0objects that declare a library-specif=
ic relocatable trait. For objects with this trait -=C2=A0which turns out to=
 be=C2=A0a large proportion of C++ objects - the library&#39;s containers c=
an then move objects in memory much more efficiently using memcpy. This mak=
es for e.g. more efficient vector resizing.</div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr">Existing move semantics are movement of content between o=
bjects, while the objects themselves remain fixed.</div><div dir=3D"ltr"><b=
r></div><div dir=3D"ltr">Relocatability, as a language supported trait, wou=
ld formalize trivially moving <em>objects</em>, as opposed to their=C2=A0<e=
m>content</em>.</div><div dir=3D"ltr"><br><br>On Friday, July 31, 2015 at 1=
1:29:33 AM UTC-6, Ville Voutilainen wrote:</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
" dir=3D"ltr"><div>On 31 July 2015 at 20:27, denis bider &lt;<a rel=3D"nofo=
llow">isocp...@denisbider.com</a>&gt; wrote:
<br>&gt;&gt; Perhaps so, but the lifetime of the object at the old address
<br>&gt;&gt; is supposed to end, that object&#39;s type does not have a
<br>&gt;&gt; trivial destructor, and that destructor is not called.
<br>&gt;
<br>&gt;
<br>&gt; But the lifetime of the object is not being ended.
<br>
<br>In that case I don&#39;t know what we&#39;re discussing here, and I hav=
en&#39;t
<br>been following
<br>this thread.
<br>
<br>&gt;
<br>&gt; Given that the committee has frowned on trivially_destructive_mova=
ble, on
<br>&gt; the basis that it complicates the concept of destruction, I think =
the proper
<br>&gt; way to progress would be to instead request that the language reco=
gnize that
<br>&gt; some objects can be moved around, and that this does not involve
<br>&gt; destruction.
<br>
<br>I have no idea what that means. The language already recognizes that ob=
jects
<br>can be moved around, and so does the library.
<br></div></blockquote></blockquote><p><br></p><div><br></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_103_693092240.1438365372132--
------=_Part_102_279321088.1438365372132--

.

On Friday 31 July 2015 10:56:12 denis bider wrote:
> Thinking about this critically, the following seems to be the crux of the
>
> issue:
> > the library's containers can then move objects in memory *much more
>
> efficiently*
>
> Maybe this is not true. I don't know.
>
> If it is not true, then we don't need relocatable.
>
> For it to be true, at least one of the following needs to be true:
>
> (1) There have to be realistic scenarios where a contained
> class cannot implement is_nothrow_move_constructible and
> is_nothrow_destructible, but could implement is_relocatable. In the absence
> of is_relocatable, the container has to resort to deep copy, which is an
> obvious handbrake.

Not very difficult to create such a case. Destructive moves do both things at
the same time, something that a move constructor alone cannot know. Remember
that a moved object must be in a valid, albeit usually unspecified state.

All you need is a member pointer that must be unique and not null. A move
constructor must then allocate memory so that both objects retain valid
pointers that are different from each other. Your move constructor is not
nothrow anymore.

And yet this is relocatable, because if you do the destructive move, you don't
have to allocate memory. In a destructive move, we know that the source object
will not be accessed, not even the destructor.

> (2) There have to be realistic scenarios where the performance of move
> construction, followed by destruction of left-behind object, is
> substantially worse than memcpy. If the object has resources, the
> destructor would most likely check whether there are resources to be freed;
> find that there aren't any (they have been moved); and the move continues
> with the next object. The main cost of this is running unnecessary branch
> instructions which may or may not clog the CPU - depending on the CPU's
> branch prediction.

The case above would already be enough. I doubt the compilers of today are
smart enough to realise that they can remove a memory allocation followed by a
memory freeing in a move + destroy, even if it's all the loop does.

But to make it simpler: the move constructor and/or the destructor could be
out-of-line. That completely hides the implementation details from the
compiler so it does not know whether it can optimise anything and the overhead
of the two function calls is considerable.

Moreover, the non-inline case is important even for the nothrow-move-
constructible+nothrow-destructible.

> I personally don't have situations in my code where (1) is true. To be in
> harmony with the spirit of C++ as-is, I've switched all my stuff to nothrow
> move constructible and nothrow destructible. That doesn't mean there isn't
> code that cannot do this, and would benefit in this case from is_relocatable

I do. To name just one: QDateTime.

This class has a member pointer (the QDateTimePrivate d-pointer) which must be
valid and non-null in all objects; the copy constructor and destructor are not
inline. It currently has no move constructor for a different reason, but if it
did, it would suffer from this problem.

And yet this class is declared as Q_MOVABLE_TYPE.

> Situation (2) is one that my code "suffers" from. There's branching
> involved in unnecessary object destruction. It may turn out to be that - at
> least on *my* target platform - CPU branch prediction is good enough that
> the impact of this is trivial. But there may be realistic cases where it's
> not trivial, and there may be platforms where it is never trivial.

I have one very simple use-case that I'd like to be supported:

std::vector<QDateTime> should be able to grow or shrink its array block via
realloc() if it wants to. Or, worst case, allocate() + memcpy.
QVector<QDateTime> already does the latter.

It doesn't do the former, most especially because of the inability to
guarantee alignment out of realloc(). In my local branch, QArrayData::allocate
can allocate a memory block of any alignment, but
QArrayData::reallocateUnaligned only works for types that don't have alignment
requirements stricter than that of a pointer.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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_216_439986034.1438371349985
Content-Type: multipart/alternative;
 boundary="----=_Part_217_2034778147.1438371349986"

------=_Part_217_2034778147.1438371349986
Content-Type: text/plain; charset=UTF-8

Good examples.

A similar example that comes to mind is that DropBox uses non-null versions
unique_ptr and shared_ptr, which they call "nn_unique_ptr" and
"nn_shared_ptr":

https://www.reddit.com/r/cpp/comments/3do75k/nn_nonnullable_pointers_for_c/

When stored in containers, this would suffer from the same problem, and
worse - if the object being wrapped is non trivial.

I have also benchmarked the performance of a nothrow move+destroy vs memcpy
on Windows x64. I was moving around VS 2015 std::string objects. The
benchmark code is here:

http://pastebin.com/jxTJdgyX

Results are as follows:

(compiled with cl -EHa -O2 BenchDestrMove.cpp)

MoveDt 100000000 x 10, elapsed: 3906ms
MoveDt 10000000 x 100, elapsed: 3906ms
MoveDt 1000000 x 1000, elapsed: 6735ms
MoveDt 100000 x 10000, elapsed: 6859ms
MoveDt 10000 x 100000, elapsed: 7437ms
MoveDt 1000 x 1000000, elapsed: 8219ms

memcpy 100000000 x 10, elapsed: 1640ms
memcpy 10000000 x 100, elapsed: 438ms
memcpy 1000000 x 1000, elapsed: 1266ms
memcpy 100000 x 10000, elapsed: 1640ms
memcpy 10000 x 100000, elapsed: 2031ms
memcpy 1000 x 1000000, elapsed: 3562ms

I moved 1 billion objects each time, but I varied the number of objects
moved. The results above were consistent between runs.

As it appears, memcpy has a sweet spot at 100 std::strings where it's 9x
faster than nothrow move+destroy. This happens to be a container size that
I expect would be common.

As the number of objects increases towards 1 million, memory access starts
to dominate code/branching in terms of cost. memcpy is still 2.3x faster
than nothrow move+destroy in the worst case (1 million objects).

This is of course assuming that nothrow move+destroy is even possible,
which for non-nullable objects, it is not.


On Friday, July 31, 2015 at 12:55:23 PM UTC-6, Thiago Macieira wrote:

> On Friday 31 July 2015 10:56:12 denis bider wrote:
> > Thinking about this critically, the following seems to be the crux of
> the
> >
> > issue:
> > > the library's containers can then move objects in memory *much more
> >
> > efficiently*
> >
> > Maybe this is not true. I don't know.
> >
> > If it is not true, then we don't need relocatable.
> >
> > For it to be true, at least one of the following needs to be true:
> >
> > (1) There have to be realistic scenarios where a contained
> > class cannot implement is_nothrow_move_constructible and
> > is_nothrow_destructible, but could implement is_relocatable. In the
> absence
> > of is_relocatable, the container has to resort to deep copy, which is an
> > obvious handbrake.
>
> Not very difficult to create such a case. Destructive moves do both things
> at
> the same time, something that a move constructor alone cannot know.
> Remember
> that a moved object must be in a valid, albeit usually unspecified state.
>
> All you need is a member pointer that must be unique and not null. A move
> constructor must then allocate memory so that both objects retain valid
> pointers that are different from each other. Your move constructor is not
> nothrow anymore.
>
> And yet this is relocatable, because if you do the destructive move, you
> don't
> have to allocate memory. In a destructive move, we know that the source
> object
> will not be accessed, not even the destructor.
>
> > (2) There have to be realistic scenarios where the performance of move
> > construction, followed by destruction of left-behind object, is
> > substantially worse than memcpy. If the object has resources, the
> > destructor would most likely check whether there are resources to be
> freed;
> > find that there aren't any (they have been moved); and the move
> continues
> > with the next object. The main cost of this is running unnecessary
> branch
> > instructions which may or may not clog the CPU - depending on the CPU's
> > branch prediction.
>
> The case above would already be enough. I doubt the compilers of today are
> smart enough to realise that they can remove a memory allocation followed
> by a
> memory freeing in a move + destroy, even if it's all the loop does.
>
> But to make it simpler: the move constructor and/or the destructor could
> be
> out-of-line. That completely hides the implementation details from the
> compiler so it does not know whether it can optimise anything and the
> overhead
> of the two function calls is considerable.
>
> Moreover, the non-inline case is important even for the nothrow-move-
> constructible+nothrow-destructible.
>
> > I personally don't have situations in my code where (1) is true. To be
> in
> > harmony with the spirit of C++ as-is, I've switched all my stuff to
> nothrow
> > move constructible and nothrow destructible. That doesn't mean there
> isn't
> > code that cannot do this, and would benefit in this case from
> is_relocatable
>
> I do. To name just one: QDateTime.
>
> This class has a member pointer (the QDateTimePrivate d-pointer) which
> must be
> valid and non-null in all objects; the copy constructor and destructor are
> not
> inline. It currently has no move constructor for a different reason, but
> if it
> did, it would suffer from this problem.
>
> And yet this class is declared as Q_MOVABLE_TYPE.
>
> > Situation (2) is one that my code "suffers" from. There's branching
> > involved in unnecessary object destruction. It may turn out to be that -
> at
> > least on *my* target platform - CPU branch prediction is good enough
> that
> > the impact of this is trivial. But there may be realistic cases where
> it's
> > not trivial, and there may be platforms where it is never trivial.
>
> I have one very simple use-case that I'd like to be supported:
>
> std::vector<QDateTime> should be able to grow or shrink its array block
> via
> realloc() if it wants to. Or, worst case, allocate() + memcpy.
> QVector<QDateTime> already does the latter.
>
> It doesn't do the former, most especially because of the inability to
> guarantee alignment out of realloc(). In my local branch,
> QArrayData::allocate
> can allocate a memory block of any alignment, but
> QArrayData::reallocateUnaligned only works for types that don't have
> alignment
> requirements stricter than that of a pointer.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

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

<div dir=3D"ltr"><div>Good examples.</div><div><br></div><div>A similar exa=
mple=C2=A0that comes to mind is that DropBox uses non-null versions unique_=
ptr and shared_ptr, which they call &quot;nn_unique_ptr&quot; and &quot;nn_=
shared_ptr&quot;:</div><div><br></div><div><a href=3D"https://www.reddit.co=
m/r/cpp/comments/3do75k/nn_nonnullable_pointers_for_c/">https://www.reddit.=
com/r/cpp/comments/3do75k/nn_nonnullable_pointers_for_c/</a></div><div><br>=
</div><div>When stored in containers, this would suffer from the same probl=
em, and worse -=C2=A0if the object being wrapped is non trivial.</div><div>=
<br></div><div>I have also benchmarked the performance of a nothrow move+de=
stroy vs memcpy on Windows x64. I was moving around VS 2015 std::string obj=
ects. The benchmark code is here:</div><div><br></div><div><a href=3D"http:=
//pastebin.com/jxTJdgyX">http://pastebin.com/jxTJdgyX</a></div><div><br></d=
iv><div>Results are as follows:</div><div><br></div><div>(compiled with cl =
-EHa -O2 BenchDestrMove.cpp)</div><div><br></div><div>MoveDt 100000000 x 10=
, elapsed: 3906ms<br>MoveDt 10000000 x 100, elapsed: 3906ms<br>MoveDt 10000=
00 x 1000, elapsed: 6735ms<br>MoveDt 100000 x 10000, elapsed: 6859ms<br>Mov=
eDt 10000 x 100000, elapsed: 7437ms<br>MoveDt 1000 x 1000000, elapsed: 8219=
ms</div><div><br></div><div>memcpy 100000000 x 10, elapsed: 1640ms<br>memcp=
y 10000000 x 100, elapsed: 438ms<br>memcpy 1000000 x 1000, elapsed: 1266ms<=
br>memcpy 100000 x 10000, elapsed: 1640ms<br>memcpy 10000 x 100000, elapsed=
: 2031ms<br>memcpy 1000 x 1000000, elapsed: 3562ms</div><div><br></div><div=
>I moved 1 billion objects each time, but I varied the number of objects mo=
ved. The results above were consistent between runs.</div><div><br></div><d=
iv>As it appears, memcpy has a sweet spot at 100 std::strings where it&#39;=
s 9x faster than nothrow move+destroy. This happens to be a=C2=A0container =
size that I expect would be common.</div><div><br></div><div>As the number =
of objects increases towards 1 million, memory access starts to dominate=C2=
=A0code/branching in terms of cost. memcpy is still 2.3x faster than nothro=
w move+destroy in the worst case (1 million objects).</div><div><br></div><=
div>This is of course assuming that nothrow move+destroy is even possible, =
which for non-nullable objects, it is not.</div><div><br><br>On Friday, Jul=
y 31, 2015 at 12:55:23 PM UTC-6, Thiago Macieira wrote:</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;">On Friday 31 July 2015 10:56:12 denis bider wrote:
<br>&gt; Thinking about this critically, the following seems to be the crux=
 of the
<br>&gt;=20
<br>&gt; issue:
<br>&gt; &gt; the library&#39;s containers can then move objects in memory =
*much more
<br>&gt;=20
<br>&gt; efficiently*
<br>&gt;=20
<br>&gt; Maybe this is not true. I don&#39;t know.
<br>&gt;=20
<br>&gt; If it is not true, then we don&#39;t need relocatable.
<br>&gt;=20
<br>&gt; For it to be true, at least one of the following needs to be true:
<br>&gt;=20
<br>&gt; (1) There have to be realistic scenarios where a contained
<br>&gt; class cannot implement is_nothrow_move_constructible and
<br>&gt; is_nothrow_destructible, but could implement is_relocatable. In th=
e absence
<br>&gt; of is_relocatable, the container has to resort to deep copy, which=
 is an
<br>&gt; obvious handbrake.
<br>
<br>Not very difficult to create such a case. Destructive moves do both thi=
ngs at=20
<br>the same time, something that a move constructor alone cannot know. Rem=
ember=20
<br>that a moved object must be in a valid, albeit usually unspecified stat=
e.
<br>
<br>All you need is a member pointer that must be unique and not null. A mo=
ve=20
<br>constructor must then allocate memory so that both objects retain valid=
=20
<br>pointers that are different from each other. Your move constructor is n=
ot=20
<br>nothrow anymore.
<br>
<br>And yet this is relocatable, because if you do the destructive move, yo=
u don&#39;t=20
<br>have to allocate memory. In a destructive move, we know that the source=
 object=20
<br>will not be accessed, not even the destructor.
<br>
<br>&gt; (2) There have to be realistic scenarios where the performance of =
move
<br>&gt; construction, followed by destruction of left-behind object, is
<br>&gt; substantially worse than memcpy. If the object has resources, the
<br>&gt; destructor would most likely check whether there are resources to =
be freed;
<br>&gt; find that there aren&#39;t any (they have been moved); and the mov=
e continues
<br>&gt; with the next object. The main cost of this is running unnecessary=
 branch
<br>&gt; instructions which may or may not clog the CPU - depending on the =
CPU&#39;s
<br>&gt; branch prediction.
<br>
<br>The case above would already be enough. I doubt the compilers of today =
are=20
<br>smart enough to realise that they can remove a memory allocation follow=
ed by a=20
<br>memory freeing in a move + destroy, even if it&#39;s all the loop does.
<br>
<br>But to make it simpler: the move constructor and/or the destructor coul=
d be=20
<br>out-of-line. That completely hides the implementation details from the=
=20
<br>compiler so it does not know whether it can optimise anything and the o=
verhead=20
<br>of the two function calls is considerable.
<br>
<br>Moreover, the non-inline case is important even for the nothrow-move-
<br>constructible+nothrow-<wbr>destructible.
<br>
<br>&gt; I personally don&#39;t have situations in my code where (1) is tru=
e. To be in
<br>&gt; harmony with the spirit of C++ as-is, I&#39;ve switched all my stu=
ff to nothrow
<br>&gt; move constructible and nothrow destructible. That doesn&#39;t mean=
 there isn&#39;t
<br>&gt; code that cannot do this, and would benefit in this case from is_r=
elocatable
<br>
<br>I do. To name just one: QDateTime.
<br>
<br>This class has a member pointer (the QDateTimePrivate d-pointer) which =
must be=20
<br>valid and non-null in all objects; the copy constructor and destructor =
are not=20
<br>inline. It currently has no move constructor for a different reason, bu=
t if it=20
<br>did, it would suffer from this problem.=20
<br>
<br>And yet this class is declared as Q_MOVABLE_TYPE.
<br>
<br>&gt; Situation (2) is one that my code &quot;suffers&quot; from. There&=
#39;s branching
<br>&gt; involved in unnecessary object destruction. It may turn out to be =
that - at
<br>&gt; least on *my* target platform - CPU branch prediction is good enou=
gh that
<br>&gt; the impact of this is trivial. But there may be realistic cases wh=
ere it&#39;s
<br>&gt; not trivial, and there may be platforms where it is never trivial.
<br>
<br>I have one very simple use-case that I&#39;d like to be supported:
<br>
<br>std::vector&lt;QDateTime&gt; should be able to grow or shrink its array=
 block via=20
<br>realloc() if it wants to. Or, worst case, allocate() + memcpy.=20
<br>QVector&lt;QDateTime&gt; already does the latter.
<br>
<br>It doesn&#39;t do the former, most especially because of the inability =
to=20
<br>guarantee alignment out of realloc(). In my local branch, QArrayData::a=
llocate=20
<br>can allocate a memory block of any alignment, but=20
<br>QArrayData::<wbr>reallocateUnaligned only works for types that don&#39;=
t have alignment=20
<br>requirements stricter than that of a pointer.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.=
href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;=
" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofollow">macieira=
..info</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http://www.googl=
e.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJd=
o5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http=
://www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" href=3D"http://kde.o=
rg" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></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_217_2034778147.1438371349986--
------=_Part_216_439986034.1438371349985--

.

On 2015-07-31 13:56, denis bider wrote:
> Thinking about this critically, the following seems to be the crux of the
> issue:
>
>> the library's containers can then move objects in memory *much more
> efficiently*
>
> Maybe this is not true. I don't know.
>
> If it is not true, then we don't need relocatable.
>
> For it to be true, at least one of the following needs to be true:
>
> (1) There have to be realistic scenarios where a contained
> class cannot implement is_nothrow_move_constructible and
> is_nothrow_destructible, but could implement is_relocatable. In the absence
> of is_relocatable, the container has to resort to deep copy, which is an
> obvious handbrake.

I think that is not strict enough, as...

> (2) There have to be realistic scenarios where the performance of move
> construction, followed by destruction of left-behind object, is
> substantially worse than memcpy.

....just calling the move ctor and dtor for every item is non-trivially
expensive (at least if they aren't inlined). Even besides the function
calls, having to restart the block memcpy for every item could harm
performance in some cases.

Really, I don't see any way relocation is not an improvement over any
other technique.

(Does e.g. std::vector at least currently fall back to memmove for POD
types, e.g. int? If not, that would be an interesting test case; I
suspect block memory operations are going to be faster for that than
individual assignments.)

> If the object has resources, the destructor would most likely check
> whether there are resources to be freed; find that there aren't any
> (they have been moved); and the move continues with the next object.
> The main cost of this is running unnecessary branch instructions
> which may or may not clog the CPU - depending on the CPU's branch
> prediction.

std::unique_ptr would make an interesting test case here...

--
Matthew

--

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

.

--Apple-Mail=_182A6642-8241-4A3B-AE8D-D87624ACEC43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9308=E2=80=9301, at 1:23 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> I presume this also requires that the destructor of the derived type is
> trivial purely from the point of view of the derived type, aka is not
> user-provided.

No, that would defeat the purpose. Quick recap:

Destructive move is useful when the move constructor is doing work that sim=
ply gets undone by the destructor. For most containers, this consists of nu=
lling out the moved-from node pointers so the moved-from state is empty. Fo=
r std::list on implementations with sentinel end nodes, it=E2=80=99s worse =
because the move constructor needs to allocate the sentinel, which the dest=
ructor immediately frees.

The goal is to skip the =E2=80=9Cuser-provided=E2=80=9D destructor behavior=
 of freeing nodes, but without straying too far from the lifetime model.

Pablo=E2=80=99s idea is to skip the destructor and move constructor entirel=
y, and do the construction inside uninitialized_destructive_move =E2=80=94 =
ideally, memcpy the object representation. There are two specializations of=
 uninitialized_destructive_move in N4393: for classes that declare memcpy t=
o be enough, and for std::list specifically, which really wants the optimiz=
ation in a more general case. The latter needs to do explicit destructor ca=
lls on the members of the list, although this step is missing from N4393 (i=
t only does the corresponding placement-news).

My idea is to slice the object back to a base class, which contains all the=
 NSDMs but doesn=E2=80=99t implement e.g. sentinel management. A base destr=
uctor which destroys all the members (typically, all the bytes) of the obje=
ct leaves it =E2=80=9Cdestroyed enough.=E2=80=9D Bless any such base destru=
ctor so the entire object is officially destroyed=E2=80=A6 after all, it=E2=
=80=99s impossible to run the derived destructor at that point, or to acces=
s the object in any way.

For a trivially copyable and trivially destructible base, slicing should wo=
rk out exactly as efficiently as N4393. If something is nontrivial, the gen=
eric implementation continues to work. There should only be a need for one =
uninitialized_destructive_move overload, no function SFINAE or ADL.

// Trait pulls info from the target class.
// Default (also works for non-class objects): move and destroy the complet=
e object.
template< typename in_type, typename =3D void >
struct destructive_move_base_type
    { typedef in_type type; };

// Allow a class to nominate its base to handle destructive moves.
// (Nomination could also be done by manual specialization inside namespace=
 std.)
template< typename in_type >
struct destructive_move_base_type< in_type,
    std::void_t< typename in_type::destructive_move_base_type > > // detect=
 magic member typedef
    { typedef typename in_type::destructive_move_base_type type; };

// Catch-all destructive move implementation.
template< typename object >
void uninitialized_destructive_move( object * from, object * to ) noexcept(=
auto) {
    typedef typename destructive_move_base_type< object >::type base;
    new (to) object( static_cast< base && >( * from ) );
    from-> ~ base();
}

For stateful allocators, nodes may or may not be transferrable at all. Stay=
ing within the generic uninitialized_destructive_move would be tricky, but =
it might still be possible. (Move the sequence in the base class, allocate =
the sentinel in the derived class.) Otherwise, that case would require over=
loading or function template specialization.

--=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=_182A6642-8241-4A3B-AE8D-D87624ACEC43
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 2015=E2=80=9308=
=E2=80=9301, at 1:23 AM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">I presume this a=
lso requires that the destructor of the derived type is<br class=3D"">trivi=
al purely from the point of view of the derived type, aka is not<br class=
=3D"">user-provided.<br class=3D""></div></blockquote><div><br class=3D""><=
/div><div>No, that would defeat the purpose. Quick recap:</div><div><br cla=
ss=3D""></div><div>Destructive move is useful when the move constructor is =
doing work that simply gets undone by the destructor. For most containers, =
this consists of nulling out the moved-from node pointers so the moved-from=
 state is empty. For <font face=3D"Courier" class=3D"">std::list</font> on =
implementations with sentinel <font face=3D"Courier" class=3D"">end</font> =
nodes, it=E2=80=99s worse because the move constructor needs to allocate th=
e sentinel, which the destructor immediately frees.</div><div><br class=3D"=
"></div><div>The goal is to skip the =E2=80=9Cuser-provided=E2=80=9D destru=
ctor behavior of freeing nodes, but without straying too far from the lifet=
ime model.</div><div><br class=3D""></div><div>Pablo=E2=80=99s idea is to s=
kip the destructor and move constructor entirely, and do the construction i=
nside&nbsp;<span style=3D"font-family: Courier;" class=3D"">uninitialized_d=
estructive_move</span>&nbsp;=E2=80=94 ideally,&nbsp;<font face=3D"Courier" =
class=3D"">memcpy</font> the object representation. There are two specializ=
ations of&nbsp;<span style=3D"font-family: Courier;" class=3D"">uninitializ=
ed_destructive_move</span>&nbsp;in N4393: for classes that declare&nbsp;<sp=
an style=3D"font-family: Courier;" class=3D"">memcpy</span>&nbsp;to be enou=
gh, and for <font face=3D"Courier" class=3D"">std::list</font> specifically=
, which really wants the optimization in a more general case. The latter ne=
eds to do explicit destructor calls on the members of the <font face=3D"Cou=
rier" class=3D"">list</font>, although this step is missing from N4393 (it =
only does the corresponding placement-<font face=3D"Courier" class=3D"">new=
</font>s).</div><div><br class=3D""></div><div>My idea is to slice the obje=
ct back to a base class, which contains all the NSDMs but doesn=E2=80=99t i=
mplement e.g. sentinel management. A base destructor which destroys all the=
 members (typically, all the bytes) of the object leaves it =E2=80=9Cdestro=
yed enough.=E2=80=9D Bless any such base destructor so the entire object is=
 officially destroyed=E2=80=A6 after all, it=E2=80=99s impossible to run th=
e derived destructor at that point, or to access the object in any way.</di=
v><div><br class=3D""></div><div>For a trivially copyable and trivially des=
tructible base, slicing should work out exactly as efficiently as N4393. If=
 something is nontrivial, the generic implementation continues to work. The=
re should only be a need for one <font face=3D"Courier" class=3D"">uninitia=
lized_destructive_move</font> overload, no function SFINAE or ADL.</div><di=
v class=3D""><br class=3D""></div><div class=3D""><font face=3D"Courier" cl=
ass=3D"">// Trait pulls info from the target class.</font></div><div class=
=3D""><font face=3D"Courier" class=3D"">// Default (also works for non-clas=
s objects): move and destroy the&nbsp;complete object.</font></div><div cla=
ss=3D""><font face=3D"Courier" class=3D"">template&lt; typename in_type, ty=
pename =3D void &gt;</font></div><div class=3D""><font face=3D"Courier" cla=
ss=3D"">struct destructive_move_base_type</font></div><div class=3D""><font=
 face=3D"Courier" class=3D"">&nbsp; &nbsp; { typedef in_type type; };</font=
></div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></f=
ont></div><div class=3D""><font face=3D"Courier" class=3D"">// Allow a clas=
s to nominate its base to handle destructive moves.</font></div><div class=
=3D""><font face=3D"Courier" class=3D"">// (Nomination could also be done b=
y&nbsp;manual specialization inside namespace std.)</font></div><div class=
=3D""><font face=3D"Courier" class=3D"">template&lt; typename in_type &gt;<=
/font></div><div class=3D""><font face=3D"Courier" class=3D"">struct destru=
ctive_move_base_type&lt; in_type,</font></div><div class=3D""><font face=3D=
"Courier" class=3D"">&nbsp; &nbsp; std::void_t&lt; typename in_type::destru=
ctive_move_base_type &gt; &gt; // detect magic member typedef</font></div><=
div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; { typedef ty=
pename in_type::destructive_move_base_type&nbsp;type; };</font></div><div c=
lass=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><di=
v class=3D""><font face=3D"Courier" class=3D"">// Catch-all&nbsp;destructiv=
e move implementation.</font></div><div><font face=3D"Courier" class=3D"">t=
emplate&lt; typename&nbsp;object&nbsp;&gt;</font></div><div><font face=3D"C=
ourier" class=3D"">void uninitialized_destructive_move( object * from,&nbsp=
;object&nbsp;* to ) noexcept(auto) {</font></div><div><font face=3D"Courier=
" class=3D"">&nbsp; &nbsp; typedef typename destructive_move_base_type&lt; =
object &gt;::type base;</font></div><div><font face=3D"Courier" class=3D"">=
&nbsp; &nbsp; new (to)&nbsp;object( static_cast&lt; base &amp;&amp; &gt;( *=
 from ) );</font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp;=
 from-&gt; ~ base();</font></div><div><font face=3D"Courier" class=3D"">}</=
font></div><div class=3D""><br class=3D""></div><div class=3D"">For statefu=
l allocators, nodes may or may not be transferrable at all. Staying within =
the generic&nbsp;<span style=3D"font-family: Courier;" class=3D"">uninitial=
ized_destructive_move</span>&nbsp;would be tricky, but it might still be po=
ssible. (Move the sequence in the base class, allocate the sentinel in the =
derived class.) Otherwise, that case would require&nbsp;overloading or func=
tion template specialization.</div><div class=3D""><br class=3D""></div></d=
iv></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=_182A6642-8241-4A3B-AE8D-D87624ACEC43--

.

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

On Fri, Jul 31, 2015 at 6:27 PM, denis bider <isocppgroup@denisbider.com>
wrote:

> Given that the committee has frowned on trivially_destructive_movable, on
> the basis that it complicates the concept of destruction,
>
> I think you are going a bit far in your interpretation of the discussion.
I don't think the committee has frowned on anything.  Writing an
specification is hard and it requires consistency, coherency, completeness=
=E2=80=A6
the language is built on certain building blocks that include the lifetime
of objects and the address of the object serving as an identity.

Note that lifetime is conceptual, no bits flip in your computer when an
object becomes alive or die, but rules in the language referring to an
object apply only during the lifetime. Yes, libraries have been doing this,
which is undefined behavior as the destination of the move never became an
object and thus the language provides no guarantees of behavior for it.

My understanding is that the committee is, far from frowning on the idea,
trying to find a way of getting this feature into the language and that
involves changing an specification that supports this and does not break
anything else.  There could be different ways of handling the
specification, either finding a way of managing the lifetimes of the
objects (most of this discussion is focused on that) or changing the
language so that an object can be "conceptually" moved (other languages,
managed languages with generational garbage collectors for example) support
this.  I don't think allowing objects to "shift" to a different position
(trying to avoid move due to the connotations) is simpler than finding a
way around lifetimes.

    David

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

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

<div dir=3D"ltr">On Fri, Jul 31, 2015 at 6:27 PM, denis bider <span dir=3D"=
ltr">&lt;<a href=3D"mailto:isocppgroup@denisbider.com" target=3D"_blank">is=
ocppgroup@denisbider.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D""><div>Given that the committee has frowned on=C2=A0trivia=
lly_destructive_movable,=C2=A0on the basis that it complicates the concept =
of destruction,<br></div></span><div><br></div></div></blockquote><div>I th=
ink you are going a bit far in your interpretation of the discussion. I don=
&#39;t think the committee has frowned on anything.=C2=A0 Writing an specif=
ication is hard and it requires consistency, coherency, completeness=E2=80=
=A6 the language is built on certain building blocks that include the lifet=
ime of objects and the address of the object serving as an identity.</div><=
div><br></div><div>Note that lifetime is conceptual, no bits flip in your c=
omputer when an object becomes alive or die, but rules in the language refe=
rring to an object apply only during the lifetime. Yes, libraries have been=
 doing this, which is undefined behavior as the destination of the move nev=
er became an object and thus the language provides no guarantees of behavio=
r for it.</div><div><br></div><div>My understanding is that the committee i=
s, far from frowning on the idea, trying to find a way of getting this feat=
ure into the language and that involves changing an specification that supp=
orts this and does not break anything else.=C2=A0 There could be different =
ways of handling the specification, either finding a way of managing the li=
fetimes of the objects (most of this discussion is focused on that) or chan=
ging the language so that an object can be &quot;conceptually&quot; moved (=
other languages, managed languages with generational garbage collectors for=
 example) support this.=C2=A0 I don&#39;t think allowing objects to &quot;s=
hift&quot; to a different position (trying to avoid move due to the connota=
tions) is simpler than finding a way around lifetimes.<br></div><div><br></=
div><div>=C2=A0 =C2=A0 David</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 />

--001a113492b8c69b88051c41e923--

.

------=_Part_616_1193677653.1438461211070
Content-Type: multipart/alternative;
 boundary="----=_Part_617_602476875.1438461211070"

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

I see; I appreciate the clarification.

Would it not be easier to approach this conceptually from a point of view=
=20
that does not involve the concept of movement or relocation?

Instead of calling the concept *trivially destructive movable*; or=20
*relocatable*; both of which imply some kind of action, some movement;

.... what if we called it *location agnostic*?

By defining the property that way, we would sidestep the relocation aspect=
=20
altogether.

Of course, an is_location_agnostic property would be used in practice to=20
relocate objects in memory. In practice, it would lead to use of realloc=20
for resizing, instead of always allocating new memory.

However, defining the property as is_location_agnostic - i.e., not saying=
=20
anything about movement - would allow the property to start being used,=20
while allowing the language to catch up with the movement aspect=20
conceptually.

If this is not done, my worry is that the conceptual aspect may hold back=
=20
practical implementation by any number of years - 5 years, 10 years,=20
however long it takes until someone comes up with a satisfactory language=
=20
fiction to explain what everyone already understands intuitively.

It seems to me that, in this case, we could benefit from decoupling the=20
practical from the theoretical, given that the way this conceptual problem=
=20
is eventually resolved is *exceedingly unlikely* to have any effect on=20
implementation in practice.


On Saturday, August 1, 2015 at 9:51:46 AM UTC-6, David Rodr=C3=ADguez Ibeas=
=20
wrote:

> On Fri, Jul 31, 2015 at 6:27 PM, denis bider <isocp...@denisbider.com=20
> <javascript:>> wrote:
>
>> Given that the committee has frowned on trivially_destructive_movable, o=
n=20
>> the basis that it complicates the concept of destruction,
>>
>> I think you are going a bit far in your interpretation of the discussion=
..=20
> I don't think the committee has frowned on anything.  Writing an=20
> specification is hard and it requires consistency, coherency, completenes=
s=E2=80=A6=20
> the language is built on certain building blocks that include the lifetim=
e=20
> of objects and the address of the object serving as an identity.
>
> Note that lifetime is conceptual, no bits flip in your computer when an=
=20
> object becomes alive or die, but rules in the language referring to an=20
> object apply only during the lifetime. Yes, libraries have been doing thi=
s,=20
> which is undefined behavior as the destination of the move never became a=
n=20
> object and thus the language provides no guarantees of behavior for it.
>
> My understanding is that the committee is, far from frowning on the idea,=
=20
> trying to find a way of getting this feature into the language and that=
=20
> involves changing an specification that supports this and does not break=
=20
> anything else.  There could be different ways of handling the=20
> specification, either finding a way of managing the lifetimes of the=20
> objects (most of this discussion is focused on that) or changing the=20
> language so that an object can be "conceptually" moved (other languages,=
=20
> managed languages with generational garbage collectors for example) suppo=
rt=20
> this.  I don't think allowing objects to "shift" to a different position=
=20
> (trying to avoid move due to the connotations) is simpler than finding a=
=20
> way around lifetimes.
>
>     David
>

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

<div dir=3D"ltr"><div>I see; I appreciate the clarification.</div><div><br>=
</div><div>Would it not be easier to approach this conceptually from a poin=
t of view that does not involve the concept of movement or relocation?</div=
><div><br></div><div>Instead of calling the concept <em>trivially destructi=
ve movable</em>; or <em>relocatable</em>; both of which imply some kind of =
action, some movement;</div><div><br></div><div>... what if we called it <e=
m>location agnostic</em>?</div><div><br></div><div>By defining the property=
 that way, we would sidestep the=C2=A0relocation aspect altogether.</div><d=
iv><br></div><div>Of course,=C2=A0an=C2=A0<font face=3D"courier new,monospa=
ce">is_location_agnostic</font>=C2=A0property=C2=A0would be used in practic=
e to relocate objects in memory.=C2=A0In practice, it=C2=A0would lead to us=
e of <font face=3D"courier new,monospace">realloc</font> for resizing, inst=
ead of always allocating new memory.</div><div><br></div><div>However, defi=
ning the property as <font face=3D"courier new,monospace">is_location_agnos=
tic</font> - i.e., not saying anything about movement - would allow the pro=
perty to start being used, while allowing the language to catch up with the=
 movement aspect conceptually.</div><div><br></div><div>If this is not done=
, my worry is that the conceptual aspect may hold back practical implementa=
tion by any number of years - 5 years, 10 years, however long it takes unti=
l someone comes up with a satisfactory language fiction to explain what eve=
ryone already understands intuitively.</div><div><br></div><div>It seems to=
 me that, in this case, we could benefit from decoupling the practical from=
 the theoretical, given that the way this conceptual problem is eventually =
resolved is <em>exceedingly unlikely</em> to have any effect on implementat=
ion in practice.</div><div><br><br>On Saturday, August 1, 2015 at 9:51:46 A=
M UTC-6, David Rodr=C3=ADguez Ibeas wrote:</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
"><div dir=3D"ltr">On Fri, Jul 31, 2015 at 6:27 PM, denis bider <span dir=
=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"1sQwqP=
z-DgAJ">isocp...@denisbider.com</a>&gt;</span> wrote:<br><div><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><span><div>Give=
n that the committee has frowned on=C2=A0trivially_destructive_<wbr>movable=
,=C2=A0on the basis that it complicates the concept of destruction,<br></di=
v></span><div><br></div></div></blockquote><div>I think you are going a bit=
 far in your interpretation of the discussion. I don&#39;t think the commit=
tee has frowned on anything.=C2=A0 Writing an specification is hard and it =
requires consistency, coherency, completeness=E2=80=A6 the language is buil=
t on certain building blocks that include the lifetime of objects and the a=
ddress of the object serving as an identity.</div><div><br></div><div>Note =
that lifetime is conceptual, no bits flip in your computer when an object b=
ecomes alive or die, but rules in the language referring to an object apply=
 only during the lifetime. Yes, libraries have been doing this, which is un=
defined behavior as the destination of the move never became an object and =
thus the language provides no guarantees of behavior for it.</div><div><br>=
</div><div>My understanding is that the committee is, far from frowning on =
the idea, trying to find a way of getting this feature into the language an=
d that involves changing an specification that supports this and does not b=
reak anything else.=C2=A0 There could be different ways of handling the spe=
cification, either finding a way of managing the lifetimes of the objects (=
most of this discussion is focused on that) or changing the language so tha=
t an object can be &quot;conceptually&quot; moved (other languages, managed=
 languages with generational garbage collectors for example) support this.=
=C2=A0 I don&#39;t think allowing objects to &quot;shift&quot; to a differe=
nt position (trying to avoid move due to the connotations) is simpler than =
finding a way around lifetimes.<br></div><div><br></div><div>=C2=A0 =C2=A0 =
David</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_617_602476875.1438461211070--
------=_Part_616_1193677653.1438461211070--

.

------=_Part_344_662060902.1438561633719
Content-Type: multipart/alternative;
 boundary="----=_Part_345_672968853.1438561633719"

------=_Part_345_672968853.1438561633719
Content-Type: text/plain; charset=UTF-8

On Saturday, August 1, 2015 at 4:33:31 PM UTC-4, denis bider wrote:
>
> I see; I appreciate the clarification.
>
> Would it not be easier to approach this conceptually from a point of view
> that does not involve the concept of movement or relocation?
>
> Instead of calling the concept *trivially destructive movable*; or
> *relocatable*; both of which imply some kind of action, some movement;
>
> ... what if we called it *location agnostic*?
>
> By defining the property that way, we would sidestep the relocation aspect
> altogether.
>
> Of course, an is_location_agnostic property would be used in practice to
> relocate objects in memory. In practice, it would lead to use of realloc
> for resizing, instead of always allocating new memory.
>
> However, defining the property as is_location_agnostic - i.e., not saying
> anything about movement - would allow the property to start being used,
> while allowing the language to catch up with the movement aspect
> conceptually.
>
> If this is not done, my worry is that the conceptual aspect may hold back
> practical implementation by any number of years - 5 years, 10 years,
> however long it takes until someone comes up with a satisfactory language
> fiction to explain what everyone already understands intuitively.
>

Well, here's the problem with going that route.

Let's say you come up with a concept, and any objects that fulfill that
concept are location agnostic. But you don't actually attach any semantics
to that concept. You say nothing in the language about what such types
mean, how the compiler treats them, or anything else. You just have a way
to test if a type fulfills that criteria.

Now later on, you're trying to decide how to go about making objects
destructively moveable. While looking at compilers, memory layout, and
various other things, you suddenly realize something. Your "location
agnostic" concept includes some objects which *cannot* be destructively
move safely. Or you decide to use David Krauss's suggestion, which requires
a specific property of a base class.

Oops...

Now you have to create a second concept, "destructively moveable", and now
you have a completely worthless concept that no language facilities attach
to. Plus, a bunch of people probably wrote their classes to be "location
agnostic" on the assumption that they would eventually become
"destructively moveable". So now they need to rewrite their types.

I see no need to be in such a hurry with this feature that you'd be willing
to take such a risk. Better to wait and get it right (see: concepts) than
to hurry and make a mistake.

It seems to me that, in this case, we could benefit from decoupling the
> practical from the theoretical, given that the way this conceptual problem
> is eventually resolved is *exceedingly unlikely* to have any effect on
> implementation in practice.
>

"Exceedingly unlikely"? It would take a great deal of compiler experience
to say that with any degree of confidence. Especially about something this
complex.

--

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

On Saturday, August 1, 2015 at 4:33:31 PM UTC-4, denis bider wrote:<blockqu=
ote 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>I see; I appreci=
ate the clarification.</div><div><br></div><div>Would it not be easier to a=
pproach this conceptually from a point of view that does not involve the co=
ncept of movement or relocation?</div><div><br></div><div>Instead of callin=
g the concept <i>trivially destructive movable</i>; or <i>relocatable</i>; =
both of which imply some kind of action, some movement;</div><div><br></div=
><div>... what if we called it <i>location agnostic</i>?</div><div><br></di=
v><div>By defining the property that way, we would sidestep the=C2=A0reloca=
tion aspect altogether.</div><div><br></div><div>Of course,=C2=A0an=C2=A0<f=
ont face=3D"courier new,monospace">is_location_<wbr>agnostic</font>=C2=A0pr=
operty=C2=A0would be used in practice to relocate objects in memory.=C2=A0I=
n practice, it=C2=A0would lead to use of <font face=3D"courier new,monospac=
e">realloc</font> for resizing, instead of always allocating new memory.</d=
iv><div><br></div><div>However, defining the property as <font face=3D"cour=
ier new,monospace">is_location_agnostic</font> - i.e., not saying anything =
about movement - would allow the property to start being used, while allowi=
ng the language to catch up with the movement aspect conceptually.</div><di=
v><br></div><div>If this is not done, my worry is that the conceptual aspec=
t may hold back practical implementation by any number of years - 5 years, =
10 years, however long it takes until someone comes up with a satisfactory =
language fiction to explain what everyone already understands intuitively.<=
/div></div></blockquote><div><br>Well, here&#39;s the problem with going th=
at route.<br><br>Let&#39;s say you come up with a concept, and any objects =
that fulfill that concept are location agnostic. But you don&#39;t actually=
 attach any semantics to that concept. You say nothing in the language abou=
t what such types mean, how the compiler treats them, or anything else. You=
 just have a way to test if a type fulfills that criteria.<br><br>Now later=
 on, you&#39;re trying to decide how to go about making objects destructive=
ly moveable. While looking at compilers, memory layout, and various other t=
hings, you suddenly realize something. Your &quot;location agnostic&quot; c=
oncept includes some objects which <i>cannot</i> be destructively move safe=
ly. Or you decide to use David Krauss&#39;s suggestion, which requires a sp=
ecific property of a base class.<br><br>Oops...<br><br>Now you have to crea=
te a second concept, &quot;destructively moveable&quot;, and now you have a=
 completely worthless concept that no language facilities attach to. Plus, =
a bunch of people probably wrote their classes to be &quot;location agnosti=
c&quot; on the assumption that they would eventually become &quot;destructi=
vely moveable&quot;. So now they need to rewrite their types.<br><br>I see =
no need to be in such a hurry with this feature that you&#39;d be willing t=
o take such a risk. Better to wait and get it right (see: concepts) than to=
 hurry and make a mistake.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>It seems to me that, in this case, we could=
 benefit from decoupling the practical from the theoretical, given that the=
 way this conceptual problem is eventually resolved is <i>exceedingly unlik=
ely</i> to have any effect on implementation in practice.</div></div></bloc=
kquote><div><br>&quot;Exceedingly unlikely&quot;? It would take a great dea=
l of compiler experience to say that with any degree of confidence. Especia=
lly about something this complex.</div><br>

<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_345_672968853.1438561633719--
------=_Part_344_662060902.1438561633719--

.

--Apple-Mail=_FD93F798-DC88-4067-8BA7-AB160DA46BC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9308=E2=80=9303, at 8:27 AM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> Or you decide to use David Krauss's suggestion, which requires a specific=
 property of a base class.

My proposal doesn=E2=80=99t place any requirements on the base. It only res=
tricts the derived class, and those restrictions are statically checked des=
pite the lack of a core language concept.

> Now you have to create a second concept, "destructively moveable=E2=80=9D

The reason there=E2=80=99s no such concept in my proposal is that everythin=
g is destructively movable. Some classes might optimize the operation, perh=
aps causing std::uninitialized_destructive_move to be noexcept whereas the =
move constructor may throw.

--=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=_FD93F798-DC88-4067-8BA7-AB160DA46BC8
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 2015=E2=80=9308=
=E2=80=9303, at 8:27 AM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>&gt; 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; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;" class=3D"">Or you decide to use David Krauss's =
suggestion, which requires a specific property of a base class.</span></div=
></blockquote></div><br class=3D""><div class=3D"">My proposal doesn=E2=80=
=99t place any requirements on the base. It only restricts the derived clas=
s, and those restrictions are statically checked despite the lack of a core=
 language concept.</div><div class=3D""><br class=3D""></div><div class=3D"=
"><blockquote type=3D"cite" class=3D"">Now you have to create a second conc=
ept, "destructively moveable=E2=80=9D</blockquote><br class=3D""></div><div=
 class=3D"">The reason there=E2=80=99s no such concept in my proposal is th=
at everything is destructively movable. Some classes might optimize the ope=
ration, perhaps causing&nbsp;<font face=3D"Courier" class=3D"">std::uniniti=
alized_destructive_move</font> to be&nbsp;<font face=3D"Courier" class=3D""=
>noexcept</font>&nbsp;whereas the move constructor may throw.</div><div cla=
ss=3D""><br class=3D""></div></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=_FD93F798-DC88-4067-8BA7-AB160DA46BC8--

.

------=_Part_294_360703203.1438619321788
Content-Type: multipart/alternative;
 boundary="----=_Part_295_1143265214.1438619321789"

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



On Monday, August 3, 2015 at 12:15:18 AM UTC-4, David Krauss wrote:
>
>
> On 2015=E2=80=9308=E2=80=9303, at 8:27 AM, Nicol Bolas <jmck...@gmail.com=
 <javascript:>>=20
> wrote:
>
> Or you decide to use David Krauss's suggestion, which requires a specific=
=20
> property of a base class.
>
>
> My proposal doesn=E2=80=99t place any requirements on the base. It only r=
estricts=20
> the derived class, and those restrictions are statically checked despite=
=20
> the lack of a core language concept.
>

"The base class destructor must not be virtual"

That sounds like a "specific property of a base class" to me ;) Admittedly,=
=20
it's not as onerous as I thought. But it's still there.

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

<br><br>On Monday, August 3, 2015 at 12:15:18 AM UTC-4, David Krauss wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-=
word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9308=E2=80=9303=
, at 8:27 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"QrgSVCR2DwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:</div><br><div><sp=
an style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important">Or you decide to use David =
Krauss&#39;s suggestion, which requires a specific property of a base class=
..</span></div></blockquote></div><br><div>My proposal doesn=E2=80=99t place=
 any requirements on the base. It only restricts the derived class, and tho=
se restrictions are statically checked despite the lack of a core language =
concept.</div></div></blockquote><div><br>&quot;The base class destructor m=
ust not be virtual&quot;<br><br>That sounds like a &quot;specific property =
of a base class&quot; to me ;) Admittedly, it&#39;s not as onerous as I tho=
ught. But it&#39;s still there.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_295_1143265214.1438619321789--
------=_Part_294_360703203.1438619321788--

.