------=_Part_8498_11022869.1388540574214
Content-Type: text/plain; charset=ISO-8859-1

Writing swap() is one of those boilerplate kinds of things that is usually
trivial but annoying (and error prone when you change data members but
forget to update swap()).

Why not allow this:

class Foo {
  public:
    void swap(Foo& f) = default;
  private:
    int a;
    Bar b;
    float c;
    Baz* d;
};

Which would be the equivalent of this:

void Foo::swap(Foo& f) {
  using std::swap;
  swap(a, f.a);
  swap(b, f.b);
  swap(c, f.c);
  swap(d, f.d);
}

Any reason this wouldn't make it as a proposal?

--

---
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_8498_11022869.1388540574214
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Writing swap() is one of those boilerplate kinds of things=
 that is usually trivial but annoying (and error prone when you change data=
 members but forget to update swap()).<div><br></div><div>Why not allow thi=
s:</div><div><br></div><div>class Foo {</div><div>&nbsp; public:</div><div>=
&nbsp; &nbsp; void swap(Foo&amp; f) =3D default;</div><div>&nbsp; private:<=
/div><div>&nbsp; &nbsp; int a;</div><div>&nbsp; &nbsp; Bar b;</div><div>&nb=
sp; &nbsp; float c;</div><div>&nbsp; &nbsp; Baz* d;</div><div>};</div><div>=
<br></div><div>Which would be the equivalent of this:</div><div><br></div><=
div>void Foo::swap(Foo&amp; f) {<br>&nbsp; using std::swap;</div><div>&nbsp=
; swap(a, f.a);</div><div>&nbsp; swap(b, f.b);</div><div>&nbsp; swap(c, f.c=
);</div><div>&nbsp; swap(d, f.d);</div><div>}</div><div><br></div><div>Any =
reason this wouldn't make it as a proposal?</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8498_11022869.1388540574214--

.

--089e0111be76ed4b8304eedef4a3
Content-Type: text/plain; charset=ISO-8859-1

I don't think this is a good idea -- if a type is going to provide swap,
normally it must do so in a non-throwing way. I'd worry that people would
just add it in without thinking only to break normal assumptions of what
swap does.

The other issue here is that "using std::swap" would require including
<algorithm>...

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 31, 2013 at 5:42 PM, <fmatthew5876@gmail.com> wrote:

> Writing swap() is one of those boilerplate kinds of things that is usually
> trivial but annoying (and error prone when you change data members but
> forget to update swap()).
>
> Why not allow this:
>
> class Foo {
>   public:
>     void swap(Foo& f) = default;
>   private:
>     int a;
>     Bar b;
>     float c;
>     Baz* d;
> };
>
> Which would be the equivalent of this:
>
> void Foo::swap(Foo& f) {
>   using std::swap;
>   swap(a, f.a);
>   swap(b, f.b);
>   swap(c, f.c);
>   swap(d, f.d);
> }
>
> Any reason this wouldn't make it as a proposal?
>
> --
>
> ---
> 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/.

--089e0111be76ed4b8304eedef4a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t think this is a good idea -- if a type is goin=
g to provide swap, normally it must do so in a non-throwing way. I&#39;d wo=
rry that people would just add it in without thinking only to break normal =
assumptions of what swap does.<div>

<br></div><div>The other issue here is that &quot;using std::swap&quot; wou=
ld require including &lt;algorithm&gt;...</div></div><div class=3D"gmail_ex=
tra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><di=
v>

<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/=
billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 5:42 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank"=
>fmatthew5876@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">

<div dir=3D"ltr">Writing swap() is one of those boilerplate kinds of things=
 that is usually trivial but annoying (and error prone when you change data=
 members but forget to update swap()).<div><br></div><div>Why not allow thi=
s:</div>

<div><br></div><div>class Foo {</div><div>=A0 public:</div><div>=A0 =A0 voi=
d swap(Foo&amp; f) =3D default;</div><div>=A0 private:</div><div>=A0 =A0 in=
t a;</div><div>=A0 =A0 Bar b;</div><div>=A0 =A0 float c;</div><div>=A0 =A0 =
Baz* d;</div><div>};</div>

<div><br></div><div>Which would be the equivalent of this:</div><div><br></=
div><div>void Foo::swap(Foo&amp; f) {<br>=A0 using std::swap;</div><div>=A0=
 swap(a, f.a);</div><div>=A0 swap(b, f.b);</div><div>=A0 swap(c, f.c);</div=
><div>

=A0 swap(d, f.d);</div><div>}</div><div><br></div><div>Any reason this woul=
dn&#39;t make it as a proposal?</div></div><span class=3D"HOEnZb"><font col=
or=3D"#888888">

<p></p>

-- <br>
=A0<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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0111be76ed4b8304eedef4a3--

.

------=_Part_4695_25600600.1388541918666
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal wrote:
>
> I don't think this is a good idea -- if a type is going to provide swap,
> normally it must do so in a non-throwing way. I'd worry that people would
> just add it in without thinking only to break normal assumptions of what
> swap does.
>

Maybe, but the defaulted swap calls swap for the members which itself
should already have the non-throwing rule. If your swap has to do something
special that might throw, you would have to write it yourself anyway.


>
> The other issue here is that "using std::swap" would require including
> <algorithm>...
>

Implementing swap yourself in this way requires the same.


>
>

> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Dec 31, 2013 at 5:42 PM, <fmatth...@gmail.com <javascript:>>wrote:
>
>> Writing swap() is one of those boilerplate kinds of things that is
>> usually trivial but annoying (and error prone when you change data members
>> but forget to update swap()).
>>
>> Why not allow this:
>>
>> class Foo {
>>   public:
>>     void swap(Foo& f) = default;
>>   private:
>>     int a;
>>     Bar b;
>>     float c;
>>     Baz* d;
>> };
>>
>> Which would be the equivalent of this:
>>
>> void Foo::swap(Foo& f) {
>>   using std::swap;
>>   swap(a, f.a);
>>   swap(b, f.b);
>>   swap(c, f.c);
>>   swap(d, f.d);
>> }
>>
>> Any reason this wouldn't make it as a proposal?
>>
>> --
>>
>> ---
>> 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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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/.

------=_Part_4695_25600600.1388541918666
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy =
O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I don't think this is a good idea -- if a type is going to provide swap, no=
rmally it must do so in a non-throwing way. I'd worry that people would jus=
t add it in without thinking only to break normal assumptions of what swap =
does.</div></blockquote><div><br></div><div><span style=3D"font-size: 13px;=
">Maybe, but the defaulted swap calls swap for the members which itself sho=
uld already have the non-throwing rule. If your swap has to do something sp=
ecial that might throw, you would have to write it yourself anyway.</span><=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>

<br></div><div>The other issue here is that "using std::swap" would require=
 including &lt;algorithm&gt;...</div></div></blockquote><div><br></div><div=
>Implementing swap yourself in this way requires the same.</div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><s=
pan style=3D"font-size: 13px;">&nbsp;</span></div></div></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div><br clear=3D"all"><div><div dir=
=3D"ltr"><div>Billy O'Neal</div><div>

