220 39687 <3f72760b-3c86-42bd-b24c-aca85684ba20@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts about relocation Date: Fri, 10 Aug 2018 12:51:28 -0700 (PDT) Lines: 153 Approved: news@gmane.org Message-ID: <3f72760b-3c86-42bd-b24c-aca85684ba20@isocpp.org> References: <19d8d86c-f4cf-47a9-bb42-9e2ba06dccab@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_897_2133872952.1533930688700" X-Trace: blaine.gmane.org 1533930565 23470 195.159.176.226 (10 Aug 2018 19:49:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2018 19:49:25 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQOZW7NQKGQEV2IW3UY@isocpp.org Fri Aug 10 21:49:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1foDPU-00060t-EF for gclcip-std-proposals@m.gmane.org; Fri, 10 Aug 2018 21:49:20 +0200 Original-Received: by mail-yw1-f71.google.com with SMTP id r144-v6sf14361208ywg.9 for ; Fri, 10 Aug 2018 12:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=xavPYv1VkPZA3S4FtAOZ2Pnf79aWV8PMyOjkPyS4PSo=; b=PoJQn/m3TnkoiKJQIbhyDDH0WAgeveat3rSrMpuWc3ofXpZe4mY7dMTEVc1Az54ZTw lIPb9i74g7ngMdLBogQ5+V10BWKvSBdEx7PmY5cGoRbmCOYmwWpK5We4gZ7gfgO+bDAX DRyNkJP2VzZM+ITIOxm0qC6MMoXPXZ4crf2a6fgU3qd8PRWol+e5WpmkYYXn7RT+/eJ8 JLdgB37RivoR/fSr7KlyIBq5Gpmvb5sXTpTt0ri8frNq7Xk51oG00ZHuEdXJ3AgiEK4T zrvPgw/d7r9f41y3EJ6dnDl2e/xd++VHnD2LmjmoJdJlzr9KX+H9Da7RXaY2mr9ccFRE lM1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=xavPYv1VkPZA3S4FtAOZ2Pnf79aWV8PMyOjkPyS4PSo=; b=nX/+x2rwDg0YQIGbutPD12u7j6SBEI/+nIzMxE1+99i7qKU7wo0fLkDarPnqI6Qu5E TNa398jeN8EJU9OzAHwxP6f9MXpA0WGrfgEav05BBF83XvHhEsYySnQqmjYRwmIjfIkU cbycPB95ouApy7ZiNPcq796V0eT6f8yVaSNUmvzjLr3P+4I7VI9LeN490cjczihhg9kz Pr42Zcwa8R7xdPd4eqkq35a22CMAr0az3WmfA6cS+VQ0UmKXNvVmmiDzrSDWsXaHh8Gm 4foxMDuXwSv3cmm4OR31MA1owo2wyH/mNOwB14FLsVVmy7xnzJttQ31yMt11pMhhjs9Z PBYA== 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:cc: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=xavPYv1VkPZA3S4FtAOZ2Pnf79aWV8PMyOjkPyS4PSo=; b=kddfn6AP5q9Nl9ylT7wZN4qkWhBhz4YkTdXhSIZdc00t8ADr5ZkMxQCjnHdPkU1YVL vxSgHPkbsLr9F2TB6tTkN01a6pRkuRyZScvDldsV/EUWuTTmQF25zZZbIN92loO5Xe/0 x7FxUBz6DK3RrIlOQ7gRtJ+RlWHsXhj/tVT6J6iOGljWbTEj9ki9SZefrOTQOnDsYBum kvNivOovbnXm1kf7kTJWAM52iHslinZo4gRnEHoyVhfSCYGBr8DgE93GYJx0rwM1dGqg dZ+KyT/1G1jfBrBhdP9YJBoHZcIU9wHwAOAarVnoQyKNtxy8lLh96PSh8jsx8GgAs9vd +jyQ== X-Gm-Message-State: AOUpUlFGqCO0sAPLjdGKg09vU+h+Rgq1K2UOo5wSyl8wlWe0pM+3nre2 d+kN8KeF4QjCxvAYtC78Ohtc+g== X-Google-Smtp-Source: AA+uWPxEaEhBG550bxtLLK7YxfAJKuN5lxqoZYNRGo+mZIT0q6g0bFEPErtNk28FMWdfx1Yhtgp4Ag== X-Received: by 2002:a0d:e807:: with SMTP id r7-v6mr2449407ywe.30.1533930690610; Fri, 10 Aug 2018 12:51:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:d982:: with SMTP id b124-v6ls1907595ywe.42.gmail; Fri, 10 Aug 2018 12:51:29 -0700 (PDT) X-Received: by 2002:a81:5705:: with SMTP id l5-v6mr186707ywb.6.1533930689280; Fri, 10 Aug 2018 12:51:29 -0700 (PDT) In-Reply-To: <19d8d86c-f4cf-47a9-bb42-9e2ba06dccab@isocpp.org> 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:39687 Archived-At: ------=_Part_897_2133872952.1533930688700 Content-Type: multipart/alternative; boundary="----=_Part_898_1583866132.1533930688700" ------=_Part_898_1583866132.1533930688700 Content-Type: text/plain; charset="UTF-8" On Friday, August 10, 2018 at 12:41:31 PM UTC-4, floria...@gmail.com wrote: > > I was playing with memory allocations, what it is possible to do and how > it is implemented. > It made me think about relocations, so here is the result of my reflection. > > > "Relocation" definition: > An object is relocated when its address changes. > This does not necessarily implies a copy of its bytes. > > This is where we run into a problem. The C++ object model is predicated on an object occupying a single region of storage throughout the period it exists: An object occupies a region of storage in its period of construction > (15.7), throughout its lifetime (6.8), and in its period of destruction > (15.7). > *Everything* about the C++ object model starts with this assumption: objects live in a specific piece of storage. Change that, and you're now rewriting the entire object model. The reason move in C++ was defined as constructing/assigning-with-modification rather than what you're talking about was precisely to avoid having to do this. The kind of thing you're talking about is a tremendous undertaking. Your post barely scratches the surface of the implications of it. If something like that is going to happen, you need a skilled spec-doctor/lawyer to take a look at whatever you're trying to do. Furthermore, I find myself confused by these statements: Relocation might be called explicitly by user code, or directly by the > compiler as an optimization. > > I don't propose any situation where the language guarantees a relocation > will happen. > That seems contradictory. If users can explicitly perform relocation, then the langauge must be able to guarantee that there is some "situation" wherein "a relocation will happen". Another optimization that can be done with such a relocation (and is not > possible with any current form relocation/destructive move) is to be able > to std::realloc a buffer, and just fix the objects afterwards. > OK, let's examine this idea in greater detail. You want to be able to `realloc` and perform object fixup. So... what happens to the objects between `realloc` and object fixup? What state are the objects in? What does the object model say about an object in such a state? Can you access it? If so, with which operations? Furthermore, what exactly does "fix the objects" mean? How does a type go about doing that? What order are the subobjects in the object "fixed" in? Who decides what this order is? Is this a user-defined process? And if "fix the objects" involves running user-defined code, then what exactly can that user-defined code do with the object? -- 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/isocpp.org/d/msgid/std-proposals/3f72760b-3c86-42bd-b24c-aca85684ba20%40isocpp.org. ------=_Part_898_1583866132.1533930688700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, August 10, 2018 at 12:41:31 PM UTC-4, f= loria...@gmail.com wrote:
I was playing with memory allocations, what it is possible to d= o and how it is implemented.
It made me think about relocations, so here= is the result of my reflection.


