220 39727 <05cd596d-8582-4a0c-8f04-e0e3eef0d9b0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts about relocation Date: Sun, 12 Aug 2018 02:45:54 -0700 (PDT) Lines: 1108 Approved: news@gmane.org Message-ID: <05cd596d-8582-4a0c-8f04-e0e3eef0d9b0@isocpp.org> References: <19d8d86c-f4cf-47a9-bb42-9e2ba06dccab@isocpp.org> <4fb6a8b4-05a1-424e-88b1-275878e1f66a@isocpp.org> <4149a2b7-9081-474d-9cfd-81880c28cf30@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1155_1027003799.1534067154725" X-Trace: blaine.gmane.org 1534067031 16141 195.159.176.226 (12 Aug 2018 09:43:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Aug 2018 09:43:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBU4DYDNQKGQELOUBXHI@isocpp.org Sun Aug 12 11:43:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f69.google.com ([209.85.161.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fomuY-00046K-Rr for gclcip-std-proposals@m.gmane.org; Sun, 12 Aug 2018 11:43:47 +0200 Original-Received: by mail-yw1-f69.google.com with SMTP id z78-v6sf18743916ywa.23 for ; Sun, 12 Aug 2018 02:45:57 -0700 (PDT) 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=0oHCEWOJxSUPmwTYEjNNYQ49A0QC3X36OBuMdO3cNK0=; b=id+9QNJuhKdTO3z042RNF1M8F0Tit05i3Z+cWUR+UueGSCj3NnvC7xlJxRiSpefBiK jtfemFdSGR9kf9LLqiysCi0TU8IOTEbhgxcciXNmYWDOKM9SrOOPuO0MmjBNcvtVcRyW hw25LYhcAzE2nXOa5TSDHMdyB2iW7smO/cgXjpLymFvQX8yoLgtGe/0veG7Yrhz1fFg2 ZIFfjBVYiqffYiCKstcBJGF2UBMGBlvcQCdaGZHMg4L15jCdWNZTzcQnhWuizYNG4/Rr D7jX4d6hgd3bqTuubjmoPKxCKia6eSP2kRlUHDmDXP+iSdlOPAHUP6emD4Uta1XLs26+ Ru+A== 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=0oHCEWOJxSUPmwTYEjNNYQ49A0QC3X36OBuMdO3cNK0=; b=IBG+XYzpa1phPgW4lB/1HG8oeQOYaUvrDm64j2KeHgFg5muNT5ThJ1QVyxMkQxuy0s WRSiNnygDT/edY/Naayt9Wf3CTphnPcDHvx90/6E25TrZygDAt4br8Q2z+5+QWkzgqF9 OKNMvF2GHAWp0mjQ2jOjfnWuFMu9Vje36UxP6Ulao+DsVg5AaVOJCCrnwjR7tpyuIW35 Lbq7zBllGQCweHDbBhNOprVs97D0n/mBkaNJ2cTogwN0lYibZdVfBDzJzB7J+Y+rMRRh ZAVlQbVw8ohaPK959dwCpXT2fKYD4bn8X2XssvdLxsmkcJ/oZsJUA9LZSx+dkQ8UTHbu Dcdw== 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=0oHCEWOJxSUPmwTYEjNNYQ49A0QC3X36OBuMdO3cNK0=; b=rdUz2ZZv/81diPKvFpVt6zGhAlORp2xJcspGeqdxGPC1SENtXwlxfKTP4GzIqrDmi+ 54pAqGG91LtD6Trz3+D6oawkq6qfSIG8ROlDXVMosfSCrZWOYlhtwIPmagUuXu2oGrI4 gcZhUIiSIAtzWcIn3IloM7Ahfo0mvYL9v9lxlJmHjei1jayj/M4eoL17jDekwInQzJ4p xpRGz8sZdMWI2lD/2BxNOUCc3+dej9ncpnyel8K9pz9HGuHy2Ok68QJPgVAsYrDPm/wk fTnWbfJZZrfKzalw3ZaMeVjwdRq0OTYH2QHZ5x2eB+wo1jzk7BgadqGV7JtreTh+jU9L cpQg== X-Gm-Message-State: AOUpUlGmQoaCgdFRMRSd0EJM65xSBu6GX9CaGz1TRv//R1SNlGv8b9Rp pXkE+QqF+BKjLpjH7eIL3Z1pXA== X-Google-Smtp-Source: AA+uWPwPZOwbLGYencuaIcOCy8DuzGKpLHq3UkG0XT1CV1FqvQTVbnxOkydvWUs6P00BCIEMLWTDSQ== X-Received: by 2002:a0d:c083:: with SMTP id b125-v6mr3938401ywd.215.1534067157180; Sun, 12 Aug 2018 02:45:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:9c4f:: with SMTP id t76-v6ls2409279ywg.29.gmail; Sun, 12 Aug 2018 02:45:55 -0700 (PDT) X-Received: by 2002:a81:5705:: with SMTP id l5-v6mr293941ywb.6.1534067155299; Sun, 12 Aug 2018 02:45:55 -0700 (PDT) In-Reply-To: X-Original-Sender: florian.csdt@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:39727 Archived-At: ------=_Part_1155_1027003799.1534067154725 Content-Type: multipart/alternative; boundary="----=_Part_1156_1556936969.1534067154727" ------=_Part_1156_1556936969.1534067154727 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le dimanche 12 ao=C3=BBt 2018 02:02:55 UTC+2, Arthur O'Dwyer a =C3=A9crit : > > On Sat, Aug 11, 2018 at 1:32 PM, >=20 > wrote: > >> Le samedi 11 ao=C3=BBt 2018 20:57:25 UTC+2, Arthur O'Dwyer a =C3=A9crit = : >>> >>> >>> Ah. If I understand correctly, this is merely an artifact of our=20 >>> different definitions of "relocate." >>> For my P1144, "relocate =3D move + destroy," and therefore if you want = to=20 >>> customize how your type is "relocated," you just give it a user-provide= d=20 >>> move-constructor and/or a user-provided destructor =E2=80=94 the same t= hing you=20 >>> already do today. >>> For your scheme, as originally described, I said it was "relocate =3D= =20 >>> memcpy + fixup." You have now changed it (good!) to what I would call= =20 >>> "relocate =3D serialize + memcpy + deserialize." Now here's where we c= rossed=20 >>> wires. In your old scheme, I was using the term "relocate" to mean the= =20 >>> *entire* operation, but I now see that you were using the term=20 >>> "relocate" to mean *just the fixup half* of the operation. In your new= =20 >>> scheme, I assume, you would use the term "relocate" to mean *just the= =20 >>> deserialize part* of the operation. >>> So I now agree, under your terminology, P1144 does not permit the user= =20 >>> to define a "relocate" operation, because P1144 does not admit the=20 >>> existence of any such operation. P1144 doesn't have what I would call a= =20 >>> "fixup" or "deserialize" step. It *only* has move plus destroy. You=20 >>> agree that these two operations are both customizable by the user; you = just=20 >>> disagree that either of them, or the combination of both of them, shoul= d be=20 >>> known by the word "relocate." I strongly disagree, of course. :) >>> >> >> Wording is a tough topic. At the beginning, relocation meant the entire= =20 >> process (but as it was a single step, that was fine). Then, I needed a a= =20 >> second step before the other. And delocate was just the perfect name. Bu= t=20 >> now, I don't have any word to mean the entire process... So for now let'= s=20 >> stick to "full relocation". >> >> So full relocation =3D delocate + moving bytes around (optional) + reloc= ate >> > > Please find a verb that describes the entire process. In English (and=20 > standardese) you can't have the relationship > > $adverb $verb1 :=3D something + something + $verb1 > > That is, "full relocation" must by definition be *a kind of*=20 > "relocation." (What kind of relocation? Full relocation.) > You can't have "full relocation" meaning "relocation, but with two=20 > additional steps on the front that do not happen during any other kind of= =20 > relocation." > Please try to be understanding on this subject: I'm not a native english=20 speaker, so what you find natural might not be for me. Also, you might find names that I could not think of. So any help on this subject is appreciated. So let's stick to relocation meaing the whole process (this does not=20 include memcpy, though). =20 > > Compare: "Trivial relocation" means relocation that is trivial. > "Nothrow relocation" means relocation that is nothrow. > (And in my last response, "efficient relocation" meant "relocation that i= s=20 > efficient.") > > So for this message (and this message only), I'll use the verb=20 > "fullrelocate" as meaning "delocate + memcpy + relocate", but I'm not goi= ng=20 > to use that verb any more after that. > > I strongly, strongly suggest that you adopt the verb "relocate" as meanin= g=20 > "deserialize + memcpy + serialize" (that is, replace your "operator=20 > relocate" with an "operator serialize"). That will bring your terminology= =20 > into line with the terminology that has been established in previous=20 > discussions in this forum (by myself, Nicol, Niall, Facebook Folly, EASTL= ,=20 > etc.) > I'm not really happy with serialize/deserialize, as it is almost always=20 used for communication or storage. This is not what I'm proposing is about.= =20 But I'm fine sticking to it until we find better names. Please also note that serialization has the same defect as my previous=20 naming: the word "serialization" is sometime used to refer to the whole=20 process. So for now, and until we find better names: relocate =3D serialize +=20 deserialize =20 > > [...] > >> Okay, agreed. >>> Your old scheme defined "entireprocess =3D memcpy + relocate" (where I= =20 >>> would say "relocate =3D memcpy + fixup"). So for me, "nothrow relocata= ble"=20 >>> means "the entire process is nothrow", whereas for you, "nothrow=20 >>> relocatable" means "just the fixup step is nothrow." >>> >> >> As delocate/relocate have no meaning on their own, when I say a type is= =20 >> [trivially|nothrow] relocatable, I mean the entire process is=20 >> [trivially|nothrow] relocatable. >> > > Again, that's not how English works. "Trivially relocatable" *by=20 > definition* means that the relocate operation, the relocation, is=20 > trivial. You are allowed to make up words, but you still have to put them= =20 > together in the ways that have been established for communication over th= e=20 > past ~2000 years. > > Also, it doesn't make any sense to say that a "process" is trivially=20 > relocatable. I infer that you meant to say *the entire process of=20 > fullrelocation is [trivial|nothrow]*. > The way you'd express that concisely in English is "the type is=20 > [trivially|nothrow] fullrelocatable." This is why it's important to have= a=20 > word for the entire process! (And we do: everyone but you calls the enti= re=20 > process by the word "relocation.") > > I agree. Also we still don't share the same definition of relocation even= =20 when relocation refers to the entire process for me. =20 > > and it is also possible to have copyable movable types that are not=20 >>>> relocatable. >>>> >>> >>> ...because you define "relocatable" to mean not just=20 >>> "gettable-from-point-A-to-point-B" but "gettable *by this specific=20 >>> mechanism* involving `operator relocate`." >>> >> So by your definition, IIUC, std::string would not be relocatable at=20 >>> all; boost::unique_ptr would not be relocatable at all; folly::FBVector= =20 >>> would not be relocatable at all... >>> >> >> Of course they would be. Why wouldn't they? >> Those are just pointers, and pointers are trivially relocatable. So the= =20 >> compiler generated operators delocate/relocate would also be trivially= =20 >> relocatable. >> > > Please explain how you propose to do this for boost::unique_ptr, without= =20 > completely breaking std::list. > You do like for move semantic: you go the other way around by defining=20 explicitly operator serialize/deserialize for std::list. template class list { private: struct node { node *previous, *next; }; struct data_node : node { T data; }; =20 node sentinel; public: list() : sentinel{&sentinel, &sentinel} {} list(const list&); list(list&& other) : sentinel(other.empty() ? node{&sentinel, &sentinel= }=20 : other.sentinel) { other.sentinel.previous =3D &other.sentinel; other.sentinel.next =3D &other.sentinel; } list& operator=3D(const list&); list& operator=3D(list&&); ~list(); bool empty() const { return sentinel.next =3D=3D &sentinel; } void operator serialize() { if (empty()) { sentinel.previous =3D nullptr; sentinel.next =3D nullptr; } } void operator deserialize() { if (sentinel.next) { // list is not empty sentinel.next->previous =3D &sentinel; sentinel.previous->next =3D &sentinel; } else { sentinel.next =3D &sentinel; sentinel.previous =3D &sentinel; } } }; =20 > Appendix C of P1144=20 > =20 > will be useful to you; it lists four situations that can make a type=20 > non-trivially relocatable. > I agree with those 4 cases. But the compiler cannot reliably detect those= =20 (at least not in the general case). The most you could do is make this UB= =20 (which is actually a good idea). =20 > > > I agree with the two last versions (YellowPtr and GreenPtr), But I=20 >> completely disagree with the first one: >> template >> class RedPtr /* red like: super green */ { >> private: >> T* m_ptr; >> public: >> RedPtr(RedPtr&&); >> ~RedPtr(); >> >> // void operator delocate() =3D default; // autogenerated by the=20 >> compiler >> // void operator relocate() =3D default; // autogenerated by the=20 >> compiler >> }; >> >> static_assert(is_florian_relocatable_v>); >> static_assert(is_florian_trivially_relocatable_v>); // int*= =20 >> is trivially relocatable so behavior is "inherited" >> > > You are proposing that this type should be considered trivially=20 > fullrelocatable, even though the compiler has no idea what its move=20 > constructor and destructor do. > Yes. Most types use pointers either to allocate memory (and this memory is= =20 not relocated when the object is), or to reference to preexisting objects= =20 that will not be relocated at the same time as the first one. Only in your 4 cases it will not work, but that's not for so many types. In= =20 those cases, you would need to explicitly define/delete your=20 serialize/deserialize. =20 > Please explain, in the form of a code sample, how you envision a library= =20 > would take advantage of the fullrelocation operation to speed up a common= =20 > operation (such as std::vector::resize or std::swap =E2=80=94 but I'll ac= cept=20 > different examples too). Remember, your library is not allowed to segfaul= t=20 > when presented with std::list. > > Here is swap. std::list will not segfault because we defined operator=20 serialize/deserialize for it (see above). template void swap(T& a, T& b) { if constexpr (is_nothrow_relocatable_v) { a.serialize(); b.serialize(); byte pa =3D reinterpret_cast(&a); byte pb =3D reinterpret_cast(&b); =20 swap_ranges(pa, pa+sizeof(T), pb); a.deserialize(); b.deserialize(); } else { T c =3D std::move(a); a =3D std::move(b); b =3D std::move(c); } } =20 > > Your code looks like an offset pointer whose range is limited. An offset= =20 >> pointer is a tricky question in general. >> > > Yes, it is. Does your proposed library segfault when presented with=20 > offset_ptr? P1144 does not. > > If offset_ptr is made non-relocatable, then my proposed library will not=20 segfault as it will fallback to move. If offset_ptr is kept implicitly relocatable, then it will depend on how it= =20 will be used. For instance, we can teach people to pointers to point outside the object= =20 and offset_ptr to point within the object. Their types will then be safely= =20 relocatables. And if they need a pointer to point within the object or an offset_ptr to= =20 point outside the object, then they would need to define/delete relocation. The former is safer, while the latter would lead to more effeicient code,= =20 but also more efforts. =20 > So I would say the NearPtr shouldn't relocatable to be safe >> > > Please describe how your compiler would ensure that NearPtr was *not*=20 > considered trivially fullrelocatable, *yet, at the same time*, ensure=20 > that RedPtr was considered trivially fullrelocatable. > > =E2=80=93Arthur > struct NearPtr { /* ... */ void operator serialize() =3D delete; }; The main problem you are trying to highlight with my design is: either=20 almost no types would be made implicitly relocatable, or we will have=20 false-positive. While I agree with this concern, I also want to point that your design has= =20 the same defect to a certain extent. The 4 cases you expressed are great, but are not bound to a type in the=20 general case (it cannot be detected reliably by the compiler). We could=20 make it UB, but we cannot go further than that. What we can do is tweaking the implicit generation of serialize/deserialize= =20 depending on the copy/move behaviour of the object. Exactly like what has been done when introducing move semantics. If copy/move are defaulted, implicitly generating serialize/deserialize is= =20 fine. If copy/move are defined but not defaulted, it is arguable, but I think=20 implicitly generating serailize/deserialize is also fine (std::vector for= =20 instance). If copy is deleted, I'm not sure... If copy and move are deleted, the safest would be to not generate=20 serialize/deserialize --=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/05cd596d-8582-4a0c-8f04-e0e3eef0d9b0%40isocpp.or= g. ------=_Part_1156_1556936969.1534067154727 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le dimanche 12 ao=C3=BBt 2018 02:02:55 UTC+2, Arth= ur O'Dwyer a =C3=A9crit=C2=A0:
On Sat, Aug 11, 2018 at 1:32 PM, = <f= loria...@gmail.com> wrote:
Le samedi 11 ao=C3=BBt 2018 20:57:25 UTC= +2, Arthur O'Dwyer a =C3=A9crit=C2=A0:

Ah. If I under= stand correctly, this is merely an artifact of our different definitions of= "relocate."
For my P1144, "relocate =3D move + de= stroy," and therefore if you want to customize how your type is "= relocated," you just give it a user-provided move-constructor and/or a= user-provided destructor =E2=80=94 the same thing you already do today.
For your scheme, as originally described, I said it was "reloc= ate =3D memcpy + fixup." =C2=A0You have now changed it (good!) to what= I would call "relocate =3D serialize + memcpy + deserialize." = =C2=A0Now here's where we crossed wires.=C2=A0 In your old scheme, I wa= s using the term "relocate" to mean the entire operation, = but I now see that you were using the term "relocate" to mean = just the fixup half of the operation.=C2=A0 In your new scheme, I assum= e, you would use the term "relocate" to mean just the deserial= ize part of the operation.
So I now agree, under your termino= logy, P1144 does not permit the user to define a "relocate" opera= tion, because P1144 does not admit the existence of any such operation. P11= 44 doesn't have what I would call a "fixup" or "deserial= ize" step. It only has move plus destroy. You agree that these = two operations are both customizable by the user; you just disagree that ei= ther of them, or the combination of both of them, should be known by the wo= rd "relocate." =C2=A0I strongly disagree, of course. :)

Wording is a tough to= pic. At the beginning, relocation meant the entire process (but as it was a= single step, that was fine). Then, I needed a a second step before the oth= er. And delocate was just the perfect name. But now, I don't have any w= ord to mean the entire process... So for now let's stick to "full = relocation".

