220 36372 <9f2b0bec-41ae-4463-a7e2-31a54886e1fc@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Sub-objects and their copy ellision Date: Tue, 26 Dec 2017 16:29:54 -0800 (PST) Lines: 162 Approved: news@gmane.org Message-ID: <9f2b0bec-41ae-4463-a7e2-31a54886e1fc@isocpp.org> References: <1c6eff77-d71f-4dd7-8c13-f609460a03f0@isocpp.org> <3ec0bd22-b228-4026-bb49-aec5102918c7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19462_2109906277.1514334594111" X-Trace: blaine.gmane.org 1514334483 28611 195.159.176.226 (27 Dec 2017 00:28:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2017 00:28:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBAWTRPJAKGQEPFZEPWI@isocpp.org Wed Dec 27 01:27:59 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTzZZ-0006e9-WD for gclcip-std-proposals@m.gmane.org; Wed, 27 Dec 2017 01:27:54 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id x135sf2017316vke.10 for ; Tue, 26 Dec 2017 16:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=w3fqyl1Mq5uuEfiFrPujBpaxUyG9+Q3ulu2vmmN0L10=; b=MtjAtvMx4zPYtDEpMp/CQQsAnzJsXJREZ2FHSnyYMSRqx/NViqQ0GofkWimKSdK+1b wQkCsgoWLOqi6pONSAKpmM37vkN53O19wRrCXbaNUbTfOqDubAzWw9l1vkw+9D+ozGyU pe3/1JEJcsJb/AJdX9OKdKLV5ejB22rFUpiUpp+mrlWXZHKWkZPq8Fl1af1PiWE4JkbM eTH15L1Ym5Y26QnAYPD2zSF6eQaUvZyaTbvUZn0JlfYhezGFLJk4YDvLNco8ckLQjuE+ viMDMPbjEsfpKMoj3Okn916Z5M7+UQWTRqglcsyBKmF7OTAKoGVteLYtdIijIR92x7V0 +EEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=w3fqyl1Mq5uuEfiFrPujBpaxUyG9+Q3ulu2vmmN0L10=; b=MxrVl90MzuQRA0sb5wOICckLWoClD55k0CoixFo0y/Vi/qNrhsQ4RNY88MmtOk2PYY 5/9r/5lTXyTakvrLePR1dBO+eyEPO7qc5Qv/SIN20jbdgSg6KUPyeCFgIDTQe1MbiYor 3FsM/kkZeCf3c32ZNWQBqcygmY985PHX0kKzoXtNEIH8AqC7yhE12f6TWlLWEgFfoA1O 1sGnBSxITVCx0Dtk0K5lp57361sYwiF3KOksjNPsrgaVA6JxTrfGR1P7wTXsAEZTYHfH dhqWbWBREnTqZgMW4FDKUTWx9HPOkaN3WjI6PHECaDT8hadSXQluRC02/P6zmfp9sm/t hp+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=w3fqyl1Mq5uuEfiFrPujBpaxUyG9+Q3ulu2vmmN0L10=; b=j7J0TmIBoK2bNruBqtEQ+5qI+g2ep2L0Cb0fhtylEUiRCoZT3YIN6jUNc0Mt8/g78w OqPRCIP8/AjpDcqm0yQZ2BQdzs8JgWqmxs3G9ySytcpc2vdBBoHTeox741jBz1GFvfJH gULhx79BbeudH+IVo+yib7BF0DVUbieD2b0yYs14zfer/FXU4D20APEOzMpKimF5CED4 jDISZmhdDVHKcjgPyC7XmUML6RTPwjAyQ0bZFDLpmX+ae9D2RP89I1w1PzS2HJXG7TlZ oKzV54VL6A2/kc6OCADfR4I8mwJpRao1he+PzS7xxv1kVW8rpW9YoikOMwLpdEc554j2 WY/A== X-Gm-Message-State: AKGB3mI0VptVHf2FxbA/4w/k6qPr0fXlD4EVKzbVsi1UfEuZew2DGR5j U6aS5DZ/gWGhGdlzajBUYJvNzQ== X-Google-Smtp-Source: ACJfBoshgV5qfohmslT7iN9jD5VpJQTQSVjuqzEMe9F29hsfLbO2on7QawvSuFWv2UmVzIdaTmL//Q== X-Received: by 10.31.115.15 with SMTP id o15mr12679470vkc.12.1514334596320; Tue, 26 Dec 2017 16:29:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.150.196 with SMTP id y187ls3538194vkd.10.gmail; Tue, 26 Dec 2017 16:29:54 -0800 (PST) X-Received: by 10.31.52.197 with SMTP id b188mr1809527vka.8.1514334594585; Tue, 26 Dec 2017 16:29:54 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:36372 Archived-At: ------=_Part_19462_2109906277.1514334594111 Content-Type: multipart/alternative; boundary="----=_Part_19463_584074063.1514334594111" ------=_Part_19463_584074063.1514334594111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, December 26, 2017 at 5:33:51 PM UTC-5, David Krauss wrote: > > Hi Antony, > > This looks more like lifetime extension than copy elision. If the copy is= =20 > elided, then the complete object cannot be destroyed until the subobject= =20 > is. Quickly scanning through your =E2=80=9Cultimate=E2=80=9D paper, I don= =E2=80=99t see this issue=20 > mentioned. > This was discussed earlier in the thread, but the general gist as I=20 understand it is that, if the destructor is non-trivial (perhaps=20 recursively?), then no elision can take place. Or to put it the right way= =20 around, elision of this sort can only take place if the compiler can* prove= *=20 that nothing in any of the destructors that need to be executed will notice= =20 that the particular subobject's lifetime has not yet ended. Basically, the idea is that compilers won't be able to do this except in=20 cases where the subobjects are all *definitively* independent of one=20 another. Since C++98 we already have a rule for lifetime extension when using a=20 > return value subobject to initialize a scoped reference. So, does this=20 > feature not already exist with the syntax of declaring a reference? > .... hmm, that's interesting; you can perform lifetime extension on=20 subobjects of the main object. But ultimately, you can't do it that way due to calling conventions. If a= =20 function says that it returns a reference, then the ABI for the caller=20 probably only provides one pointer's worth of storage for the return value.= =20 But if you have this "lifetime extension" idea, the caller would have to=20 provide sufficient space for the entire object that contains the subobject.= =20 How will it know it needs to do that? Basically, elision has to be able to work between two pieces of code=20 without any more knowledge between them than the function's signature.=20 That's why earlier parts of the thread discuss matters of having the=20 compiler separating out subobjects and so forth, since the function's=20 signature only contains the type of the subobject. So if elision were=20 possible on some subobject, the compiler would have to basically strip out= =20 part of the object, such that part of it is in one place and part is in=20 another. And therefore, if you ever pass a pointer/reference of the main object to= =20 some other code, the optimization is not possible (since the other code=20 would only be aware of the object's original layout). And similarly, no=20 optimization can happen if you start doing pointer gymnastics to the object= .. That's what makes this whole proposal dodgy. It paints itself into such a= =20 corner that the optimization can only be providedin highly limited and not= =20 easily definable circumstances. =20 > Also, the behavior is required, not optional. > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/9f2b0bec-41ae-4463-a7e2-31a54886e1fc%40isocpp.or= g. ------=_Part_19463_584074063.1514334594111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, December 26, 2017 at 5:33:51 PM UTC-5, David K= rauss wrote:
Hi Antony,

