220 36368 article Path: news.gmane.org!.POSTED!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Sub-objects and their copy ellision Date: Tue, 26 Dec 2017 23:33:47 +0100 Lines: 394 Approved: news@gmane.org Message-ID: 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 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_05AF0CC4-A682-48FE-B367-53B848E8527F" X-Trace: blaine.gmane.org 1514327515 27118 195.159.176.226 (26 Dec 2017 22:31:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 22:31:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBTU4RPJAKGQEMON5DQA@isocpp.org Tue Dec 26 23:31:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f199.google.com ([209.85.128.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTxlE-0006ck-JI for gclcip-std-proposals@m.gmane.org; Tue, 26 Dec 2017 23:31:48 +0100 Original-Received: by mail-wr0-f199.google.com with SMTP id c3sf21921972wrd.0 for ; Tue, 26 Dec 2017 14:33:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1514327631; cv=pass; d=google.com; s=arc-20160816; b=UO0BucYzJySTXYDu6pUer9qg2//NU6+XFmPJmobHCbQADV5f+roOpF+LqZXU1O4nxT 5laW0pKGdNpGOP2kxhd3taJpNfxAVIO7kom1N99W4mkiJSjoPRqFw0fJbNSzUe9wNGia HihyjV9J71Lq8WBgNuVvcolEZwyNOp2G+39Yp/hfD4fTtH3+28bEbvq+V/RjhhkDawe9 EaKup2A94c9EfFG1a5it8/7kCiljVisL6jdBWprzq62DK6c2+BeuzOgA0JnFQullM05h WgxQMMjArZYNqwx3juQPEkD7RjOcWcBAw+EnD5ci/L1l2i8Cy7qGyDNcVi/+qQ6fgugb Y/sg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:in-reply-to:to:references :date:subject:mime-version:message-id:from :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=2ef4t4pgRaSebObqlPQXrXcpQTrZTYZ69N/NVazPB10=; b=hwEnbukdKY/9m9mXGoMyFEWjr4B0HxOP4FoBAt8duOzxlOZhCUh1c9qsM/PULbFkI6 4xbmVM0EX3wy9ymOXtNSbqE5wOcudwMdhIHG7mQtLMGehoUFck10x2PrD1JwguMMAhNc /h7pdkTsGov4eWA7s0z0KzaqPiAmL251DTrmelMZ3xtIlVm963M7cE/VOPtjlcFMZJvn A+jiKuuRurUFU7jTkanC4W1O24K2lhNGK2uvSntTMkw/NLkXeC2RmlRwmyhxHVaNonQ4 J/sgkN3rl1OgLMA5rkf2H+Zs6ZFwGXpkivi9PIIRts263lIjFx/8KVJGztScnXMV3T1O LAHA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pNm+DMwQ; spf=pass (google.com: domain of potswa@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=potswa@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to: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; bh=2ef4t4pgRaSebObqlPQXrXcpQTrZTYZ69N/NVazPB10=; b=eb7FXHD7SC8d4EjYcbXVrWZBYp0ou1bKW405SGcpssKyMIM6NdSiftj06P3QSS7Nqq JcKyCygBPSAoTTvUVlgt4EAEAY95cn7cduvdrTzqPruz4AyRxcEXmISnz9RhUi6F2knz lOh5yJCWTh1+svj5oLzCf2T9trRFPWSgTNtSP/hDRX9bgaqHhncFI0ZbI0zylLTHC0QW 5ZkVIYpdbtt8hV8hqel8kXlnGsDl2QwgLEdCQdmmuvcw/T4945kcSah7ipw+XFldgq4E Zcw0Yzi2RoD8OGYp7hn3zgr53ZuurxgwzApX883lk/d7qeGP+1Go0WhtaP2jj+j6LasE e/rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=2ef4t4pgRaSebObqlPQXrXcpQTrZTYZ69N/NVazPB10=; b=rj/lFDRDS2mzTdwY7ZaLeWA8/Q1nMKRMvAHFi+XEstWKw/u1PRh2TNDGUUY97xwP5q n7simxgLJjaqmUbZXs2gNuW0WpPVkNz/qzofuMY9H2NbrEFKTYUQOR9jPm68M7iVn58U ZaCzlchcdUlOuRlYsEhOFj4m5ZiQ2LZBROOdwwVK7ZZlxfWTPmOAwcHroLFHSOuM6FuR hL7o0f641zMk4J1Zf/kKqZcvYRweVCnyS7ii1rX+S1Rcib/eneN4YGw6EAtXHakfcmq4 xy5HIW6V3+5AmGoGOMBZ2lvPBoBaQ5lfCP6LECYvc2JNkz6nsFV9nSasFqy/pOeoYbTx wKuw== X-Gm-Message-State: AKGB3mI6I5LzQXPNWN8iHnTSLUUutmvbqeu9K9GSzjdxX/i/P1auDGmC ThY/98fFEJERX+S1F6BIUteURg== X-Google-Smtp-Source: ACJfBotEV+OZYh8bjJX9z1uneV5iPAHcZnzBAwTSkmkfSJ5SpWMKfZPICCGuIxE1A4AxqPnEs3Ja9g== X-Received: by 10.80.230.25 with SMTP id y25mr6808000edm.9.1514327631298; Tue, 26 Dec 2017 14:33:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.80.212.217 with SMTP id e25ls5865394edj.2.gmail; Tue, 26 Dec 2017 14:33:49 -0800 (PST) X-Received: by 10.80.175.65 with SMTP id g59mr33315054edd.283.1514327629766; Tue, 26 Dec 2017 14:33:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1514327629; cv=none; d=google.com; s=arc-20160816; b=b/zJAvgQzmXbENi+b02CMjlgEJEG6nwPHxxIrzssPFXA8pcjnBHtlOvS8s5utlAB1O VUie28yqTBI+EWV6/KTzzOJT3ezHrhmVkqOgsI7dCOHeYTWPCJYrMWUS+inFrGU3R8k/ xQauz1VlvMw5J58Ai8xF7/IPCDIs79Iqv7KoJHVS/+XQmXKSDnMLG4lHZxFu8+HcZwIq tRmMjOOi33zHO4KpU3pEDGGJ+9S7MSYYYVP9cU4Asrwit7NDo+WHkE1YkvFvY5ykt2RN 8ugyqf3AfRykWNRRMQdOTtieo1eZgkCH1MSISYuyznzxZTFrDDIWchHLbj1fkrWHDA2G T7ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:to:references:date:subject:mime-version:message-id:from :dkim-signature:arc-authentication-results; bh=QJJAbH/CjCv4VAWinn42li0jFfTy4ZrvC+Dw50lgLPg=; b=ovjlI/K4Qsu9f2Y4Bv3MRy5GhoYU9DFM1qTpF28fApW8KqCk4AlpzjWbvRsHYwJEyC 6H7pE0fyrbNKLqcu8Cum+vyKSrwwQL4pry6g3YdmRiXtJOpi8LM4Tp0DbefMmANmUXed /3Z4vTxLYm3kLRuJBl6i+TO24ySpSwZgAVhyRlNCqcnggXEQDVfNdXTuP6QTbchMdb0I 1022OT66M00uVTXCeCrNeSfh/0FsalMsilZeyr0xm42YK5Kajat2lWnfBqfIbK0pIK0z aGQEKzQG569lzLjZ5yiG09NvXTwp9KKfz3l/IKsZ1WqGyL+KR6EZORWHT2FiazGn1WBd si1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pNm+DMwQ; spf=pass (google.com: domain of potswa@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=potswa@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id y3sor16695949edi.51.2017.12.26.14.33.49 for (Google Transport Security); Tue, 26 Dec 2017 14:33:49 -0800 (PST) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.80.192.85 with SMTP id u21mr32418909edd.37.1514327629239; Tue, 26 Dec 2017 14:33:49 -0800 (PST) Original-Received: from [192.168.1.100] (133-103-144-85.ftth.glasoperator.nl. [85.144.103.133]) by smtp.gmail.com with ESMTPSA id f36sm28626644edd.82.2017.12.26.14.33.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Dec 2017 14:33:48 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3096.5) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pNm+DMwQ; spf=pass (google.com: domain of potswa@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=potswa@gmail.com; dmarc=pass (p=NONE sp=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-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:36368 Archived-At: --Apple-Mail=_05AF0CC4-A682-48FE-B367-53B848E8527F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Antony, This looks more like lifetime extension than copy elision. If the copy is e= lided, then the complete object cannot be destroyed until the subobject is.= Quickly scanning through your =E2=80=9Cultimate=E2=80=9D paper, I don=E2= =80=99t see this issue mentioned. Since C++98 we already have a rule for lifetime extension when using a retu= rn value subobject to initialize a scoped reference. So, does this feature = not already exist with the syntax of declaring a reference? Also, the behav= ior is required, not optional. - D > On 2017=E2=80=9312=E2=80=9325, at 7:12 PM, Antony Polukhin wrote: >=20 >=20 >=20 > On Dec 20, 2017 04:06, "Nicol Bolas" > wrote: > <...> > Just within this thread, we have identified a number of limitations on wh= at you can do with such objects. Let's not go further than merely what you'= ve already agree to: destruction of subobjects and layout. That is, this op= timization is not possible if any of the following is true: >=20 > 1) The containing type has a non-defaulted destructor. > 2) The containing object is not passed to another function by pointer or = reference, since that requires the object's layout to be consistent with wh= at the standard says. > 3) The user of the containing object does not do anything layout-specific= itself. >=20 > Note that this is almost certainly not a complete list. It's merely the o= nes talked about thus far; there are almost certainly others. >=20 > Since late November paper concentrates on cases when the callee is inline= d. In that case there's no need to mess with the object layout. But please,= wait for a moment and read further. I know that this point rises even more= questions. >=20 >=20 >=20 >=20 > Item #2 is particularly important. Why? Because that rules out calling an= y member functions, since all non-static member functions take the object b= y pointer. And that requires the object's layout to be consistent with its = definition. >=20 > Notice that "Motivating example #2" doesn't qualify for this, since we ca= ll a function on the object. That requires it to have a certain layout. >=20 > So, how much real code actually qualifies for such elision? >=20 > Because here's the thing the person behind that proposal just doesn't get= .. His proposal doesn't work. It does not solve the problem. Why? >=20 > Because compilers can't do it in so many of these cases. RVO was very rel= iable; when compilers offered it, it worked for any case of returning a prv= alue. NRVO is pretty reliable; declare the variable at the top of the funct= ion, return it whenever, and you're almost guaranteed to get the optimizati= on. >=20 > That's true. But let me put it other way around. >=20 > Compilers could do devirtualization. Does this optimization reliable? No,= it is very dependent on the compiler abilities and flags. Does the C++ Sta= ndard forbids that optimization? No, because it's an optimization and users= may benefit from it. >=20 > Just treat optimization from the "subobject copy elision" paper as some r= andom optimization: not something you could rely on, but something that may= help if compiler is clever enough. >=20 >=20 >=20 > What are the guidelines for getting this proposal's optimizations? What c= ircumstances stop it, and what can be done to avoid them? >=20 > Because here's the thing: if I do this: >=20 > string foo() > { > string str; > str =3D ...; > return str; > } >=20 > If I do that, and I don't get elision, it's still fine. Why? Because I st= ill get automatic move support. `str` in the return statement is a referenc= e to an automatic variable in the function's scope, so it is moved from. I = may not have gotten the best answer, but I got a good enough one. >=20 > In this case: >=20 > string foo() > { > pair pr =3D ...; > return pr.second; > } >=20 > What happens if this doesn't get elided? Well, you get a copy. The only w= ay to get a move is to ask for it: `return std::move(pr.second)`. >=20 > So the proposal actually encourages bad code, on the assumption that the = compiler will swoop in and save you. >=20 > You've got that impression from the assumption that the optimization is s= omething you could rely on, which is not true. >=20 > But the example with std::move that disables the copy elision is a good c= atch. I've been thinking on that problem a lot a few weeks ago and suddenly= came up with a more generic solution: http://apolukhin.github.io/papers/ul= timate_copy_elision.html >=20 > I'd be grateful if you and other volunteers could take a look at it. It a= ddresses most of the above comments. >=20 >=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= email 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/isoc= pp.org/d/msgid/std-proposals/CAKqmYPbdMjxUOp9u%2BErcx%2BeYjvUJvAn%2BCZe5EDp= gGd4vaz47ag%40mail.gmail.com . --=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/AD4FF975-B9C1-43C2-8214-07665ECDBA52%40gmail.com= .. --Apple-Mail=_05AF0CC4-A682-48FE-B367-53B848E8527F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Antony,