<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fbitbucket.org=
%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEUaaIry0cea0l0vX6ztWgwQ=
7_4Lg';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\7=
5https%3A%2F%2Fbitbucket.org%2FBillyONeal%2F\46sa\75D\46sntz\0751\46usg\75A=
FQjCNEUaaIry0cea0l0vX6ztWgwQ7_4Lg';return true;">https://github.com/BillyON=
eal/</a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-on=
eal" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\75http%3A%2F%2Fstackoverflow.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D=
\46sntz\0751\46usg\75AFQjCNHY_gA133vyg0yY-U2PNMVA8cCSBg';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflo=
w.com%2Fusers%2F82320%2Fbilly-oneal\46sa\75D\46sntz\0751\46usg\75AFQjCNHY_g=
A133vyg0yY-U2PNMVA8cCSBg';return true;">http://stackoverflow.com/<wbr>users=
/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 5:42 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"sUShiWNYUcMJ" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">fmatth...@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">

<div dir=3D"ltr">Writing swap() is one of those boilerplate kinds of things=
 that is usually trivial but annoying (and error prone when you change data=
 members but forget to update swap()).<div><br></div><div>Why not allow thi=
s:</div>

<div><br></div><div>class Foo {</div><div>&nbsp; public:</div><div>&nbsp; &=
nbsp; void swap(Foo&amp; f) =3D default;</div><div>&nbsp; private:</div><di=
v>&nbsp; &nbsp; int a;</div><div>&nbsp; &nbsp; Bar b;</div><div>&nbsp; &nbs=
p; float c;</div><div>&nbsp; &nbsp; Baz* d;</div><div>};</div>

<div><br></div><div>Which would be the equivalent of this:</div><div><br></=
div><div>void Foo::swap(Foo&amp; f) {<br>&nbsp; using std::swap;</div><div>=
&nbsp; swap(a, f.a);</div><div>&nbsp; swap(b, f.b);</div><div>&nbsp; swap(c=
, f.c);</div><div>

&nbsp; swap(d, f.d);</div><div>}</div><div><br></div><div>Any reason this w=
ouldn't make it as a proposal?</div></div><span><font color=3D"#888888">

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
sUShiWNYUcMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"sUShiWNYUcMJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4695_25600600.1388541918666--

.

On 2013-12-31 21:05, fmatthew5876@gmail.com wrote:
> On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal wrote:
>> The other issue here is that "using std::swap" would require including
>> <algorithm>...
>
> Implementing swap yourself in this way requires the same.

I think the problem here is that the *header* would need to include it.

Related to that note, I wonder if we should allow e.g.:

foo.h
-----
class Foo
{
   ...
   ~Foo();
   ...
}

foo.cpp
-------

Foo::~Foo() = default;


IOW, allow uses of '= default' after declaration, to allow the compiler
to emit the default implementation at the source level rather than the
header level. This would be great for classes where the default
implementation would require a complete declaration of a type that
otherwise could be forward declared. (Especially thinking of
'unique_ptr<Private>', for which the dtor needs the definition of
Private, but otherwise Private could be forward declared.)

In this case, this would solve needing <algorithm> in the header.

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

.

Matthew Woehlke skrev 2014-01-01 16:26:
> On 2013-12-31 21:05, fmatthew5876@gmail.com wrote:
>> On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal wrote:
>>> The other issue here is that "using std::swap" would require including
>>> <algorithm>...
>>
>> Implementing swap yourself in this way requires the same.
>
> I think the problem here is that the *header* would need to include it.
>
> Related to that note, I wonder if we should allow e.g.:
>
> foo.h
> -----
> class Foo
> {
>    ...
>    ~Foo();
>    ...
> }
>
> foo.cpp
> -------
>
> Foo::~Foo() = default;
>
>
> IOW, allow uses of '= default' after declaration, to allow the compiler
> to emit the default implementation at the source level rather than the
> header level. This would be great for classes where the default
> implementation would require a complete declaration of a type that
> otherwise could be forward declared. (Especially thinking of
> 'unique_ptr<Private>', for which the dtor needs the definition of
> Private, but otherwise Private could be forward declared.)
>
> In this case, this would solve needing <algorithm> in the header.
>

But wouldn't this instead cause trouble for <type_traits>, like
is_trivially_destructible<Foo> ?


Bo Persson


--

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

.

--001a11c3560c073fb004eeeb5909
Content-Type: text/plain; charset=ISO-8859-1

On Wed Jan 01 2014 at 16:26:22, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Related to that note, I wonder if we should allow e.g.:
>
> foo.h
> -----
> class Foo
> {
>    ...
>    ~Foo();
>    ...
> }
>
> foo.cpp
> -------
>
> Foo::~Foo() = default;
>
>
> IOW, allow uses of '= default' after declaration, to allow the compiler
> to emit the default implementation at the source level rather than the
> header level.
>

Huh? I'm pretty sure this is already allowed.

--

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

--001a11c3560c073fb004eeeb5909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div>On Wed Jan 01 2014 at 16:26:22, Matthew Woehlke &lt;<a href=3D=
"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
Related to that note, I wonder if we should allow e.g.:<br>
<br>
foo.h<br>
-----<br>
class Foo<br>
{<br>
=A0 =A0...<br>
=A0 =A0~Foo();<br>
=A0 =A0...<br>
}<br>
<br>
foo.cpp<br>
-------<br>
<br>
Foo::~Foo() =3D default;<br>
<br>
<br>
IOW, allow uses of &#39;=3D default&#39; after declaration, to allow the co=
mpiler<br>
to emit the default implementation at the source level rather than the<br>
header level.<br></blockquote><div><br></div><div>Huh? I&#39;m pretty sure =
this is already allowed.=A0</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3560c073fb004eeeb5909--

.

On 2014-01-01 11:07, Bo Persson wrote:
> Matthew Woehlke skrev 2014-01-01 16:26:
>> On 2013-12-31 21:05, fmatthew5876@gmail.com wrote:
>>> On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal wrote:
>>>> The other issue here is that "using std::swap" would require including
>>>> <algorithm>...
>>>
>>> Implementing swap yourself in this way requires the same.
>>
>> I think the problem here is that the *header* would need to include it.
>>
>> Related to that note, I wonder if we should allow e.g.:
>>
>> foo.h
>> -----
>> class Foo
>> {
>>    ...
>>    ~Foo();
>>    ...
>> }
>>
>> foo.cpp
>> -------
>>
>> Foo::~Foo() = default;
>>
>>
>> IOW, allow uses of '= default' after declaration, to allow the compiler
>> to emit the default implementation at the source level rather than the
>> header level. This would be great for classes where the default
>> implementation would require a complete declaration of a type that
>> otherwise could be forward declared. (Especially thinking of
>> 'unique_ptr<Private>', for which the dtor needs the definition of
>> Private, but otherwise Private could be forward declared.)
>>
>> In this case, this would solve needing <algorithm> in the header.
>>
>
> But wouldn't this instead cause trouble for <type_traits>, like
> is_trivially_destructible<Foo> ?

I don't know. From a conceptual standpoint, in practice, I don't think
it should; a default dtor defined in the .cpp would necessarily be
defined as not "trivial". (In practice, you'd be doing this because one
of the members has a dtor that involves knowledge of the definition of
some class/struct - in the original example, in order to 'delete' it -
which IIUC means you're dealing with a non-trivial dtor regardless. IOW,
in practice, if you are defining a default dtor at the .cpp level it is
because it is already non-trivial, so forcing it to be considered
non-trivial because it is defined in the .cpp is no loss.)

