220 8331 <52c45ab8.4808ec0a.31ec.fffff22e@mx.google.com> article Path: news.gmane.org!not-for-mail From: "=?utf-8?B?YmlsbHkub25lYWxAZ21haWwuY29t?=" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Default swap operation Date: Wed, 01 Jan 2014 10:13:09 -0800 Lines: 249 Approved: news@gmane.org Message-ID: <52c45ab8.4808ec0a.31ec.fffff22e@mx.google.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1388599989326" X-Trace: ger.gmane.org 1388599990 20042 80.91.229.3 (1 Jan 2014 18:13:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jan 2014 18:13:10 +0000 (UTC) To: "=?utf-8?B?c3RkLXByb3Bvc2Fscw==?=" Original-X-From: std-proposals+bncBDKLBLVE6ADBBOVVSGLAKGQEJ7NEQBQ@isocpp.org Wed Jan 01 19:13:17 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VyQI8-0006H5-B8 for gclcip-std-proposals@m.gmane.org; Wed, 01 Jan 2014 19:13:16 +0100 Original-Received: by mail-pd0-f199.google.com with SMTP id r10sf40492431pdi.2 for ; Wed, 01 Jan 2014 10:13:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:to:from:subject:date:mime-version :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=2xq4nBoVrqZDD3zX78TfoQok0RMyVbDAlKusBDUyWe4=; b=nCDmDxgRj5XWZipPxJeI9kHaz+h+XeaFuW30lac0m3TWVAcfLECIGWFg/3KvawbmSJ kGH7fEjWnFR/T36HWI9IpfBrL3hr3yhyFydC2Z+mhJVi+m/PxQStWLuCV2NA9/ipfXVU JpimjYnVUFtsZvy9gQSY3x3fiEf/ygSTzR5Ickuup2IF8kpg4iguyHOQoBCfBSb/pBIu 8JsG5Y0j+C3c0npeddWeGLu/BuVocrVm9dd/vrVFnDq4E7sNPgyBDyrcov3U4PVZvQos LhOoNOTKFmW210mXwncOfnN4glVpDtHuzsprCGfEbHy5Oxs3uPCdyblrvp7083+wT5/x PTmg== X-Gm-Message-State: ALoCoQkDyqYs/1PHxLOAAkniAwY96wg8QaB7JfizNn2nZ4IKK0Fcgc5LJmXmMZtRWCPSo31/ihzV X-Received: by 10.66.141.231 with SMTP id rr7mr1161778pab.47.1388599994638; Wed, 01 Jan 2014 10:13:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.106.102 with SMTP id gt6ls4123807qeb.78.gmail; Wed, 01 Jan 2014 10:13:13 -0800 (PST) X-Received: by 10.236.140.65 with SMTP id d41mr12934991yhj.66.1388599993904; Wed, 01 Jan 2014 10:13:13 -0800 (PST) Original-Received: from mail-gg0-x22f.google.com (mail-gg0-x22f.google.com [2607:f8b0:4002:c02::22f]) by mx.google.com with ESMTPS id p5si56008972yho.259.2014.01.01.10.13.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jan 2014 10:13:13 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4002:c02::22f as permitted sender) client-ip=2607:f8b0:4002:c02::22f; Original-Received: by mail-gg0-f175.google.com with SMTP id u2so2669520ggn.34 for ; Wed, 01 Jan 2014 10:13:13 -0800 (PST) X-Received: by 10.236.106.99 with SMTP id l63mr12785055yhg.81.1388599993723; Wed, 01 Jan 2014 10:13:13 -0800 (PST) Original-Received: from [2601:8:9780:880:c0dd:a13f:c02:2433] ([2601:8:9780:880:c0dd:a13f:c02:2433]) by mx.google.com with ESMTPSA id 48sm72703301yhq.11.2014.01.01.10.13.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jan 2014 10:13:12 -0800 (PST) X-Original-Sender: billy.oneal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4002:c02::22f as permitted sender) smtp.mail=billy.oneal@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8331 Archived-At: ------=_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" To: 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 >>>> ... >>> >>> 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', for which the dtor needs the definition of >> Private, but otherwise Private could be forward declared.) >> >> In this case, this would solve needing in the header. >> > > But wouldn't this instead cause trouble for , like > is_trivially_destructible ? 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
That would be inconsistent with other uses of "=3D defa= ult", which are not considered user-provided.

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

----- Reply message -----
From: "Matthew Woehlke&qu= ot; <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 w=
rote:
>>>> The other issue here is that "using std::swap" would requi=
re including
>>>> <algorithm>...
>>>
>>> Implementing swap yourself in this way requires the same.
>>
>> I think the problem here is that the *header* would need to includ=
e it.
>>
>> Related to that note, I wonder if we should allow e.g.:
>>
>> foo.h
>> -----
>> class Foo
>> {
>>    ...
>>    ~Foo();
>>    ...
>> }
>>
>> foo.cpp
>> -------
>>
>> Foo::~Foo() =3D default;
>>
>>
>> IOW, allow uses of '=3D default' after declaration, to allow the c=
ompiler
>> 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 definiti=
on of
>> Private, but otherwise Private could be forward declared.)
>>
>> In this case, this would solve needing <algorithm> in the he=
ader.
>>
>
> 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=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 http://groups.google.com/a/isocpp.org/group/std-proposals/=
..

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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-proposals/<= /a>.
------=_Part_0_1388599989326-- .