220 25484 <42c08c4f-dae2-4705-922b-a1ddf8ca7839@isocpp.org> article Path: news.gmane.org!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Fri, 8 Apr 2016 11:51:42 -0700 (PDT) Lines: 738 Approved: news@gmane.org Message-ID: <42c08c4f-dae2-4705-922b-a1ddf8ca7839@isocpp.org> References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> <30181f63-7189-494d-9294-3f8b8759308f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1046_1148487956.1460141502506" X-Trace: ger.gmane.org 1460141509 31616 80.91.229.3 (8 Apr 2016 18:51:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 18:51:49 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBQH3T64AKGQECURCI6Y@isocpp.org Fri Apr 08 20:51:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aobVS-0003yL-6S for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 20:51:46 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id g133sf151100140ywb.0 for ; Fri, 08 Apr 2016 11:51:45 -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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ENNp6G7ZS39I2pZiZUg6nN47nPv0ZHLYHj1AKYzj+BQ=; b=kJo4ttrFtYtkRSiARs76K6u6KroenJZ7hBdHLAahH3KPhEcgn9XGOWD2vyu0mx9oGT 8KHVS+2xOiBTcmncxOXWAIdbuW8t3SgjkIaR1O1r4BufZsoAnTOfbVQ1eaiXpHalmvOU kTKTv78SSU3yBHK6FsMLqPD+Ymx/E63vCXwXyCWdXoNVGOeRo/70nFkoJP9fDALPeBDa BWGtkZtwxHFMTS1Yzls04pIyJ2KPk7Fd49gMeOZ0+nGkurjVtYg2j9YiZ1C/cTfqze7z Hf9y8fJC31B7/lVZhenuJvtw/87VQdcNms2VzEskcn9FAiBIC/YjFKLpZ1rOgb58CiD4 fUZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=ENNp6G7ZS39I2pZiZUg6nN47nPv0ZHLYHj1AKYzj+BQ=; b=T9odPG8JcHha1PzzL/OnlKeGzdfsc0XkmyFTFCKl5raf5MOtyS2uUGo2RRc85XQNtj 9uMyYVPqpWZjpfHh+0lOtM8zFkBGcSFTlSw5pkpUoh7K9GE/0/TdPFr7o5cj9VQl+0Xm ZJHw3693WOY6ZyQ9NsFMduezr0PaJEms3zLjBVkRp4PyIkrdgxc0Kt+sJQvFPs1L52cR s0WrBramgdRTVh5zXY2toIostXVO65Nq4OvIfcBRQKB1wPHortHW7bfRClOROPRKBKj9 s+beRawStWGQRpQQHvnrk08urFuce6f9MwmjwFuK/WHtXVI2q0LJuW8Nr7JSiLzZrk2O vUgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=ENNp6G7ZS39I2pZiZUg6nN47nPv0ZHLYHj1AKYzj+BQ=; b=CSdszIFMuKysMXhl5D06xoDAKYPbOw2Y1z3IBKJ2fgDD66bfrmFwMmbbx0M25FpESK kq9q8AR9EXS7RwbMM4IKXrRR4VWjJRJUlojZY5yKBxig2AgNwVqMxh1pHvKgQFJ2xJjY KG5MeYos5AEjFDMADDJwVtYNpKM5f7hoXzsiQR7L2wbDqb2Pl8hlxDY1dL8wcT9iJFVL FYqkn5o0g2cJFsqkRz+JvchC+5BFG5W6mfDZKYhFyIknvH2151Vgni4eAyNUacbe5I9g mD9u9PJjKlooSIZHxTCi4FYXSgRQWWk0MDuQlQumNgR1tHvH6EeWcYHMmvw6BYlBO6Ft ErhA== X-Gm-Message-State: AD7BkJK3SmAJbI9mAVp/36MIubMmTrWpd7ZoCXGOCGt2X799+BHf26SfvMXKY786prj1Yw== X-Received: by 10.129.79.142 with SMTP id d136mr6871648ywb.9.1460141505115; Fri, 08 Apr 2016 11:51:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.112.129 with SMTP id iq1ls272748igb.17.gmail; Fri, 08 Apr 2016 11:51:43 -0700 (PDT) X-Received: by 10.50.129.97 with SMTP id nv1mr124018igb.7.1460141503652; Fri, 08 Apr 2016 11:51:43 -0700 (PDT) In-Reply-To: X-Original-Sender: inkwizytoryankes@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:25484 Archived-At: ------=_Part_1046_1148487956.1460141502506 Content-Type: multipart/alternative; boundary="----=_Part_1047_829198281.1460141502508" ------=_Part_1047_829198281.1460141502508 Content-Type: text/plain; charset=UTF-8 On Friday, April 8, 2016 at 4:12:03 PM UTC+2, Nicol Bolas wrote: > > On Friday, April 8, 2016 at 2:07:17 AM UTC-4, isocp...@denisbider.com > wrote: >> >> Ah, Jesus. >> >> It seems to me C++ has become infested with people who call themselves >> "modern", but whose objective is to desperately try to divorce the >> language from its low-level origins, while ashamedly having to recognize >> that this cannot be done, because it would defeat the purpose of the >> language and make it useless for its primary role. >> >> You are now building this over-ambitious standard library monstrosity, >> which is trying to pretend that C++ can be a platform. But the role of C++ >> is not to *be* a platform. It is a tool for *building* platforms, and >> for building applications on top of existing platforms. >> >> I can honestly say I don't like what you're doing, and if you keep going >> in this direction, C++ will have to be replaced with something that serves >> its original purpose. >> >> Stop trying to make this a managed language, for god's sake. >> > > ... So Sean points out how move support introduced a plethora of new value > categories in order to ensure that it does not get automatically used in > the wrong place. To make sure that it's reasonably safe and usable for most > programmers. And he suggests that you should investigate this sort of thing > as a way to make sure that your "relocation" is also reasonably safe, that > it gets used automatically where appropriate, and that it doesn't get used > in improper places. And so forth. > > And your response to this is to claim that such commentary comes from > people who are "infesting" the > language, that even that we make the language *as safe as it currently is* > represents an attempt to "make this a managed language", and so forth. > You're basically saying that your design is perfect as is, and anyone who > questions it in the name of safety is "desperately try[ing] to divorce the > language from its low-level origins." > > Seriously, are you *five-years old*? > > And let's not forget the implied insult to the standards committee that > their design for move support is wrong because it actually includes such > safety features. > > Personally, my basic criticism of your proposal is that it's not even > really half of a proposal. You can only "relocate" objects who's lifetimes > are governed by `new/delete` or placement new/explicit destructor calls. > That is, not automatic objects. You're basically taking the *easy part* > of destructive move/relocation, and then pretending that you have a > complete "relocation" feature. > > If your relocation support can't even perform relocation in this most > simple of cases: > > std::list SomeFunc() > { > std::list lt = ... > ... > return lt; //Insert syntax for relocation-returning, if needed > } > > Then *what good is it*? > > In fact, there is *no way* in your proposal to relocate an object into a > return value. Not even with P0135's guaranteed elision mechanics. Since you > can only relocate an object through the use of `new`, and return values > aren't created by `new`, there is no way to use relocation on simple return > values. > > So again, *what good is this?* > > That's where the "safety" argument that Sean is making comes from. Your > proposal only works with features that are inherently unsafe and that > programmers increasingly do not use with any particular frequency. Unlike > `move`, which works on *all object*s, automatic and non-automatic alike. > > That's the basic point that Sean is (or seems to be) making about your > proposal. You cannot use your proposal without calling upon deep-magic > levels of C++, like placement new and so forth. Your features is brittle, > incomplete, and painful to use. > > Allow me to restate your asinine "scalpel" analogy/conversation to better > explain this: > > Surgeon: I propose this new scalpel, which does these things better than >> the old scalpel. >> Committee: But it doesn't do things better than the old scalpel. It >> doesn't even work most of the time. >> Surgeon: Sure it does. See, it works just fine if you stand on your head, >> and it does things even better than the old one. >> Committee: But... most people stopped performing surgery while standing >> on their head years ago. >> Surgeon: Isn't it up to the surgeon to decide how he wants to perform >> surgery? >> Committee: That's old style thinking. In modern surgery, we want tools >> that work with how we actually operate on people, not tools that force us >> to operate in a specific way. Especially ones known to be bad. >> Surgeon: But the old scalpel has no such protections either. The old >> scalpel is just... a scalpel. >> Committee: That's not true at all. The old scalpel works just fine when >> standing normally. >> Surgeon: How would we even design a scalpel that does what this does >> without having to stand on your head? >> Committee: Put some effort into it, rather than doing the bare minimum >> that you feel you can get away with. Make a *complete* scalpel. >> > > In this analogy, "stand on your head" mean "using new/delete or placement > new and explicit destructor calls". > > Indeed, it's not clear to me why it is that your proposal needs to be a > language feature at all. N4034 was able to do what you're talking about > purely as a standard library thing. All it would need to do is say that the > function ends the lifetime of the source object, and that the source object > must not be an automatic object. > > You can even have implicitly generated versions which will simply perform > a move from the source to the destination, followed by a destructor call on > the source. It would be deleted for any type `T` who's move constructor is > not `noexcept`. > I think biggest problem is trying to shoehorn destructive move to object with custom destructor. We already have types that have "destructive move", there are PODs. They need wrapper that manage lifetime of data from internal object. Great example of this is `unique_ptr` that manage raw pointer. We could even expand this to `unique_vector` that will manage array of unique pointers. Extracting one pointer from it will only need one `memmove` operation, inserting new will need only this too. I think that is possible to create today library that will handle that kind of types: struct pod { int x, y; friend void init(pod*); //pseudo constructor friend void destroy(pod*); //pseudo destructor friend void move(pod*, pod*); //pseudo copy constructor, if not find library use memcopy }; template class Warper { static_assert(std::is_pod