I don't know enough about the implementation of
is_trivially_destructible to know about that, but I would think it
wouldn't be affected.

IOW, this:

Foo::~Foo() = default

....should be exactly equivalent to this:

Foo::~Foo() {}

....which is to say that the effect is just that the compiler generates
the body, but it is otherwise semantically equivalent to if the
programmer had provided a definition.

(The dtor is perhaps not the best example, as the '= default' body is I
think the same as '{}' in all cases. It's more interesting for e.g. copy
ctor, which would have a non-trivial body. Keeping in mind that the
proposal is for *any* default-able member to be "defined" at the .cpp
level.)

Come to think of it, I'm pretty sure I've run into exactly this before,
i.e. having to define a "custom" ctor when I really want the default
just because use of forward declarations means the compiler lacks
sufficient information to compiler the default definition at the header
level.

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

.

On 2014-01-01 11:41, Philipp Maximilian Stephani wrote:
> On Wed Jan 01 2014 at 16:26:22, Matthew Woehlke <mwoehlke.floss@gmail.com>
> wrote:
>
>> Related to that note, I wonder if we should allow e.g.:
>>
>> foo.h
>> -----
>> class Foo
>> {
>>     ...
>>     ~Foo();
>>     ...
>> }
>>
>> foo.cpp
>> -------
>>
>> Foo::~Foo() = default;
>>
>>
>> IOW, allow uses of '= default' after declaration, to allow the compiler
>> to emit the default implementation at the source level rather than the
>> header level.
>>
>
> Huh? I'm pretty sure this is already allowed.

Hmm... gcc at least seems to allow it :-D. I guess I assumed it wasn't,
as I cant recall that any of the 'what's new in C++11' I've read
mentioned it...

Well, that's pretty nice.

--
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_0_1388599989326
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline

That would be inconsistent with other uses of "= default", which are not considered user-provided.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Matthew Woehlke" <mwoehlke.floss@gmail.com>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Re: Proposal: Default swap operation
Date: Wed, Jan 1, 2014 9:51 AM

On 2014-01-01 11:07, Bo Persson wrote:
> Matthew Woehlke skrev 2014-01-01 16:26:
>> On 2013-12-31 21:05, fmatthew5876@gmail.com wrote:
>>> On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal wrote:
>>>> The other issue here is that "using std::swap" would require including
>>>> <algorithm>...
>>>
>>> Implementing swap yourself in this way requires the same.
>>
>> I think the problem here is that the *header* would need to include it.
>>
>> Related to that note, I wonder if we should allow e.g.:
>>
>> foo.h
>> -----
>> class Foo
>> {
>>    ...
>>    ~Foo();
>>    ...
>> }
>>
>> foo.cpp
>> -------
>>
>> Foo::~Foo() = default;
>>
>>
>> IOW, allow uses of '= default' after declaration, to allow the compiler
>> to emit the default implementation at the source level rather than the
>> header level. This would be great for classes where the default
>> implementation would require a complete declaration of a type that
>> otherwise could be forward declared. (Especially thinking of
>> 'unique_ptr<Private>', for which the dtor needs the definition of
>> Private, but otherwise Private could be forward declared.)
>>
>> In this case, this would solve needing <algorithm> in the header.
>>
>
> But wouldn't this instead cause trouble for <type_traits>, like
> is_trivially_destructible<Foo> ?

I don't know. From a conceptual standpoint, in practice, I don't think
it should; a default dtor defined in the .cpp would necessarily be
defined as not "trivial". (In practice, you'd be doing this because one
of the members has a dtor that involves knowledge of the definition of
some class/struct - in the original example, in order to 'delete' it -
which IIUC means you're dealing with a non-trivial dtor regardless. IOW,
in practice, if you are defining a default dtor at the .cpp level it is
because it is already non-trivial, so forcing it to be considered
non-trivial because it is defined in the .cpp is no loss.)

I don't know enough about the implementation of
is_trivially_destructible to know about that, but I would think it
wouldn't be affected.

IOW, this:

Foo::~Foo() = default

....should be exactly equivalent to this:

Foo::~Foo() {}

....which is to say that the effect is just that the compiler generates
the body, but it is otherwise semantically equivalent to if the
programmer had provided a definition.

(The dtor is perhaps not the best example, as the '= default' body is I
think the same as '{}' in all cases. It's more interesting for e.g. copy
ctor, which would have a non-trivial body. Keeping in mind that the
proposal is for *any* default-able member to be "defined" at the .cpp
level.)

Come to think of it, I'm pretty sure I've run into exactly this before,
i.e. having to define a "custom" ctor when I really want the default
just because use of forward declarations means the compiler lacks
sufficient information to compiler the default definition at the header
level.

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

--

---
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_0_1388599989326
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head></head><body><div style=3D"font-size: 12pt; font-family: Calibr=
i,sans-serif;"><div>That would be inconsistent with other uses of "=3D defa=
ult", which are not considered user-provided.</div><div><br></div><div>Sent=
 from a touchscreen. Please excuse the brevity and tpyos.</div><br><div id=
=3D"htc_header">----- Reply message -----<br>From: &quot;Matthew Woehlke&qu=
ot; &lt;mwoehlke.floss@gmail.com&gt;<br>To: &lt;std-proposals@isocpp.org&gt=
;<br>Subject: [std-proposals] Re: Proposal: Default swap operation<br>Date:=
 Wed, Jan 1, 2014 9:51 AM</div></div><br><pre style=3D"word-wrap: break-wor=
d; white-space: pre-wrap;">On 2014-01-01 11:07, Bo Persson wrote:
&gt; Matthew Woehlke skrev 2014-01-01 16:26:
&gt;&gt; On 2013-12-31 21:05, fmatthew5876@gmail.com wrote:
&gt;&gt;&gt; On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal w=
rote:
&gt;&gt;&gt;&gt; The other issue here is that "using std::swap" would requi=
re including
&gt;&gt;&gt;&gt; &lt;algorithm&gt;...
&gt;&gt;&gt;
&gt;&gt;&gt; Implementing swap yourself in this way requires the same.
&gt;&gt;
&gt;&gt; I think the problem here is that the *header* would need to includ=
e it.
&gt;&gt;
&gt;&gt; Related to that note, I wonder if we should allow e.g.:
&gt;&gt;
&gt;&gt; foo.h
&gt;&gt; -----
&gt;&gt; class Foo
&gt;&gt; {
&gt;&gt;    ...
&gt;&gt;    ~Foo();
&gt;&gt;    ...
&gt;&gt; }
&gt;&gt;
&gt;&gt; foo.cpp
&gt;&gt; -------
&gt;&gt;
&gt;&gt; Foo::~Foo() =3D default;
&gt;&gt;
&gt;&gt;
&gt;&gt; IOW, allow uses of '=3D default' after declaration, to allow the c=
ompiler
&gt;&gt; to emit the default implementation at the source level rather than=
 the