This looks more like lifetime = extension than copy elision. If the copy is elided, then the complete objec= t cannot be destroyed until the subobject is. Quickly scanning through your= =E2=80=9Cultimate=E2=80=9D paper, I don=E2=80=99t see this issue mentioned= ..

Since C++98 we = already have a rule for lifetime extension when using a return value subobj= ect to initialize a scoped reference. So, does this feature not already exi= st with the syntax of declaring a reference? Also, the behavior is required= , not optional.

<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> - D


On 2017=E2=80=9312=E2=80= =9325, at 7:12 PM, Antony Polukhin <antoshkka@gmail.com> wrote:


=
On Dec 20, 2017 04:06, "Nicol Bol= as" <jmckesson@gmail.com> wrote:
<...= >
Just within this thread, we have identified a number of limitations o= n what you can do with such objects. Let's not go further than merely what = you've already agree to: destruction of subobjects and layout. That is, thi= s optimization is not possible if any of the following is true:

1) The containing type has a= non-defaulted destructor.
2) The containing object is= not passed to another function by pointer or reference, since that require= s the object's layout to be consistent with what the standard says.
3) The user of the containing object does not do anything lay= out-specific itself.

Note that this is almost certainly not a complete l= ist. It's merely the ones talked about thus far; there are almost certainly= others.