(), "Type need to be POD"); P p; public: Warper() : p{} { init(&p); } ~Warper() { destroy(&p); } }; template class Warper_vector; template class Warper_movable { static_assert(std::is_pod

(), "Type need to be POD"); friend class Warper_vector

; bool empty; P p; public: Warper_movable() : empty{false}, p{} { init(&p); } Warper_movable(Warper_movable&& r) : empty{false}, p{} { move(&r.p, &p); r.empty = true; } ~Warper_movable() { if (!empty) destroy(&p); } }; template class Warper_vector { static_assert(std::is_pod

(), "Type need to be POD"); std::vector

v; public: Warper_vector() : v(10) { for (auto& p : v) init(&p); } ~Warper_vector() { for (auto& p : v) destroy(&p); } void push_back(Warper_movable

&& r) { v.push_back(r.p); //no destructors or constructors calls r.empty = true; //we can now optimalzie out `Warper_movable` call to `destroy`. } }; int main() { Warper_vector vec; for (int i = 0; i < 10; ++i) { Warper_movable obj; vec.push_back(std::move(obj)); } } //`init` and `destroy` is call 20 times -- 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/42c08c4f-dae2-4705-922b-a1ddf8ca7839%40isocpp.org. ------=_Part_1047_829198281.1460141502508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Friday, April 8, 2016 at 4:12:03 PM UTC+2, Nico= l Bolas wrote:
On Friday, April 8, 2016 at 2:07:17 AM UTC-4, isocp...@denisbider.com wrote:
Ah, = Jesus.

It seems to me C++ has become infested with= people=C2=A0who call themselves "modern", but whose=C2=A0objecti= ve is to=C2=A0desperately try to divorce=C2=A0the language=C2=A0from its lo= w-level origins, while=C2=A0ashamedly having to=C2=A0recognize that this ca= nnot be done, because it would defeat the purpose of the language and make = it useless for its primary role.

You are now build= ing this over-ambitious standard library monstrosity, which is=C2=A0trying = to pretend that C++ can be a platform. But the=C2=A0role of C++ is not to <= i>be a platform. It is a tool for building platforms, and for bu= ilding applications on top of existing platforms.

= I can honestly say I don't like what you're doing, and if you keep = going in this direction, C++ will have to be replaced with something that s= erves its original purpose.

Stop trying to make th= is a managed language, for god's sake.
... So Sean points out how move support introduced a plethora of new value= categories in order to ensure that it does not get automatically used in t= he wrong place. To make sure that it's reasonably safe and usable for m= ost programmers. And he suggests that you should investigate this sort of t= hing as a way to make sure that your "relocation" is also reasona= bly safe, that it gets used automatically where appropriate, and that it do= esn't get used in improper places. And so forth.

And your respon= se to this is to claim that such commentary c= omes from people who are "infesting" the language, that even = that we make the language as safe as it currently is represents an a= ttempt to "make this a managed language", and so forth. You'r= e basically saying that your design is perfect as is, and anyone who questi= ons it in the name of safety is "desperately try[ing] to divorce=C2=A0= the language=C2=A0from its low-level origins."

Seriously, are y= ou five-years old?

And let's not forget the implied insul= t to the standards committee that their design for move support is wrong be= cause it actually includes such safety features.

Personally, my basi= c criticism of your proposal is that it's not even really half of a pro= posal. You can only "relocate" objects who's lifetimes are go= verned by `new/delete` or placement new/explicit destructor calls. That is,= not automatic objects. You're basically taking the easy part of= destructive move/relocation, and then pretending that you have a complete = "relocation" feature.

If your relocation support can't= even perform relocation in this most simple of cases:

std::list<T> SomeFunc()
{
=C2=A0 std::list<T> lt =3D ...
=C2=A0 ...
=C2=A0 return lt; = //Insert syntax for relocation-returning, if nee= ded
= }

Then what good is it?

In fact,= there is no way in your proposal to relocate an object into a retur= n value. Not even with P0135's guaranteed elision mechanics. Since you = can only relocate an object through the use of `new`, and return values are= n't created by `new`, there is no way to use relocation on simple retur= n values.

So again, what good is this?

That's wher= e the "safety" argument that Sean is making comes from. Your prop= osal only works with features that are inherently unsafe and that programme= rs increasingly do not use with any particular frequency. Unlike `move`, wh= ich works on all objects, automatic and non-automatic alike.

= That's the basic point that Sean is (or seems to be) making about your = proposal. You cannot use your proposal without calling upon deep-magic leve= ls of C++, like placement new and so forth. Your features is brittle, incom= plete, and painful to use.

Allow me to restate your asinine "sc= alpel" analogy/conversation to better explain this:

Surgeon: I propose this new scalpel,= which does these things better than the old scalpel.
Committee: But it = doesn't do things better than the old scalpel. It doesn't even work= most of the time.
Surgeon: Sure it does. See, it works just fine if you= stand on your head, and it does things even better than the old one.
Co= mmittee: But... most people stopped performing surgery while standing on th= eir head years ago.
Surgeon: Isn't it up to the surgeon to decide ho= w he wants to perform surgery?
Committee: That's old style thinking.= In modern surgery, we want tools that work with how we actually operate on= people, not tools that force us to operate in a specific way. Especially o= nes known to be bad.
Surgeon: But the old scalpel has no such protection= s either. The old scalpel is just... a scalpel.
Committee: That's no= t true at all. The old scalpel works just fine when standing normally.
S= urgeon: How would we even design a scalpel that does what this does without= having to stand on your head?
Committee: Put some effort into it, rathe= r than doing the bare minimum that you feel you can get away with. Make a <= i>complete scalpel.

In this analogy, "sta= nd on your head" mean "using new/delete or placement new and expl= icit destructor calls".

Indeed, it's not clear to me why it= is that your proposal needs to be a=20 language feature at all. N4034 was able to do what you're talking about= =20 purely as a standard library thing. All it would need to do is say that=20 the function ends the lifetime of the source object, and that the source object must not be an automatic object.

You can even have implicitl= y generated versions which will simply perform a move from the source to th= e destination, followed by a destructor call on the source. It would be del= eted for any type `T` who's move constructor is not `noexcept`.
=C2=A0
=C2=A0I think biggest prob= lem is trying to shoehorn destructive move to obje= ct with custom destructor. We already have types that have "destructiv= e move", there are PODs. They need wrapper that manage lifetime of dat= a from internal object. Great example of this is `unique_ptr` that manage r= aw pointer. We could even expand this to `unique_vector` that will manage a= rray of unique pointers. Extracting one pointer from it will only need one = `memmove` operation, inserting new will need only this too.

I think = that is possible to create today library that will handle that kind of type= s:

st= ruct pod{=
=C2=A0 =C2=A0= int x, y;
=C2=A0 =C2=A0 friend void init(= pod*); //pseudo constructor
=C2=A0 = =C2=A0 fri= end void destroy(pod*); //pseudo destructor
=C2=A0 =C2=A0 friend void move(pod*,<= /span> pod= *); //pseudo copy constructor, if not= find library use memcopy
};

t= emplate<= ;typename<= /span> P>
class Warper
{
=C2=A0 =C2=A0 static_assert(std::= is_pod<= P>(), "Type need to be POD"= );<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = P p;
public:
=C2=A0 =C2=A0 Warper() : p{} { init(&p); }
=C2=A0 =C2=A0 ~Warper() { destroy= (&p); }
};
template&= lt;typename> clas= s <= span style=3D"color: #606;" class=3D"styled-by-prettify">Warper_vector;
template<typename P>
class Warper_movable
{
= =C2=A0 =C2=A0 static_assert(st= d::= is_pod<P>(), "Type need to be POD");
=C2=A0 =C2=A0 friend class Warper_vector<P>;
=C2=A0 =C2=A0 bool empty;
=C2= =A0 =C2=A0 P p;
<= /span>public:
=C2=A0 =C2=A0 Warper_movable() : empty{false}, p{} { init(&p); }
=C2=A0 =C2=A0 Warper_movable(Warper_movable&& r) = : empty{false}, p{} { m= ove(&<= /span>r.p, &p); r= .empty =3D true; }
=C2=A0 =C2=A0 ~Warper_movable() {= if (!empty) destroy(&p); }
};
template<typename P>
clas= s <= span style=3D"color: #606;" class=3D"styled-by-prettify">Warper_vector
{
=C2=A0 =C2=A0 static_assert= (std::is_pod<P>(), "Type need to be POD");
=C2=A0 =C2=A0 std::vector<P= > v;
public:
=C2=A0 =C2=A0 Warper_vector() : v(10) { for (auto& = p := v) init(&p); }=C2=A0 =C2=A0 ~War= per_vector= () = { for (auto& p : v) destroy(&p); }

=C2=A0 =C2=A0 void push_back(Warper_movable<P>&a= mp;& r= )
=C2=A0 =C2=A0 <= /span>{
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 v.push= _back(r.p); //no destructors or constructors calls
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 r.empty <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D true; //we can now optimalzie out `Warper_movable` call to `dest= roy`.
= =C2=A0 =C2=A0 }
<= /span>};

int main()
{
=C2=A0 =C2=A0 Warper_vector<pod> vec;
=C2=A0 =C2=A0 for (i= nt i =3D 0; i < 10; ++i)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Warper_movable<pod> obj;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vec= .push_back(std::move(obj));
=C2=A0 =C2=A0 }
} //`init` and `destroy`= is call 20 times





--
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/42c08c4f-dae2-4705-922b-a1ddf8ca7839= %40isocpp.org.
------=_Part_1047_829198281.1460141502508-- ------=_Part_1046_1148487956.1460141502506-- .