So full relocation =3D delocate = + moving bytes around (optional) + relocate

Please find a verb that describes the entire process. In E= nglish (and standardese) you can't have the relationship

=
=C2=A0 =C2=A0 $adverb $verb1 :=3D something + something + $verb1=

That is, "full relocation" must by defi= nition be a kind of "relocation." (What kind of relocation= ? Full relocation.)
You can't have "full relocation"= ; meaning "relocation, but with two additional steps on the front that= do not happen during any other kind of relocation."
=

Please try to be understanding on th= is subject: I'm not a native english speaker, so what you find natural = might not be for me.
Also, you might find names that I could not = think of.
So any help on this subject is appreciated.
<= br>
So let's stick to relocation meaing the whole process (th= is does not include memcpy, though).
=C2=A0

Compare: "Trivial relocation" means re= location that is trivial.
"Nothrow relocation" means re= location that is nothrow.
(And in my last response, "efficie= nt relocation" meant "relocation that is efficient.")
<= div>
So for this message (and this message only), I'll us= e the verb "fullrelocate" as meaning "delocate + memcpy + re= locate", but I'm not going to use that verb any more after that.

I strongly, strongly suggest that you adopt the ver= b "relocate" as meaning "deserialize + memcpy + serialize&qu= ot; (that is, replace your "operator relocate" with an "oper= ator serialize"). That will bring your terminology into line with the = terminology that has been established in previous discussions in this forum= (by myself, Nicol, Niall, Facebook Folly, EASTL, etc.)