&gt;&gt; header level. This would be great for classes where the default
&gt;&gt; implementation would require a complete declaration of a type that
&gt;&gt; otherwise could be forward declared. (Especially thinking of
&gt;&gt; 'unique_ptr&lt;Private&gt;', for which the dtor needs the definiti=
on of
&gt;&gt; Private, but otherwise Private could be forward declared.)
&gt;&gt;
&gt;&gt; In this case, this would solve needing &lt;algorithm&gt; in the he=
ader.
&gt;&gt;
&gt;
&gt; But wouldn't this instead cause trouble for &lt;type_traits&gt;, like
&gt; is_trivially_destructible&lt;Foo&gt; ?

I don't know. From a conceptual standpoint, in practice, I don't think=20
it should; a default dtor defined in the .cpp would necessarily be=20
defined as not "trivial". (In practice, you'd be doing this because one=20
of the members has a dtor that involves knowledge of the definition of=20
some class/struct - in the original example, in order to 'delete' it -=20
which IIUC means you're dealing with a non-trivial dtor regardless. IOW,=20
in practice, if you are defining a default dtor at the .cpp level it is=20
because it is already non-trivial, so forcing it to be considered=20
non-trivial because it is defined in the .cpp is no loss.)

I don't know enough about the implementation of=20
is_trivially_destructible to know about that, but I would think it=20
wouldn't be affected.

IOW, this:

Foo::~Foo() =3D default

....should be exactly equivalent to this:

Foo::~Foo() {}

....which is to say that the effect is just that the compiler generates=20
the body, but it is otherwise semantically equivalent to if the=20
programmer had provided a definition.

(The dtor is perhaps not the best example, as the '=3D default' body is I=
=20
think the same as '{}' in all cases. It's more interesting for e.g. copy=20
ctor, which would have a non-trivial body. Keeping in mind that the=20
proposal is for *any* default-able member to be "defined" at the .cpp=20
level.)

Come to think of it, I'm pretty sure I've run into exactly this before,=20
i.e. having to define a "custom" ctor when I really want the default=20
just because use of forward declarations means the compiler lacks=20
sufficient information to compiler the default definition at the header=20
level.

--=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 <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/.">http://groups.google.com/a/isocpp.org/group/std-proposals/=
..</a>
</pre></body></html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_0_1388599989326--


.

On 1 January 2014 20:13, billy.oneal@gmail.com <billy.oneal@gmail.com> wrote:
> That would be inconsistent with other uses of "= default", which are not
> considered user-provided.

What "that"? A function defaulted in its first declaration is not
user-provided. A function defaulted
after its first declaration is user-provided (and thus never trivial).

>
> Sent from a touchscreen. Please excuse the brevity and tpyos.
>
> ----- Reply message -----
> From: "Matthew Woehlke" <mwoehlke.floss@gmail.com>
> To: <std-proposals@isocpp.org>
> Subject: [std-proposals] Re: Proposal: Default swap operation
> Date: Wed, Jan 1, 2014 9:51 AM
>
> On 2014-01-01 11:07, Bo Persson wrote:
>> Matthew Woehlke skrev 2014-01-01 16:26:
>>> On 2013-12-31 21:05, fmatthew5876@gmail.com
>  wrote:
>>>> On Tuesday, December 31, 2013 8:53:46 PM UTC-5, Billy O'Neal wrote:
>>>>> The other issue here is that "using std::swap" would require including
>>>>> <algorithm>...
>>>>
>>>> Implementing swap yourself in this way requires the same.
>>>
>>> I think the problem here is that the *header* would need to include it.
>>>
>>> Related to that note, I wonder if we should allow e.g.:
>>>
>>> foo.h
>>> -----
>>> class Foo
>>> {
>>>    ...
>>>    ~Foo();
>>>    ...
>>> }
>>>
>>> foo.cpp
>>> -------
>>>
>>> Foo::~Foo() = default;
>>>
>>>
>>> IOW, allow uses of '= default' after declaration, to allow the compiler
>>> to emit the default implementation at the source level rather than the
>>> header level. This would be great for classes where the default
>>> implementation would require a complete declaration of a type that
>>> otherwise could be forward declared. (Especially thinking of
>>> 'unique_ptr<Private>', for which the dtor needs the definition of
>>> Private, but otherwise Private could be forward declared.)
>>>
>>> In this case, this would solve needing <algorithm> in the header.
>>>
>>
>> But wouldn't this instead cause trouble for <type_traits>, like
>> is_trivially_destructible<Foo> ?
>
> I don't know. From a conceptual standpoint, in practice, I don't think
> it should; a default dtor defined in the .cpp would necessarily be
> defined as not "trivial". (In practice, you'd be doing this because one
> of the members has a dtor that involves knowledge of the definition of
> some class/struct - in the original example, in order to 'delete' it -
> which IIUC means you're dealing with a non-trivial dtor regardless. IOW,
> in practice, if you are defining a default dtor at the .cpp level it is
> because it is already non-trivial, so forcing it to be considered
> non-trivial because it is defined in the .cpp is no loss.)
>
> I don't know enough about the implementation of
> is_trivially_destructible to know about that, but I would think it
> wouldn't be affected.
>
> IOW, this:
>
> Foo::~Foo() = default
>
> ...should be exactly equivalent to this:
>
> Foo::~Foo() {}
>
> ...which is to say that the effect is just that the compiler generates
> the body, but it is otherwise semantically equivalent to if the
> programmer had provided a definition.
>
> (The dtor is perhaps not the best example, as the '= default' body is I
> think the same as '{}' in all cases. It's more interesting for e.g. copy
> ctor, which would have a non-trivial body. Keeping in mind that the
> proposal is for *any* default-able member to be "defined" at the .cpp
> level.)
>
> Come to think of it, I'm pretty sure I've run into exactly this before,
> i.e. having to define a "custom" ctor when I really want the default
> just because use of forward declarations means the compiler lacks
> sufficient information to compiler the default definition at the header
> level.
>
> --
> 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/.
>
> --
>
> ---
> 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/.

.

On quarta-feira, 1 de janeiro de 2014 10:26:19, Matthew Woehlke wrote:
> Foo::~Foo() = default;

This requires more typing than:

Foo::~Foo() {}

And quite frankly I don't see the benefit. This destructor can't be from other
translation units under the conditions you described. It could be inlined from
the same translation unit, which the above accomplishes.

This destructor cannot be trivial either under your condition: if all of them
were trivial, then you could have left the declaration in the header.

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

.

On quarta-feira, 1 de janeiro de 2014 12:56:21, Matthew Woehlke wrote:
> > Huh? I'm pretty sure this is already allowed.
>
> Hmm... gcc at least seems to allow it :-D. I guess I assumed it wasn't,
> as I cant recall that any of the 'what's new in C++11' I've read
> mentioned it...

It is, but note that it doesn't emit a symbol for other translation units to
see. The program is ill-defined if any translation unit trying to destroy Foo
doesn't see the = default.

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

.

On 2014-01-01 14:23, Thiago Macieira wrote:
> On quarta-feira, 1 de janeiro de 2014 10:26:19, Matthew Woehlke wrote:
>> Foo::~Foo() = default;
>
> This requires more typing than:
>
> Foo::~Foo() {}

True, though it does express intent more clearly :-). However, that
exact point was why I mentioned in the previous mail that the dtor is
not the best example.