Since late November= paper concentrates on cases when the callee is inlined. In that case there= 's no need to mess with the object layout. But please, wait for a moment an= d read further. I know that this point rises even more questions.
=
<= /blockquote>

<= /div>



Item #2 is partic= ularly important. Why? Because that rules out calling any mem= ber functions, since all non-static member functions take the object by= pointer. And that requires the object's layout to be consistent with its d= efinition.

Notice= that "Mot= ivating example #2" doesn't qualify for this, since we call a function on t= he object. That requires it to have a certain layout.
So, how much real code actually qu= alifies for such elision?

Because here's the thing the person behind that proposal just does= n't get. His proposal doesn't work. It does not solve the= problem. Why?

Be= cause compilers can't do it in so many of these cases. RVO was very reliabl= e; when compilers offered it, it worked for any case of returning a prvalue= .. NRVO is pretty reliable; declare the variable at the top of the function,= return it whenever, and you're almost guaranteed to get the optimization.<= /div>

That's true. But let me put i= t other way around.

=
Compilers could do devirtualization. Does this= optimization reliable? No, it is very dependent on the compiler abilities = and flags. Does the C++ Standard forbids that optimization? No, because it'= s an optimization and users may benefit from it.

Just treat optimi= zation from the "subobject copy elision" paper as some random optimization:= not something you could rely on, but something that may help if compiler i= s clever enough.