I'm not really happy with serialize/deserialize, a= s it is almost always used for communication or storage. This is not what I= 'm proposing is about. But I'm fine sticking to it until we find be= tter names.
Please also note that serialization has the same defect as m= y previous naming: the word "serialization" is sometime used to r= efer to the whole process.

So for now, and until we find better name= s: relocate =3D serialize + deserialize
=C2=A0

[...]
Okay, ag= reed.
Your old scheme defined "entireprocess =3D memcpy = + relocate" (where I would say "relocate =3D memcpy + fixup"= ).=C2=A0 So for me, "nothrow relocatable" means "the entire = process is nothrow", whereas for you, "nothrow relocatable" = means "just the fixup step is nothrow."

As delocate/relocate have no meaning on the= ir own, when I say a type is [trivially|nothrow] relocatable, I mean the en= tire process is [trivially|nothrow] relocatable.

Again, that's not how English works. "Trivially = relocatable" by definition means that the relocate operation, t= he relocation, is trivial. You are allowed to make up words, but you still = have to put them together in the ways that have been established for commun= ication over the past ~2000 years.

Also, it doesn&= #39;t make any sense to say that a "process" is trivially relocat= able.=C2=A0 I infer that you meant to say the entire process of fullrelo= cation is [trivial|nothrow].
The way you'd express that c= oncisely in English is "the type is [trivially|nothrow] fullrelocatabl= e." =C2=A0This is why it's important to have a word for the entire= process! =C2=A0(And we do: everyone but you calls the entire process by th= e word "relocation.")