"Relocati= on" definition:
An object is= relocated when its address changes.
This does not necessarily implies a= copy of its bytes.


Thi= s is where we run into a problem. The C++ object model is predicated on an = object occupying a single region of storage throughout the period it exists= :

An object occupies a region of storage in its period of construct= ion (15.7), throughout its lifetime (6.8), and in its period of destruction= (15.7).

Everything about = the C++ object model starts with this assumption: objects live in a specifi= c piece of storage. Change that, and you're now rewriting the entire ob= ject model. The reason move in C++ was defined as constructing/assigning-wi= th-modification rather than what you're talking about was precisely to = avoid having to do this.

The kind of thing you= 're talking about is a tremendous undertaking. Your post barely scratch= es the surface of the implications of it. If something like that is going t= o happen, you need a skilled spec-doctor/lawyer to take a look at whatever = you're trying to do.

Furthermore, I= find myself confused by these statements:

Relocation might be call= ed explicitly by user code, or directly by the compiler as an optimization.=

I don't propose any situation where the langu= age guarantees a relocation will happen.

<= div>That seems contradictory. If users can explicitly perform relocation, t= hen the langauge must be able to guarantee that there is some "situati= on" wherein "a relocation will happen".

=
Another opti= mization that can be done with such a relocation (and is not possible with = any current form relocation/destructive move) is to be able to std::realloc= a buffer, and just fix the objects afterwards.
=
OK, let's examine this idea in greater detail. You want = to be able to `realloc` and perform object fixup.

= So... what happens to the objects between `realloc` and object fixup? What = state are the objects in? What does the object model say about an object in= such a state? Can you access it? If so, with which operations?

Furthermore, what exactly does "fix the objects"= ; mean? How does a type go about doing that? What order are the subobjects = in the object "fixed" in? Who decides what this order is? Is this= a user-defined process? And if "fix the objects" involves runnin= g user-defined code, then what exactly can that user-defined code do with t= he object?

--
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/3f72760b-3c86-42bd-b24c-aca85684ba20= %40isocpp.org.
------=_Part_898_1583866132.1533930688700-- ------=_Part_897_2133872952.1533930688700-- .