(In some pedantic coding styles, '= default;' would be one line where
'{}' would be mandated to be written '\n{\n}', thus 2 more lines :-).)

> And quite frankly I don't see the benefit. This destructor can't be from other
> translation units under the conditions you described.

Yes. This would need to be changed for the idea to be useful. So there
is still something that could be changed here; specifying that '=
default' should make the definition accessible to other translation
units the same as if a user definition had been provided. (If it is not
possible to change the behavior of '= default', then I would propose '=
extern default' instead to explicitly specify that a symbol should be
emitted.)

> This destructor cannot be trivial either under your condition: if all of them
> were trivial, then you could have left the declaration in the header.

Right. If '= default' appears in the .cpp and not in the .h, the
compiler shall (be free to) assume that it is non-trivial. Because in
practice, if you need it in the .cpp and not the .h it is likely
(always?) because it is non-trivial anyway.

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

.

On 1 January 2014 21:24, Thiago Macieira <thiago@macieira.org> wrote:
> On quarta-feira, 1 de janeiro de 2014 12:56:21, Matthew Woehlke wrote:
>> > Huh? I'm pretty sure this is already allowed.
>>
>> Hmm... gcc at least seems to allow it :-D. I guess I assumed it wasn't,
>> as I cant recall that any of the 'what's new in C++11' I've read
>> mentioned it...
>
> It is, but note that it doesn't emit a symbol for other translation units to
> see. The program is ill-defined if any translation unit trying to destroy Foo
> doesn't see the = default.


I don't see any wording in the standard that would require other TUs to
see the =default to use the function.

--

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

.

On 2014-01-01 14:53, Ville Voutilainen wrote:
> On 1 January 2014 21:24, Thiago Macieira <thiago@macieira.org> wrote:
>> On quarta-feira, 1 de janeiro de 2014 12:56:21, Matthew Woehlke wrote:
>>>> Huh? I'm pretty sure this is already allowed.
>>>
>>> Hmm... gcc at least seems to allow it :-D. I guess I assumed it wasn't,
>>> as I cant recall that any of the 'what's new in C++11' I've read
>>> mentioned it...
>>
>> It is, but note that it doesn't emit a symbol for other translation units to
>> see. The program is ill-defined if any translation unit trying to destroy Foo
>> doesn't see the = default.
>
>
> I don't see any wording in the standard that would require other TUs to
> see the =default to use the function.

I'm inclined to agree. I didn't consult the spec, but when I tried using
it in a project, I am not seeing link errors that I would expect if the
definition wasn't available to other TU's. (And I *do* see link errors
if I omit the dtor definition entirely, so the dtor is definitely being
referenced.)

I'd also be curious about your reading of the spec. It may be that
technically such a program is ill-formed, but existing compilers (or at
least gcc) "DTRT" (i.e. behave in the desired manner) anyway?

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

.

On 1 January 2014 23:29, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2014-01-01 14:53, Ville Voutilainen wrote:
>> I don't see any wording in the standard that would require other TUs to
>> see the =default to use the function.
>
>
> I'm inclined to agree. I didn't consult the spec, but when I tried using it
> in a project, I am not seeing link errors that I would expect if the
> definition wasn't available to other TU's. (And I *do* see link errors if I
> omit the dtor definition entirely, so the dtor is definitely being
> referenced.)
>
> I'd also be curious about your reading of the spec. It may be that
> technically such a program is ill-formed, but existing compilers (or at
> least gcc) "DTRT" (i.e. behave in the desired manner) anyway?


I have no reason to believe a program that defaults a special member
after the first declaration is in any way ill-formed, quite the contrary.
And I have no reason to believe such a definition wouldn't be accessible
to other TUs. Both of these statements are based on my reading of the
spec, it specifically allows defaulting after first declaration, and there's
nothing saying such a definition is in any way static.

--

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

.

On 2014-01-01 16:48, Ville Voutilainen wrote:
> On 1 January 2014 23:29, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2014-01-01 14:53, Ville Voutilainen wrote:
>>> I don't see any wording in the standard that would require other TUs to
>>> see the =default to use the function.
>>
>>
>> I'm inclined to agree. I didn't consult the spec, but when I tried using it
>> in a project, I am not seeing link errors that I would expect if the
>> definition wasn't available to other TU's. (And I *do* see link errors if I
>> omit the dtor definition entirely, so the dtor is definitely being
>> referenced.)
>>
>> I'd also be curious about your reading of the spec. It may be that
>> technically such a program is ill-formed, but existing compilers (or at
>> least gcc) "DTRT" (i.e. behave in the desired manner) anyway?
>
>
> I have no reason to believe a program that defaults a special member
> after the first declaration is in any way ill-formed, quite the contrary.
> And I have no reason to believe such a definition wouldn't be accessible
> to other TUs. Both of these statements are based on my reading of the
> spec, it specifically allows defaulting after first declaration, and there's
> nothing saying such a definition is in any way static.

Right. Thiago, do we convince you? If not, would you kindly explain your
take? (And/or does anyone know of any compilers that don't behave this way?)

Thanks,

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

.

--047d7b5d2ea4c6980d04eef09e29
Content-Type: text/plain; charset=ISO-8859-1

[quote]
What "that"? A function defaulted in its first declaration is not
user-provided. A function defaulted after its first declaration is
user-provided (and thus never trivial).
[/quote]
Whoops, I misunderstood that bit. :)

[quote]
I don't see any wording in the standard that would require other TUs to see
the =default to use the function.
[/quote]
The wording is that when a translation unit doesn't see a default
constructor for a class, one is defined as an inline public member of that
class. When you define the member outside of the class that way, you are
not doing it inline. Thus, this breaks ODR.

If the default constructor is declared in the class definition though, I
think it may be fine, though I haven't found anything specific in the spec
to confirm or deny this.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Jan 1, 2014 at 2:02 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>wrote:

> On 2014-01-01 16:48, Ville Voutilainen wrote:
>
>> On 1 January 2014 23:29, Matthew Woehlke <mwoehlke.floss@gmail.com>
>> wrote:
>>
>>> On 2014-01-01 14:53, Ville Voutilainen wrote:
>>>
>>>> I don't see any wording in the standard that would require other TUs to
>>>> see the =default to use the function.
>>>>
>>>
>>>
>>> I'm inclined to agree. I didn't consult the spec, but when I tried using
>>> it
>>> in a project, I am not seeing link errors that I would expect if the
>>> definition wasn't available to other TU's. (And I *do* see link errors
>>> if I
>>> omit the dtor definition entirely, so the dtor is definitely being
>>> referenced.)
>>>
>>> I'd also be curious about your reading of the spec. It may be that
>>> technically such a program is ill-formed, but existing compilers (or at
>>> least gcc) "DTRT" (i.e. behave in the desired manner) anyway?
>>>
>>
>>
>> I have no reason to believe a program that defaults a special member
>> after the first declaration is in any way ill-formed, quite the contrary.
>> And I have no reason to believe such a definition wouldn't be accessible
>> to other TUs. Both of these statements are based on my reading of the
>> spec, it specifically allows defaulting after first declaration, and
>> there's
>> nothing saying such a definition is in any way static.
>>
>
> Right. Thiago, do we convince you? If not, would you kindly explain your
> take? (And/or does anyone know of any compilers that don't behave this way?)
>
> Thanks,
>
> --
> 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/.
>

--

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

--047d7b5d2ea4c6980d04eef09e29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>[quote]<br>What &quot;that&quot;? A function defaulted =
in its first declaration is not user-provided. A function defaulted after i=
ts first declaration is user-provided (and thus never trivial).<br>[/quote]=
<br>

Whoops, I misunderstood that bit. :)</p><p>[quote]<br>I don&#39;t see any w=
ording in the standard that would require other TUs to see the =3Ddefault t=
o use the function.<br>[/quote]<br>The wording is that when a translation u=
nit doesn&#39;t see a default constructor for a class, one is defined as an=
 inline public member of that class. When you define the member outside of =
