220 41382 article Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Destructive move, via forwarding and destructuring operations Date: Tue, 22 Jan 2019 13:04:22 -0500 Approved: news@gmane.org Message-ID: References: <7b2204ba-51d0-481e-9974-10029547031c@isocpp.org> Reply-To: std-proposals@isocpp.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b91ab305800fce80" Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="118962"; mail-complaints-to="usenet@ciao.gmane.org" To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDLZJYWNDQIKVNU54ICRUBDD4H3ZU@isocpp.org Tue Jan 22 19:04:28 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr1-f71.google.com ([209.85.221.71]) by ciao.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gm0PT-000UnZ-So for gclcip-std-proposals@m.gmane.org; Tue, 22 Jan 2019 19:04:28 +0100 Original-Received: by mail-wr1-f71.google.com with SMTP id e17sf12798430wrw.13 for ; Tue, 22 Jan 2019 10:04:27 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1548180267; cv=pass; d=google.com; s=arc-20160816; b=y2URP/ev4xvyF0OAA7RtYAsT6J0e1rDugl9lcSoMlQjkAO+Pj/oCf8/Cgtb4OhC9+8 EmX4/KFqIhOZd62XcDbLJjKVkHQig+sM39za/afjve08ng052xYkmV21xlxhKyNPJp/h 20zWC2x5iKl8k+X1sa/YMQ98wn6ME/SatUMn78OmzLPkjvuAjwVW3xS5Bp/Gj2FrqGjj 1O+3K2qh0j3fqH4YcoF50cOp/AHCHe4/H4b6Zny4vKKiGWzobtVqGWdsSyEtF8wlnsAb ZTQKg/fPEgD/ColAP+Q514Gj8jmBhFkjmq5iFxBIw8die1vSBYDhyW6jgV1tG84ZOXF1 kQGg== 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:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=xPP1HGerRIIemeIngWCbCZ0wNKpQvcSeijEyyQ3R0HI=; b=PDlMXyZRBrnrhZ5/YBNSHxSrwh5CqWo9fyjh/sBUZP3nU1DWxx7F884c9B75jy3rjq sFq/+nyZOZ7eZndqrvSKtBRmMdyLPulifw4oSKe/HmgjjKC4ANOPEdeaj6DkkKtlmWIP OUX3ZSYenOo7geeEEe4JPazjrWCzKpw5EXe9YhBD8eNQ/9m6A6cSqQQatIrChdAHGyFS 0q8B400pnUOJr0u72kwmc2e9Q784lAH7W/j/HiGGa5/OZyp7z0wt9++MBWKVfshIuSi0 h/HI5liZIFupn3GTVCKIRYQUVne5ebLtmWOxOANzvxInKudJsr/10qd32YljDSVne7rs aoyw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FglPrE6p; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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=mime-version:references:in-reply-to: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; bh=xPP1HGerRIIemeIngWCbCZ0wNKpQvcSeijEyyQ3R0HI=; b=G9+Ei2KBzVjX+yn5uks51lvq7x2vsbwpOIavO4w+pxwXbW7rFG8AEF1aevpsl9Dhxp USfcCDfqk/lHjog69CIym7oWldrF1XV0rWucq6k3YkGiBtCNJG98DOmt+0/rAla23aKe Lb816wzWIiFLWoEU73ZXh3mduhS/1mbeO5tv6lw7wcbH5tz8YI86S8j1N909Rl4UoGPj cYorOex83fTUeO6RgeFGsNo/9Bd6mxyhh6VHibRHJkH2y8E8JDXY2Z0hQmGWm89UUAHe YYvsLXD6rlKnRHezqdYYRfz/VJmZ1dvrwKvHCxY41JFdkI+EEWvCNNBvbH6gM021u1sX PhnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject: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=xPP1HGerRIIemeIngWCbCZ0wNKpQvcSeijEyyQ3R0HI=; b=StDiQDueXUYtFq7rQyYpPcRU7VCGNHfEq4pbOzCF3K9KoA9Ju8NY/CRJiKTE3d768Z iGFKp1fG6duTBqBe9iXgE9xs25ynYhkvl2WeqAUrjGc9ZG8rW7r2Ac7YFaRjts6PWKb5 ppVIqAUi8FL4sCWWaU852+HIahA0nn+ECab3ButflL4xWs9BLkx/SyB356jMWf/ct+YT gu7ejoM5WE2L+OSsXl1hjoVHKAVxiYKhoKkQ3DXO0oI/893TEzCK96LJ+ZiRHz08ZQ9N 40RrZx/jmns07yVvD22M3moB1uQcI1uTTF1ySkkoP9ec6c6p/srSk0Gs9/8tyOJVeXga 1PUw== X-Gm-Message-State: AJcUukc605Htz4z/ES66BHSKKer8S7zFfFBSHxMrY3dsadqsfViVHUEn RHNoaJDtpCerR6sn2ZMhAcjaAA== X-Google-Smtp-Source: ALg8bN4xvs6EeLSmjuaCAndnqbDE+exAkq5veTnxT4Udrvys60iVQcSz4e6br3oGumq7dXxPAe5shw== X-Received: by 2002:a7b:ca4d:: with SMTP id m13mr175358wml.19.1548180267247; Tue, 22 Jan 2019 10:04:27 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:eac3:: with SMTP id o3ls5641513wrn.8.gmail; Tue, 22 Jan 2019 10:04:25 -0800 (PST) X-Received: by 2002:adf:d4c9:: with SMTP id w9mr34054531wrk.119.1548180265422; Tue, 22 Jan 2019 10:04:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548180265; cv=none; d=google.com; s=arc-20160816; b=yDKgwWakY3dXR8YS0gTlBtEGVH36Dv/Sv4UObfA9+xY1Nt2K7GDmBpt7dYDcNM3y5D ktMNSIQdti9bFqIYGHBZs6swjQPGuqtwi+SHIoCBKJOeW3n3XkvaPreTlKAuyfyYlQak gz2hJeYO+WlxiQE0SC+FN3v4nJff5udugn6icGcdh8CIekolOM7rrY007NoW72tgjchh Zmgz7C51chtQv1IgQz5IB385cTtuVAL3gRJ8GUCFdEY5wvU9ZB7NxPRE0vRyxJ7mSg3J r+ZhLmU3dZgwriXRVOJdJfVUNkcB9dGfiov2UG7pJDgm/GZmGZwFcP/ACRrPLemyIA9q yTIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=JFN7IRk6CHSY2b83ymgQYv4pKUWIZ4bBvQlpnR0nZ4k=; b=G8GWW0eW5gijnpUbuHrA5/HSPFaD89qziJJZrJfKB4TBfKmDxa9woCwgaEyc2hbuLs MQCKmW7Fwz8ZIpr1Lr5M/XmHGfjN5dlBWK4p1JJlALiNXCt5RLEEN/InyszPax/JV+HJ HSiPRKx/l2nkjdYXqkR28cqOcKs8HhKvA6KDpwqzhQ78IyH0rnTx8g8nTcR8x/ULcG8M BOttRoT3Fgdzgdmt6cHN36FI7c2GXrhxZgOi2Z6Whc5rgK/Rq/hX1bay1lxXfFa6vY0z SYUbTko8oDXxgUqIxY2O5vhOVtV0aO6kONlEXQCJyt/pQONdvqJlnlxJI/dLk/A/pBfz Xzlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FglPrE6p; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id m14sor7798945wmc.18.2019.01.22.10.04.25 for (Google Transport Security); Tue, 22 Jan 2019 10:04:25 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a1c:f71a:: with SMTP id v26mr4417704wmh.131.1548180264653; Tue, 22 Jan 2019 10:04:24 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FglPrE6p; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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:41382 Archived-At: --000000000000b91ab305800fce80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 22, 2019 at 11:52 AM 'Niall Douglas' via ISO C++ Standard - Future Proposals wrote: > For me personally, the gains for adding a new reference type to C++ would > have to be enormous and game changing to be worth it. > > I also, personally, speaking, think it's the wrong approach. For Cologne = I > intend to propose to SG12 a new memory and object model which just happen= s > to implement object relocation as a side effect, but its main goal is to > add awareness to C++ of memory paging. > > Under what I have in mind, all C++ objects anywhere in the universe > actually live in a theoretical object store somewhere, and what each C++ > program sees is merely those objects attached to the current running C++ > program. You can detach an object, the memory where it is stored goes fro= m > a T to byte[sizeof(T)] i.e. T's lifetime ends and an array of byte begins= , > atomically. You can relocate those bytes by memcpy(), or page table > manipulation, or whatever, as an array of bytes is trivially copyable. Yo= u > then can reattach that object back into the current running C++ program a= t > a new address, thus turning byte[sizeof(T)] back into a living T. > > So you don't get destructive moves exactly, but you do get to relocate an > object in memory arbitrarily. You can also detach and object and hand it > off to another C++ program running elsewhere, thus implementing shared > memory support. > I quite like this way of thinking about it! However, would you agree that - there's a set of types (such as `int`) which can be "ended, relocated, and revived" in this way without any ill effects - there's a set of types (such as `offset_ptr`) which, if they are ended, relocated, and revived, you'll get undefined behavior for sure - there's a set of types (such as `std::string`) which can be ended, relocated, and revived, but only within a single process, not across processes ? I think it would be a problem for me if we standardized only the *physical mechanism* for ending and reviving, without also standardizing ways for the programmer to use the type-system to statically prove that they were using the physical mechanism only in ways that didn't lead to undefined behavior. Remember, people can already do exactly what you're describing, today; and people *do* do it. The *only* additional value a proposal can bring to the table is to make it "not-undefined-behavior" to do this stuff. (But it *must* remain undefined behavior in some cases, like the example of relocating a std::string between processes in different address spaces. So the programmer needs a way to distinguish the stuff that's okay-to-do from the stuff that's undefined.) =E2=80=93Arthur --=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/CADvuK0JB4_ZoZMFnFgag1efjsH%2B3gFTMRmdiVU5Z2-Jfg= NxXQQ%40mail.gmail.com. --000000000000b91ab305800fce80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 22, 2019 at 11:52 AM 'Nia= ll Douglas' via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org> wrote:
For me= personally, the gains for adding a new reference type to C++ would have to= be enormous and game changing to be worth it.

