220 8340 article Path: news.gmane.org!not-for-mail From: "Billy O'Neal" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Default swap operation Date: Wed, 1 Jan 2014 14:58:09 -0800 Lines: 210 Approved: news@gmane.org Message-ID: References: <-414611097405781448@gmail297201516> <52C456C5.8000407@gmail.com> <1429572.pH5kxD60ME@tjmaciei-mobl2> <52C488CB.3030805@gmail.com> <52C4908B.2030606@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d2ea4c6980d04eef09e29 X-Trace: ger.gmane.org 1388617124 21341 80.91.229.3 (1 Jan 2014 22:58:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jan 2014 22:58:44 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDKLBLVE6ADBBK53SKLAKGQEM5QHY2Y@isocpp.org Wed Jan 01 23:58:53 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f71.google.com ([209.85.213.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VyUkW-0005DV-Vq for gclcip-std-proposals@m.gmane.org; Wed, 01 Jan 2014 23:58:53 +0100 Original-Received: by mail-yh0-f71.google.com with SMTP id f64sf17151189yha.2 for ; Wed, 01 Jan 2014 14:58:51 -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:from:date :message-id:subject: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=X2890QTyyJHZ4pXhzYWBtdn8ovklJvPL1ReSMVEj32g=; b=d4WYi6FDI7Pr2J7bD3+xsiFf2OwnJwSeymlUMsJqGSqyxtP9avRTCqWtbFLy+MjDoz 1WdO0TEv60Ein9J/QhqLoe7dJABXWOmbCe/yESQ3x0kw/MWnGHl/Vli3hcbtCatdfTdK yKati6890J7e/gxiCm8/f4G/wuU0LYUcYVkHt/RgPysEkhw3UEVxcJRi9IA10CmK/pdP 2ZL56H7dJriwuscOoa6SDFrG85sOvdRn5ap6ogFX9lKtT953mpPrAglc1LTjLIh3VNDa o0YSWJhYsXeV8JF2HkjcG/gkjWsAnN+6232/inU/LYsNVAjfXakeiAbiZmh4tQkfnRyI SraQ== X-Gm-Message-State: ALoCoQmNqxMwwFOi2llDaIcS+l/YbUoP9UfQS/9RBZRPWgim4Nzlg8vTdJj+vPOALssdnlksJJPj X-Received: by 10.58.249.180 with SMTP id yv20mr29092553vec.11.1388617131694; Wed, 01 Jan 2014 14:58:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.29.197 with SMTP id m5ls4209121qeh.43.gmail; Wed, 01 Jan 2014 14:58:50 -0800 (PST) X-Received: by 10.49.109.97 with SMTP id hr1mr136999428qeb.59.1388617130699; Wed, 01 Jan 2014 14:58:50 -0800 (PST) Original-Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [2607:f8b0:4003:c02::22b]) by mx.google.com with ESMTPS id w1si22793296qcz.32.2014.01.01.14.58.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jan 2014 14:58:50 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22b as permitted sender) client-ip=2607:f8b0:4003:c02::22b; Original-Received: by mail-oa0-f43.google.com with SMTP id i7so14256235oag.2 for ; Wed, 01 Jan 2014 14:58:50 -0800 (PST) X-Received: by 10.182.49.166 with SMTP id v6mr53248100obn.13.1388617130217; Wed, 01 Jan 2014 14:58:50 -0800 (PST) Original-Received: by 10.182.87.37 with HTTP; Wed, 1 Jan 2014 14:58:09 -0800 (PST) In-Reply-To: <52C4908B.2030606@gmail.com> 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:4003:c02::22b 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:8340 Archived-At: --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/ http://stackoverflow.com/users/82320/billy-oneal Malware Response Instructor - BleepingComputer.com On Wed, Jan 1, 2014 at 2:02 PM, Matthew Woehlke wrote: > On 2014-01-01 16:48, Ville Voutilainen wrote: > >> On 1 January 2014 23:29, Matthew Woehlke >> 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

[quote]
What "that"? 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).
[/quote]=
Whoops, I misunderstood that bit. :)

[quote]
I don't see any w= ording in the standard that would require other TUs to see the =3Ddefault t= o use the function.
[/quote]
The wording is that when a translation u= nit 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
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 =3Ddefault 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 err= ors 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 accessibl= e
to other TUs. Both of these statements are based on my reading of the
spec, it specifically allows defaulting after first declaration, and there&= #39;s
nothing saying such a definition is in any way static.

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't behave this wa= y?)

Thanks,

--
Matthew


--

--- You received this message because you are subscribed to the Google Grou= ps "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>.
--047d7b5d2ea4c6980d04eef09e29-- .