220 8329 <52C455A7.5090901@gmail.com> article
Path: news.gmane.org!not-for-mail
From: Matthew Woehlke <mwoehlke.floss@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Re: Proposal: Default swap operation
Date: Wed, 01 Jan 2014 12:51:35 -0500
Lines: 91
Approved: news@gmane.org
Message-ID: <52C455A7.5090901@gmail.com>
References: <c505e517-1c73-4486-b9dd-9ec15af1e649@isocpp.org> <CAPBZbvxzF1pgzaa=A5KfWDTeX7o0epwWiH5+YES+7u4eX2SG0Q@mail.gmail.com> <68012381-8af4-4d62-a5a4-912c454fba96@isocpp.org> <52C4339B.20701@gmail.com> <la1egb$ang$1@ger.gmane.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Trace: ger.gmane.org 1388598697 7447 80.91.229.3 (1 Jan 2014 17:51:37 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 1 Jan 2014 17:51:37 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBC37LBFWUIFBBKNLSGLAKGQEF4FNUII@isocpp.org Wed Jan 01 18:51:43 2014
Return-path: <std-proposals+bncBC37LBFWUIFBBKNLSGLAKGQEF4FNUII@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ie0-f199.google.com ([209.85.223.199])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBC37LBFWUIFBBKNLSGLAKGQEF4FNUII@isocpp.org>)
	id 1VyPxD-0001LC-AJ
	for gclcip-std-proposals@m.gmane.org; Wed, 01 Jan 2014 18:51:39 +0100
Original-Received: by mail-ie0-f199.google.com with SMTP id lx4sf66358329iec.2
        for <gclcip-std-proposals@m.gmane.org>; Wed, 01 Jan 2014 09:51:37 -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:date:from:user-agent:mime-version:to
         :subject:references:in-reply-to: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=awKqbqq8cPAIP1v7sHCw/+c1XhoFGjJPCizu9RguEa4=;
        b=VM4Z3QodIaVXI8UiaDHBNLq8dXjkHCR8Yyx4erNbP+F3EHoC13L88tchJTKkVWmuBD
         aL8sOBtqmLgeKdlBwBbUZ/GivRSSRXLRzGEMEymQVzmUCLi6+AxH5OufngTuNWn49GRM
         gEPEQYslmXOEATrEuA9T38j1S3nYWvlOE8NMLTB6PGJuhWXd16R4FaWu2V0lVyrJ7HHw
         IJDtsVgPvGcQIlmhYbFwvDg/hMXu38cryAzkKDqQ1fmKcCk69YsZ+t8RV6LRpFAqfS5Z
         l8AVRaf4d99k/GhCgHAEIqtDu0cplVb7+Ixy1jAKa4HS2zApHwn2my+nV6NnteVpGvFM
         UxzA==
X-Gm-Message-State: ALoCoQktEZWFZz8deoJxdu8GBr2RclnkrxNxph651+g+ryLA3834j8QW6EEVZcJfHvOEOvbFjPoq
X-Received: by 10.182.81.7 with SMTP id v7mr32000262obx.28.1388598697754;
        Wed, 01 Jan 2014 09:51:37 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.49.60.169 with SMTP id i9ls4201417qer.65.gmail; Wed, 01 Jan
 2014 09:51:37 -0800 (PST)
X-Received: by 10.224.90.6 with SMTP id g6mr26851808qam.87.1388598697127;
        Wed, 01 Jan 2014 09:51:37 -0800 (PST)
Original-Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [2607:f8b0:4001:c05::231])
        by mx.google.com with ESMTPS id m3si22464621qcg.22.2014.01.01.09.51.37
        for <std-proposals@isocpp.org>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Wed, 01 Jan 2014 09:51:37 -0800 (PST)
Received-SPF: pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:4001:c05::231 as permitted sender) client-ip=2607:f8b0:4001:c05::231;
Original-Received: by mail-ig0-f177.google.com with SMTP id uy17so32066243igb.4
        for <std-proposals@isocpp.org>; Wed, 01 Jan 2014 09:51:36 -0800 (PST)
X-Received: by 10.50.119.3 with SMTP id kq3mr10279509igb.12.1388598696675;
        Wed, 01 Jan 2014 09:51:36 -0800 (PST)
Original-Received: from [192.168.1.181] (tripoint.kitware.com. [66.194.253.20])
        by mx.google.com with ESMTPSA id kt2sm70065506igb.1.2014.01.01.09.51.35
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Wed, 01 Jan 2014 09:51:36 -0800 (PST)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
In-Reply-To: <la1egb$ang$1@ger.gmane.org>
X-Original-Sender: mwoehlke.floss@gmail.com
X-Original-Authentication-Results: mx.google.com;       spf=pass (google.com:
 domain of mwoehlke.floss@gmail.com designates 2607:f8b0:4001:c05::231 as
 permitted sender) smtp.mail=mwoehlke.floss@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: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8329
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/8329>

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/.

.