the class that way, you are not doing it inline. Thus, this breaks ODR.</p>

<p>If the default constructor is declared in the class definition though, I=
 think it may be fine, though I haven&#39;t found anything specific in the =
spec to confirm or deny this.</p></div><div class=3D"gmail_extra"><br clear=
=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jan 1, 2014 at 2:02 PM, Matthew =
Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" t=
arget=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div class=3D"im">On 2014-01-01 16:48, Ville Voutilainen 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-l=
eft-style:solid">
On 1 January 2014 23:29, Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.flo=
ss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt; 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-l=
eft-style:solid">
On 2014-01-01 14:53, Ville Voutilainen 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-l=
eft-style:solid">
I don&#39;t see any wording in the standard that would require other TUs to=
<br>
see the =3Ddefault to use the function.<br>
</blockquote>
<br>
<br>
I&#39;m inclined to agree. I didn&#39;t consult the spec, but when I tried =
using it<br>
in a project, I am not seeing link errors that I would expect if the<br>
definition wasn&#39;t available to other TU&#39;s. (And I *do* see link err=
ors if I<br>
omit the dtor definition entirely, so the dtor is definitely being<br>
referenced.)<br>
<br>
I&#39;d also be curious about your reading of the spec. It may be that<br>
technically such a program is ill-formed, but existing compilers (or at<br>
least gcc) &quot;DTRT&quot; (i.e. behave in the desired manner) anyway?<br>
</blockquote>
<br>
<br>
I have no reason to believe a program that defaults a special member<br>
after the first declaration is in any way ill-formed, quite the contrary.<b=
r>
And I have no reason to believe such a definition wouldn&#39;t be accessibl=
e<br>
to other TUs. Both of these statements are based on my reading of the<br>
spec, it specifically allows defaulting after first declaration, and there&=
#39;s<br>
nothing saying such a definition is in any way static.<br>
</blockquote>
<br></div>
Right. Thiago, do we convince you? If not, would you kindly explain your ta=
ke? (And/or does anyone know of any compilers that don&#39;t behave this wa=
y?)<br>
<br>
Thanks,<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Matthew</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 Grou=
ps &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@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d2ea4c6980d04eef09e29--

.

--001a11c2903c10f1c304eef1d7f8
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 1, 2014 at 2:42 AM, <fmatthew5876@gmail.com> wrote:

> Writing swap() is one of those boilerplate kinds of things that is usually
> trivial but annoying (and error prone when you change data members but
> forget to update swap()).
>
> Why not allow this:
>
> class Foo {
>   public:
>     void swap(Foo& f) = default;
>   private:
>     int a;
>     Bar b;
>     float c;
>     Baz* d;
> };
>
> Which would be the equivalent of this:
>
> void Foo::swap(Foo& f) {
>   using std::swap;
>   swap(a, f.a);
>   swap(b, f.b);
>   swap(c, f.c);
>   swap(d, f.d);
> }
>
> Any reason this wouldn't make it as a proposal?
>

How would this differ from the swap operator proposal? [1]
I don't remember if a discussion about this paper happened around here or
if someone talked about how it was received by the committee.


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf

--

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

--001a11c2903c10f1c304eef1d7f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jan 1, 2014 at 2:42 AM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Writing swap() is one of those boilerplat=
e kinds of things that is usually trivial but annoying (and error prone whe=
n you change data members but forget to update swap()).<div>
<br></div><div>Why not allow this:</div><div><br></div><div>class Foo {</di=
v><div>=A0 public:</div><div>=A0 =A0 void swap(Foo&amp; f) =3D default;</di=
v><div>=A0 private:</div><div>=A0 =A0 int a;</div><div>=A0 =A0 Bar b;</div>=
<div>=A0 =A0 float c;</div>
<div>=A0 =A0 Baz* d;</div><div>};</div><div><br></div><div>Which would be t=
he equivalent of this:</div><div><br></div><div>void Foo::swap(Foo&amp; f) =
{<br>=A0 using std::swap;</div><div>=A0 swap(a, f.a);</div><div>=A0 swap(b,=
 f.b);</div>
<div>=A0 swap(c, f.c);</div><div>=A0 swap(d, f.d);</div><div>}</div><div><b=
r></div><div>Any reason this wouldn&#39;t make it as a proposal?</div></div=
></blockquote><div><br></div><div>How would this differ from the swap opera=
tor proposal? [1]</div>
<div>I don&#39;t remember if a discussion about this paper happened around =
here or if someone talked about how it was received by the committee.</div>=
<div><br></div><div><br></div><div>[1] <a href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2013/n3746.pdf">http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2013/n3746.pdf</a></div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2903c10f1c304eef1d7f8--

.