I agree. Also we still don't share the same= definition of relocation even when relocation refers to the entire process= for me.
=C2=A0

=
and it is also possible to have copyable movable types that are not reloc= atable.

...because you define &= quot;relocatable" to mean not just "gettable-from-point-A-to-point-B" but "gettable by this specific mechanism involvi= ng `operator relocate`."
= =C2=A0So by your definition, IIUC, std::string would not be relocatable at = all; boost::unique_ptr would not be relocatable at all; folly::FBVector wou= ld not be relocatable at all...
Of course they would be. Why wouldn't they?
Those are just pointers, and pointers are trivially relocatable. So the = compiler generated operators delocate/relocate would also be trivially relo= catable.

Please explain how you= propose to do this for boost::unique_ptr, without completely breaking std:= :list.

You do like = for move semantic: you go the other way around by defining explicitly opera= tor serialize/deserialize for std::list.
template <class T>
class lis= t {=
=C2=A0 private:
=C2=A0 =C2=A0 struct node {
=C2=A0 =C2=A0 =C2=A0 node = *previous, *next;
=C2=A0 =C2=A0 };
=C2=A0 =C2=A0 struct data_node : node {
=C2=A0 = =C2=A0 =C2=A0 T data;
=C2=A0 =C2=A0 };
=C2=A0 =C2=A0
=C2=A0 =C2=A0 node sentinel;
=C2=A0 public:
=C2=A0 =C2=A0 list() : sentinel{&sentinel,= &sentinel} {}
=C2=A0 =C2=A0 list(const list&);
=C2=A0 =C2=A0 list(list&& other)= :<= span style=3D"color: #000;" class=3D"styled-by-prettify"> sentinel(other.empty() ? node{&a= mp;sentine= l,<= span style=3D"color: #000;" class=3D"styled-by-prettify"> &sentinel} : other.sentinel= ) <= span style=3D"color: #660;" class=3D"styled-by-prettify">{
=C2=A0 =C2=A0 =C2=A0 ot= her.sentinel<= span style=3D"color: #660;" class=3D"styled-by-prettify">.previous =3D &other.sentinel;
=C2=A0 =C2=A0 =C2=A0 other.sentinel.next =3D &other.sentinel;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 list& operator=3D(const list&am= p;);
= =C2=A0 =C2=A0 list& operat= or=3D(list&&);<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = ~list();

=C2=A0 =C2=A0 bool empty() const {
=C2=A0 =C2=A0 =C2=A0 return sentinel.next =3D= =3D &sentinel;
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 void operator serialize() {
=C2=A0 =C2=A0 =C2=A0 if (= empty()) {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 sentinel.previou= s =3D nullptr;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sent= inel.next =3D nullptr;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 void operator deserialize() = {
=C2= =A0 =C2=A0 =C2=A0 if= (<= span style=3D"color: #000;" class=3D"styled-by-prettify">sentinel.next) { // list is not empty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sentinel.next->previous =3D &sentinel;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 sentinel.previous->next =3D &sentinel;
=C2=A0 =C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sentinel.next =3D &sent= inel;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 sentinel.previous =3D = &sentinel= ;
=C2=A0 =C2=A0 =C2=A0 <= /span>}
=C2=A0 =C2=A0 }
};

<= br>

=C2=A0
Appendix C of P1144 will be useful to you; it lists four sit= uations that can make a type non-trivially relocatable.

I agree with those 4 cases. But the co= mpiler cannot reliably detect those (at least not in the general case). The= most you could do is make this UB (which is actually a good idea).
=C2=A0


I agree with the two last versions (YellowPtr and GreenPtr), But I compl= etely disagree with the first one:
template <class T>
class<= /span> RedPtr /* red like: super green */ {
=C2=A0 private:
=C2=A0 =C2=A0 T* m_ptr;=C2=A0 public:
=C2= =A0 =C2=A0 RedPtr(= RedPtr&&);
=C2=A0 =C2=A0 ~RedPtr();

=C2=A0 =C2=A0// = void operator delocate() =3D default; // autogenerated by the compiler
=C2=A0 =C2=A0// void operator relocate() =3D default; // autogenerate= d by the compiler
};
static_assert(is_fl= orian_relocatable_v<RedPtr<int>>);=
static_assert(is_florian_trivially_relocatable_v<RedPtr<int= >>); // int* is tr= ivially relocatable so behavior is "inherited"

You are proposing that = this type should be considered trivially fullrelocatable, even though the c= ompiler has no idea what its move constructor and destructor do.

Yes. Most types use pointers = either to allocate memory (and this memory is not relocated when the object= is), or to reference to preexisting objects that will not be relocated at = the same time as the first one.
Only in your 4 cases it will not = work, but that's not for so many types. In those cases, you would need = to explicitly define/delete your serialize/deserialize.
=C2= =A0
Please explain, in the form of a code samp= le, how you envision a library would take advantage of the fullrelocation o= peration to speed up a common operation (such as std::vector::resize or std= ::swap =E2=80=94 but I'll accept different examples too). Remember, you= r library is not allowed to segfault when presented with std::list.


Here is swa= p.
std::list will not segfault because we defined operator serial= ize/deserialize for it (see above).
template <class T>
= void swap<= /span>(T& a, T& b) {
=C2=A0 if constexpr (is_nothrow_relocatable_v<T>) {
= =C2=A0 =C2=A0 a.seri= alize();
=C2=A0 = =C2=A0 b.<= /span>serialize();

=C2=A0 =C2= =A0 byte pa <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D reinterpret_cast<byte*>(&a);
=C2=A0 =C2=A0 byte pb =3D r= einterpret_cast<b= yte*>(&= amp;b);
=C2=A0 =C2=A0
= =C2=A0 =C2=A0 swap_ranges(pa,<= /span> pa<= span style=3D"color: #660;" class=3D"styled-by-prettify">+sizeof(T), pb);

=C2=A0 =C2=A0 a.deserialize();
=C2=A0 =C2=A0 b.deserialize();
= =C2=A0 } else {
=C2=A0 =C2=A0 T c =3D std::move(a);<= /span>
=C2=A0 = =C2=A0 a = =3D std::move(b);
=C2=A0 =C2=A0 b =3D std::move(c<= /span>);
=C2=A0 <= span style=3D"color: #660;" class=3D"styled-by-prettify">}
}


=C2=A0

Your code looks like an offset pointer whose ra= nge is limited. An offset pointer is a tricky question in general.

Yes, it is. Does your proposed libr= ary segfault when presented with offset_ptr?=C2=A0 P1144 does not.


If offset_pt= r is made non-relocatable, then my proposed library will not segfault as it= will fallback to move.

If offset_ptr is kept impl= icitly relocatable, then it will depend on how it will be used.
F= or instance, we can teach people to pointers to point outside the object an= d offset_ptr to point within the object. Their types will then be safely re= locatables.
And if they need a pointer to point within the object= or an offset_ptr to point outside the object, then they would need to defi= ne/delete relocation.

The former is safer, while t= he latter would lead to more effeicient code, but also more efforts.
=C2=A0
So I would say the NearPtr shouldn't relocat= able to be safe

Please describe= how your compiler would ensure that NearPtr was not considered triv= ially fullrelocatable, yet, at the same time, ensure that RedPtr was= considered trivially fullrelocatable.

=E2=80=93Ar= thur

struct NearPtr {
=C2=A0 /* ... */
=C2=A0 void operator serialize() =3D delete;
};


The main problem you are trying to highlight with my design is: either= almost no types would be made implicitly relocatable, or we will have fals= e-positive.
While I agree with this concern, I also want to point= that your design has the same defect to a certain extent.
Th= e 4 cases you expressed are great, but are not bound to a type in the gener= al case (it cannot be detected reliably by the compiler). We could make it = UB, but we cannot go further than that.

What we ca= n do is tweaking the implicit generation of serialize/deserialize depending= on the copy/move behaviour of the object.
Exactly like what has = been done when introducing move semantics.

If copy= /move are defaulted, implicitly generating serialize/deserialize is fine.
If copy/move are defined but not defaulted, it is arguable, but I = think implicitly generating serailize/deserialize is also fine (std::vector= =C2=A0 for instance).
If copy is deleted, I'm not sure...
If copy and move are deleted, the safest would be to not generate se= rialize/deserialize

--
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/05cd596d-8582-4a0c-8f04-e0e3eef0d9b0= %40isocpp.org.
------=_Part_1156_1556936969.1534067154727-- ------=_Part_1155_1027003799.1534067154725-- .