I a= lso, personally, speaking, think it's the wrong approach. For Cologne I= intend to propose to SG12 a new memory and object model which just happens= to implement object relocation as a side effect, but its main goal is to a= dd awareness to C++ of memory paging.

Under what I= have in mind, all C++ objects anywhere in the universe actually live in a = theoretical object store somewhere, and what each C++ program sees is merel= y those objects attached to the current running C++ program. You can detach= an object, the memory where it is stored goes from a T to byte[sizeof(T)] = i.e. T's lifetime ends and an array of byte begins, atomically. You can= relocate those bytes by memcpy(), or page table manipulation, or whatever,= as an array of bytes is trivially copyable. You then can reattach that obj= ect back into the current running C++ program at a new address, thus turnin= g byte[sizeof(T)] back into a living T.

So you don= 't get destructive moves exactly, but you do get to relocate an object = in memory arbitrarily. You can also detach and object and hand it off to an= other C++ program running elsewhere, thus implementing shared memory suppor= t.

I quite like this way of thi= nking about it!

However, would you agree that
- there's a set of types (such as `int`) which can be "ended= , relocated, and revived" in this way without any ill effects
- there's a set of types (such as `offset_ptr<int>`) which, if = they are ended, relocated, and revived, you'll get undefined behavior f= or sure
- there's a set of types (such as `std::string`) whic= h can be ended, relocated, and revived, but only within a single process, n= ot across processes
?
I think it would be a problem for= me if we standardized only the physical mechanism for ending and re= viving, without also standardizing ways for the programmer to use the type-= system to statically prove that they were using the physical mechanism only= in ways that didn't lead to undefined behavior.
Remember, pe= ople can already do exactly what you're describing, today; and people <= i>do do it. The only additional value a proposal can bring to th= e table is to make it "not-undefined-behavior" to do this stuff. = =C2=A0(But it must remain undefined behavior in some cases, like the= example of relocating a std::string between processes in different address= spaces. So the programmer needs a way to distinguish the stuff that's = okay-to-do from the stuff that's undefined.)

= =E2=80=93Arthur

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JB4_ZoZM= FnFgag1efjsH%2B3gFTMRmdiVU5Z2-JfgNxXQQ%40mail.gmail.com.
--000000000000b91ab305800fce80-- .