This looks more like lifeti= me extension than copy elision. If the copy is elided, then the complete ob= ject cannot be destroyed until the subobject is. Quickly scanning through y= our =E2=80=9Cultimate=E2=80=9D paper, I don=E2=80=99t see this issue mentio= ned.

This was discussed earlier= in the thread, but the general gist as I understand it is that, if the des= tructor is non-trivial (perhaps recursively?), then no elision can take pla= ce. Or to put it the right way around, elision of this sort can only take p= lace if the compiler can prove that nothing in any of the destructor= s that need to be executed will notice that the particular subobject's = lifetime has not yet ended.

Basically, the idea is= that compilers won't be able to do this except in cases where the subo= bjects are all definitively independent of one another.
Since C++98 we already have a rule for lifetime extensio= n when using a return value subobject to initialize a scoped reference. So,= does this feature not already exist with the syntax of declaring a referen= ce?

... hmm, that's interes= ting; you can perform lifetime extension on subobjects of the main object.<= /div>

But ultimately, you can't do it that way due t= o calling conventions. If a function says that it returns a reference, then= the ABI for the caller probably only provides one pointer's worth of s= torage for the return value. But if you have this "lifetime extension&= quot; idea, the caller would have to provide sufficient space for the entir= e object that contains the subobject. How will it know it needs to do that?=

Basically, elision has to be able to work between= two pieces of code without any more knowledge between them than the functi= on's signature. That's why earlier parts of the thread discuss matt= ers of having the compiler separating out subobjects and so forth, since th= e function's signature only contains the type of the subobject. So if e= lision were possible on some subobject, the compiler would have to basicall= y strip out part of the object, such that part of it is in one place and pa= rt is in another.

And therefore, if you ever pass = a pointer/reference of the main object to some other code, the optimization= is not possible (since the other code would only be aware of the object= 9;s original layout). And similarly, no optimization can happen if you star= t doing pointer gymnastics to the object.

That'= ;s what makes this whole proposal dodgy. It paints itself into such a corne= r that the optimization can only be providedin highly limited and not easil= y definable circumstances.
=C2=A0
Also, the behav= ior is required, not optional.

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9f2b0bec-41ae-4463-a7e2-31a54886e1fc= %40isocpp.org.
------=_Part_19463_584074063.1514334594111-- ------=_Part_19462_2109906277.1514334594111-- .