What are the gui= delines for getting this proposal's optimizations? What circumstances stop = it, and what can be done to avoid them?

Because here's the thing: if I do this:

string foo<= span class=3D"gmail-m_7257956923552495514m_6661943320342599201styled-by-pre= ttify" style=3D"color:rgb(102,102,0)">()
{
  str= ing str;
  str =3D ...;
&= nbsp; return str;
}

If I do that, and I don't get elision, it's still fine. = Why? Because I still get automatic move support. `str` in the return statem= ent is a reference to an automatic variable in the function's scope, so it = is moved from. I may not have gotten the best answer, but I got a good enou= gh one.

In this c= ase:

string foo()
{
  pair<string, string> pr =3D ...;
&nbs= p; return pr.second;
}<= /span>

What happens if this doesn't get elided? Well, you get a copy. The only = way to get a move is to ask for it: `return std::move(pr.second)`.

So the proposal actually encourages bad code, on the assumption that the compiler will= swoop in and save you.

You've got that impre= ssion from the assumption that the optimization is something you could rely= on, which is not true.

But the example with std::move that= disables the copy elision is a good catch. I've been thinking on that prob= lem a lot a few weeks ago and suddenly came up with a more generic solution= : http://apolukhin.github.io/papers/ultimate_copy_elision.html=

I'd be grateful = if you and other volunteers could take a look at it. It addresses most of t= he above comments.


--
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-propos= als/CAKqmYPbdMjxUOp9u%2BErcx%2BeYjvUJvAn%2BCZe5EDpgGd4vaz47ag%40mail.gmail.= com.

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/AD4FF975-B9C1-43C2-8214-07665ECDBA52%= 40gmail.com.
--Apple-Mail=_05AF0CC4-A682-48FE-B367-53B848E8527F-- .