On quarta-feira, 1 de janeiro de 2014 17:02:51, Matthew Woehlke wrote:
> Right. Thiago, do we convince you? If not, would you kindly explain your
> take? (And/or does anyone know of any compilers that don't behave this way?)

I didn't check the spec either, I was quoting from memory. I must be confusing
with something else that causes ill-forming.

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

.

--nextPart1751862.VONXlpbYM5
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On quarta-feira, 1 de janeiro de 2014 14:41:33, Matthew Woehlke wrote:
> > And quite frankly I don't see the benefit. This destructor can't be from
> > other translation units under the conditions you described.
>
> Yes. This would need to be changed for the idea to be useful. So there
> is still something that could be changed here; specifying that '=
> default' should make the definition accessible to other translation
> units the same as if a user definition had been provided. (If it is not
> possible to change the behavior of '= default', then I would propose '=
> extern default' instead to explicitly specify that a symbol should be
> emitted.)

This part of the discussion was probably wrong on my part.

> > This destructor cannot be trivial either under your condition: if all of
> > them were trivial, then you could have left the declaration in the
> > header.
> Right. If '= default' appears in the .cpp and not in the .h, the
> compiler shall (be free to) assume that it is non-trivial. Because in
> practice, if you need it in the .cpp and not the .h it is likely
> (always?) because it is non-trivial anyway.

But this one is still right. This may be allowed, but I don't see the point in
doing it this way, since the code produced will be exactly the same.

You may disagree with me here, but whenever two syntaxes produce the exactly
same thing with no overhead and no difference in readability, I'd choose the
older syntax.

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

--nextPart1751862.VONXlpbYM5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBSxLo9M/XwBW70U1gRAsnPAKC2amKCC3WfnBELgfsE7xMKhRmM5ACfa1aO
JTGTgXt/rNc2NkTDc6my8JA=
=rHNW
-----END PGP SIGNATURE-----

--nextPart1751862.VONXlpbYM5--


.

On Jan 1, 2014, at 8:00 PM, Thiago Macieira <thiago@macieira.org> wrote:

> On quarta-feira, 1 de janeiro de 2014 14:41:33, Matthew Woehlke wrote:
>>> And quite frankly I don't see the benefit. This destructor can't be from
>>> other translation units under the conditions you described.
>>
>> Yes. This would need to be changed for the idea to be useful. So there
>> is still something that could be changed here; specifying that '=
>> default' should make the definition accessible to other translation
>> units the same as if a user definition had been provided. (If it is not
>> possible to change the behavior of '= default', then I would propose '=
>> extern default' instead to explicitly specify that a symbol should be
>> emitted.)
>
> This part of the discussion was probably wrong on my part.
>
>>> This destructor cannot be trivial either under your condition: if all of
>>> them were trivial, then you could have left the declaration in the
>>> header.
>> Right. If '= default' appears in the .cpp and not in the .h, the
>> compiler shall (be free to) assume that it is non-trivial. Because in
>> practice, if you need it in the .cpp and not the .h it is likely
>> (always?) because it is non-trivial anyway.
>
> But this one is still right. This may be allowed, but I don't see the point in
> doing it this way, since the code produced will be exactly the same.
>
> You may disagree with me here, but whenever two syntaxes produce the exactly
> same thing with no overhead and no difference in readability, I'd choose the
> older syntax.

Is it me, or does the subject of this thread seem completely unrelated to the subject line in the mail (for the vast majority of posts in this thread)?

Howard

--

---
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_636_28550004.1388629993893
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, January 1, 2014 8:23:01 PM UTC-5, Howard Hinnant wrote:
>
> On Jan 1, 2014, at 8:00 PM, Thiago Macieira <thi...@macieira.org<javascript:>>
> wrote:
>
> > On quarta-feira, 1 de janeiro de 2014 14:41:33, Matthew Woehlke wrote:
> >>> And quite frankly I don't see the benefit. This destructor can't be
> from
> >>> other translation units under the conditions you described.
> >>
> >> Yes. This would need to be changed for the idea to be useful. So there
> >> is still something that could be changed here; specifying that '=
> >> default' should make the definition accessible to other translation
> >> units the same as if a user definition had been provided. (If it is not
> >> possible to change the behavior of '= default', then I would propose '=
> >> extern default' instead to explicitly specify that a symbol should be
> >> emitted.)
> >
> > This part of the discussion was probably wrong on my part.
> >
> >>> This destructor cannot be trivial either under your condition: if all
> of
> >>> them were trivial, then you could have left the declaration in the
> >>> header.
> >> Right. If '= default' appears in the .cpp and not in the .h, the
> >> compiler shall (be free to) assume that it is non-trivial. Because in
> >> practice, if you need it in the .cpp and not the .h it is likely
> >> (always?) because it is non-trivial anyway.
> >
> > But this one is still right. This may be allowed, but I don't see the
> point in
> > doing it this way, since the code produced will be exactly the same.
> >
> > You may disagree with me here, but whenever two syntaxes produce the
> exactly
> > same thing with no overhead and no difference in readability, I'd choose
> the
> > older syntax.
>
> Is it me, or does the subject of this thread seem completely unrelated to
> the subject line in the mail (for the vast majority of posts in this
> thread)?
>
>
It has. Everyone, can we get back on topic with the idea of a defaulted
swap operator?


> Howard
>
>

--

---
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_636_28550004.1388629993893
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, January 1, 2014 8:23:01 PM UTC-5, Ho=
ward Hinnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Jan 1, 2=
014, at 8:00 PM, Thiago Macieira &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"k_5pTxZtkcMJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">t=
hi...@macieira.org</a>&gt; wrote:
<br>
<br>&gt; On quarta-feira, 1 de janeiro de 2014 14:41:33, Matthew Woehlke wr=
ote:
<br>&gt;&gt;&gt; And quite frankly I don't see the benefit. This destructor=
 can't be from
<br>&gt;&gt;&gt; other translation units under the conditions you described=
..
<br>&gt;&gt;=20
<br>&gt;&gt; Yes. This would need to be changed for the idea to be useful. =
So there
<br>&gt;&gt; is still something that could be changed here; specifying that=
 '=3D
<br>&gt;&gt; default' should make the definition accessible to other transl=
ation
<br>&gt;&gt; units the same as if a user definition had been provided. (If =
it is not
<br>&gt;&gt; possible to change the behavior of '=3D default', then I would=
 propose '=3D
<br>&gt;&gt; extern default' instead to explicitly specify that a symbol sh=
ould be
<br>&gt;&gt; emitted.)
<br>&gt;=20
<br>&gt; This part of the discussion was probably wrong on my part.
<br>&gt;=20
<br>&gt;&gt;&gt; This destructor cannot be trivial either under your condit=
ion: if all of
<br>&gt;&gt;&gt; them were trivial, then you could have left the declaratio=
n in the
<br>&gt;&gt;&gt; header.
<br>&gt;&gt; Right. If '=3D default' appears in the .cpp and not in the .h,=
 the
<br>&gt;&gt; compiler shall (be free to) assume that it is non-trivial. Bec=
ause in
<br>&gt;&gt; practice, if you need it in the .cpp and not the .h it is like=
ly
<br>&gt;&gt; (always?) because it is non-trivial anyway.
<br>&gt;=20
<br>&gt; But this one is still right. This may be allowed, but I don't see =
the point in=20
<br>&gt; doing it this way, since the code produced will be exactly the sam=
e.
<br>&gt;=20
<br>&gt; You may disagree with me here, but whenever two syntaxes produce t=
he exactly=20
<br>&gt; same thing with no overhead and no difference in readability, I'd =
choose the=20
<br>&gt; older syntax.
<br>
<br>Is it me, or does the subject of this thread seem completely unrelated =
to the subject line in the mail (for the vast majority of posts in this thr=
ead)?
<br>
<br></blockquote><div><br></div><div>It has. Everyone, can we get back on t=
opic with the idea of a defaulted swap operator?</div><div>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">Howard
<br>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_636_28550004.1388629993893--

.

--001a11c2903cee913904eef45606
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 2, 2014 at 3:33 AM, <fmatthew5876@gmail.com> wrote:

> It has. Everyone, can we get back on topic with the idea of a defaulted
> swap operator?


What about my question about N3746?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf
It proposes a swap operator AND a specific behaviour when defaulted (and
also when deleted), for example in 3.4 (n) section.
Doesnt-it match your requirements?

--

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

--001a11c2903cee913904eef45606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jan 2, 2014 at 3:33 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:fm=
atthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">It has. Everyone, can we get back on topic with the idea o=
f a defaulted swap operator?</blockquote>
</div><br>What about my question about N3746?=A0<a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf">http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2013/n3746.pdf</a><br>It proposes a swap operato=
r AND a specific behaviour when defaulted (and also when deleted), for exam=
ple in 3.4 (n) section.<br>
</div><div class=3D"gmail_extra">Doesnt-it match your requirements?</div></=
div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2903cee913904eef45606--

.

------=_Part_7305_12351074.1388653331614
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

1 jan 2014 =C7., 5:42:54 UTC+4 fmatth...@gmail.com:
>
> Writing swap() is one of those boilerplate kinds of things that is usuall=
y=20
> trivial but annoying (and error prone when you change data members but=20
> forget to update swap()).
> [...]
> Any reason this wouldn't make it as a proposal?
>

Compile time reflection is general solution for such kind of problems. It=
=20
would help to remove boilerplate for swap, and for all other cases like=20
hash_value, operator<, operator=3D=3D, etc.
I think we should get compile time reflection first - and check what kind=
=20
of experience it provides.

Here is example: http://coliru.stacked-crooked.com/a/1a1ae88f8b705f3d

--=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_7305_12351074.1388653331614
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">1 jan 2014&nbsp;=C7., 5:42:54 UTC+4 fmatth...@gmail.com:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Writing swap() =
is one of those boilerplate kinds of things that is usually trivial but ann=
oying (and error prone when you change data members but forget to update sw=
ap()).<br>[...]<br><div>Any reason this wouldn't make it as a proposal?</di=
v></div></blockquote><div><br>Compile time reflection is general solution f=
or such kind of problems. It would help to remove boilerplate for swap, and=
 for all other cases like hash_value, operator&lt;, operator=3D=3D, etc.<br=
>I think we should get compile time reflection first - and check what kind =
of experience it provides.<br><br>Here is example: http://coliru.stacked-cr=
ooked.com/a/1a1ae88f8b705f3d<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7305_12351074.1388653331614--

.

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

2 jan 2014 =D0=B3., 7:25:04 UTC+4 Klaim - Jo=C3=ABl Lamotte:

> What about my question about N3746?=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf
>
=20
T& operator :=3D: (T& x, T &y);
Returning T& - is asking for inefficiency. I think variadic "cycle"=20
function is much more suitable.

Usually swap between two values is 3 copy/move assignments.
Swapping of N values using v1 :=3D: v2 :=3D: ... :=3D: vN would require (N-=
1)*3=20
assignments.

But using variadic function it becomes: cycle(v1,v2,...,vN) with N+1=20
assignments. (refer http://www.stepanovpapers.com/notes.pdf)

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

<div dir=3D"ltr">2 jan 2014&nbsp;=D0=B3., 7:25:04 UTC+4 Klaim - Jo=C3=ABl L=
amotte:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>What about my question about N3746?&nbsp;<a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf" target=3D"_blank" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3746.pdf\46sa\75D\46sntz\=
0751\46usg\75AFQjCNEc6qDbPCVLTfRKAMN8Mv1gh6VaiQ';return true;" onclick=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3746.pdf\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNEc6qDbPCVLTfRKAMN8Mv1gh6VaiQ';return true;">http://www.open-st=
d.<wbr>org/jtc1/sc22/wg21/docs/<wbr>papers/2013/n3746.pdf</a></div></div></=
blockquote><div>&nbsp;<br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled=
-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">operator<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">:=3D:</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">y</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></co=
de></div>Returning T&amp; - is asking for inefficiency. I think variadic "c=
ycle" function is much more suitable.<br><br>Usually swap between two value=
s is 3 copy/move assignments.<br>Swapping of N values using v1 :=3D: v2 :=
=3D: ... :=3D: vN would require (N-1)*3 assignments.<br><br>But using varia=
dic function it becomes: cycle(v1,v2,...,vN) with N+1 assignments. (refer h=
ttp://www.stepanovpapers.com/notes.pdf)<br><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7282_2540367.1388653952007--

.

------=_Part_6509_11485628.1388725900376
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I like your idea better, but in the event it is not accepted due to the=20
committee being conservative about new operators, this idea would still be=
=20
useful.

On Wednesday, January 1, 2014 10:25:04 PM UTC-5, Klaim - Jo=EBl Lamotte wro=
te:
>
>
> On Thu, Jan 2, 2014 at 3:33 AM, <fmatth...@gmail.com <javascript:>> wrote=
:
>
>> It has. Everyone, can we get back on topic with the idea of a defaulted=
=20
>> swap operator?
>
>
> What about my question about N3746?=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf
> It proposes a swap operator AND a specific behaviour when defaulted (and=
=20
> also when deleted), for example in 3.4 (n) section.
> Doesnt-it match your requirements?
>

--=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_6509_11485628.1388725900376
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I like your idea better, but in the event it is not accept=
ed due to the committee being conservative about new operators, this idea w=
ould still be useful.<br><br>On Wednesday, January 1, 2014 10:25:04 PM UTC-=
5, Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote">On Thu, Jan 2, 2014 =
at 3:33 AM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"6sfUcjV03YkJ" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">fma=
tth...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">It has. Everyone, can we get back on topic with the idea o=
f a defaulted swap operator?</blockquote>
</div><br>What about my question about N3746?&nbsp;<a href=3D"http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2013/n3746.pdf" target=3D"_blank" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.ope=
n-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3746.pdf\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEc6qDbPCVLTfRKAMN8Mv1gh6VaiQ';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3746.pdf\46sa\75D\46sntz=
\0751\46usg\75AFQjCNEc6qDbPCVLTfRKAMN8Mv1gh6VaiQ';return true;">http://www.=
open-std.<wbr>org/jtc1/sc22/wg21/docs/<wbr>papers/2013/n3746.pdf</a><br>It =
proposes a swap operator AND a specific behaviour when defaulted (and also =
when deleted), for example in 3.4 (n) section.<br>
</div><div>Doesnt-it match your requirements?</div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6509_11485628.1388725900376--

.

I realize that I'm an awful spoil-sport but the desire to generate default =
versions of operator=3D=3D(), swap(), operator<(), I/O operations, and poss=
ibly other operations with varying degrees of design considerations is why =
I think this direction is a waste of time! Instead of even looking at propo=
sals to do any of these, we should concentrate our efforts on putting a suf=
ficient initial version of compile-time reflection together and provide the=
 necessary library components to have the corresponding operations generate=
d!

Since I stated this when a defaulted version of operator=3D=3D() was discus=
sed at the committee meeting and proponents of a default operator=3D=3D() b=
asically stated that their desire is more important than having a generic s=
olution, I expect the same to happen here and won't mention it again. Howev=
er, I will continue to consider any efforts of defaulting additional member=
s which isn't based on a generally available reflection system a waste of t=
ime. Note that this position is based on the merits of any specific proposa=
l for optionally defaulting member functions but rather on wanting a genera=
l solution in favour of many special solutions baked into the language.

On 1 Jan 2014, at 02:42, fmatthew5876@gmail.com wrote:

> Writing swap() is one of those boilerplate kinds of things that is usuall=
y trivial but annoying (and error prone when you change data members but fo=
rget to update swap()).
>=20
> Why not allow this:
>=20
> class Foo {
>   public:
>     void swap(Foo& f) =3D default;
>   private:
>     int a;
>     Bar b;
>     float c;
>     Baz* d;
> };
>=20
> Which would be the equivalent of this:
>=20
> void Foo::swap(Foo& f) {
>   using std::swap;
>   swap(a, f.a);
>   swap(b, f.b);
>   swap(c, f.c);
>   swap(d, f.d);
> }
>=20
> Any reason this wouldn't make it as a proposal?

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

.