220 8332 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Default swap operation Date: Wed, 1 Jan 2014 21:19:22 +0200 Lines: 131 Approved: news@gmane.org Message-ID: References: <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: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1388603957 26058 80.91.229.3 (1 Jan 2014 19:19:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jan 2014 19:19:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBOWUSGLAKGQEZJAVPZY@isocpp.org Wed Jan 01 20:19:25 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f69.google.com ([209.85.212.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VyRK8-0007Do-CU for gclcip-std-proposals@m.gmane.org; Wed, 01 Jan 2014 20:19:24 +0100 Original-Received: by mail-vb0-f69.google.com with SMTP id f12sf16534976vbg.8 for ; Wed, 01 Jan 2014 11:19:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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=6orA73qR0xfEVnHGVSfxWn9Db+X4idvCtyNlzyY/mLc=; b=GUZfqfi2TCuBSf25XgaQ0LzCsJP3vCwRvXYyPayFL4anZ38FmaZ6JC5iYopfXj03OJ engtBDHHrdKjJKqu2oIZR/FaOSdO9F/QdNRmbt25Si7+i/S1YmX5G9saeCVORGk3Qr+f w7faRr5iOJ9sf130kdF13wz4GbZGRbAph06IbFG5KQyoRLoBa6fBaR1UnG23xEydnP2J ASL39wpddAxLgXUpFhhSYpfwlNKXq5XcXt9O9bT6uEr7NOZ2vZILDr2hMR0eiTDmPRjs IdLLZbVIiLF/R+2rZMGAvDhtvIy13b32O4pmQJMTDHa35gYAA7W6PZW7WevelYjqzLkX v0jA== X-Gm-Message-State: ALoCoQl9kOJ6VdmlwqeF1B3q1MLy3hG1E8WTo1XlXi/BC5Ht24kZe8SKcjnkPq7d6mL8itziRVQf X-Received: by 10.58.34.142 with SMTP id z14mr29927825vei.23.1388603963334; Wed, 01 Jan 2014 11:19:23 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.25.196 with SMTP id e4ls4088292qeg.6.gmail; Wed, 01 Jan 2014 11:19:22 -0800 (PST) X-Received: by 10.49.51.66 with SMTP id i2mr134001922qeo.26.1388603962864; Wed, 01 Jan 2014 11:19:22 -0800 (PST) Original-Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [2607:f8b0:400d:c02::22a]) by mx.google.com with ESMTPS id fg9si22555696qcb.18.2014.01.01.11.19.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jan 2014 11:19:22 -0800 (PST) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c02::22a as permitted sender) client-ip=2607:f8b0:400d:c02::22a; Original-Received: by mail-qe0-f42.google.com with SMTP id b4so13634103qen.15 for ; Wed, 01 Jan 2014 11:19:22 -0800 (PST) X-Received: by 10.49.52.102 with SMTP id s6mr134299576qeo.60.1388603962772; Wed, 01 Jan 2014 11:19:22 -0800 (PST) Original-Received: by 10.224.104.139 with HTTP; Wed, 1 Jan 2014 11:19:22 -0800 (PST) In-Reply-To: <52c45ab8.4808ec0a.31ec.fffff22e@mx.google.com> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c02::22a as permitted sender) smtp.mail=ville.voutilainen@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:8332 Archived-At: On 1 January 2014 20:13, 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" > 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/. -- --- 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/. .