220 20531 <87343e65-eecd-4b96-86b7-a883aa7f9d1d@isocpp.org> article Path: news.gmane.org!not-for-mail From: Tomasz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Draft D0065: Movable initializer lists, rev. 2 Date: Sun, 20 Sep 2015 12:02:54 -0700 (PDT) Lines: 150 Approved: news@gmane.org Message-ID: <87343e65-eecd-4b96-86b7-a883aa7f9d1d@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_237_781490530.1442775774412" X-Trace: ger.gmane.org 1442775781 3640 80.91.229.3 (20 Sep 2015 19:03:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Sep 2015 19:03:01 +0000 (UTC) Cc: rcc.dark@gmail.com, bballo@mozilla.com, jlakos@bloomberg.net To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNPVXXG6IGBBX4F7SXQKGQE6LIIH3I@isocpp.org Sun Sep 20 21:02:59 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zdjt3-0000G1-TD for gclcip-std-proposals@m.gmane.org; Sun, 20 Sep 2015 21:02:58 +0200 Original-Received: by qkey1 with SMTP id y1sf152421744qke.0 for ; Sun, 20 Sep 2015 12:02:56 -0700 (PDT) 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:content-type: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=twS/oO7NR1KfqtDRCQY382Ws/XENwLAFbk5kGvntvpw=; b=lKmLFCj69WPVHcFRqmkXYsQC5W5coYVRQIAKbrTMfYVJQPfn+UBvS2/HWAZCcSl1E7 UIDLWdLUfGbJ4irFKRU/GXcKbKS41pvbTRFfvHCuTsE90sfeqnNgw37zlYO0XBKs5wKD Ik6o8UtX6KUtwfiCP8s3ZAIWAD1dXH+swA/oyNTvM4f1hFuZ6+iBhTaF/yGcxmbIIwDU ADIYA/Wq7/8/SfBZpfaUTIsBp8+4ZHAB90sy/GZ8UI5Sw6gQYppgO3YC+kK4qzhce8pX x2x7wBRujgORmZiic/fgJNTRVzTuWM+Aw4bQ/o+dpYaxf2zXM7ROraTSh6yeDfBjXbo0 6plA== 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:content-type: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=twS/oO7NR1KfqtDRCQY382Ws/XENwLAFbk5kGvntvpw=; b=l8EaFztYy7/uLdqlmKsVnLTAt/qZtyeWrcxqSk7dXXRTLq0XuABxxWISwXR0zI+Nat hNbx8rLICMSP20oC6DiUAOEg12iPr5X3HffX3GvUiGU8KR5OZ1r9Csk24LHEBrrFELv0 xfWuCbH/hqi6XAB7yp1Muv0XVexaiaT6Q0sjLyybxFIjWJ6nneMcGgkftoh3mhEXQSrh ldJJA2XdBQlHCLnzsm6Ep3G2TvYnh9wCdx8ZmYEAPCLuTWE9EXa5uas7P4lxD2oKierN hoA1fgNjwfStVY7d7ZfRWTX8Y8g/mbeIe5fUtSq9y8mjRa9cTbdPdKKMDlUjbKCoz8Uu FbNg== X-Gm-Message-State: ALoCoQnga29KS8sABpw/cFFrHEV4RSSW0f4cKosDM35m1RP3cndUzIVCwJK7jSZulqysoOVWE7yg X-Received: by 10.140.239.142 with SMTP id k136mr13794966qhc.7.1442775776639; Sun, 20 Sep 2015 12:02:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.138.231 with SMTP id c100ls958451ioj.109.gmail; Sun, 20 Sep 2015 12:02:55 -0700 (PDT) X-Received: by 10.50.79.193 with SMTP id l1mr74049igx.2.1442775775378; Sun, 20 Sep 2015 12:02:55 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@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:20531 Archived-At: ------=_Part_237_781490530.1442775774412 Content-Type: multipart/alternative; boundary="----=_Part_238_235391780.1442775774412" ------=_Part_238_235391780.1442775774412 Content-Type: text/plain; charset=UTF-8 I have a question regarding the rationale for keeping own_initializer_list movable. This still may lead to several dangling reference problems, for example most common one is to treat own_initializer_list as normal container and store as class member, for example: //Building a static composite struct Component; typedef std::unique_ptr ComponentPtr; struct Composite { Composite(own_initializer_list&& a_list) : a_list(m_list) {} private: own_initializer_list m_list; }; Composite c{std::make_unique(), std::make_unique()}; //The member m_list is dangling here //Selecting the list of initializers boost::optional> list; if (useImplementation1) list.emplace({std::make_unique()}); else list.emplace({std::make_unique()}); //list is dangling now Both situations are non-trivial to understand and requires knowledge about internal implementation (stack array) and are source of errors in the program. Both of them would be fixed by making the own_initializer_list non-copyable and non-moveable. The cost of the change would be that you will be no longer able to write: auto list = {"ala"s, "ola"s}; //Will requires move constructor to intializer from temporary on left hand side. However the syntax: auto&& list = {"ala"s, "ola"s}; //Will still be valid. The functions will be required to accept own_initializer_list&&, but I do not think that this is a problem; There is a situation, when the non-copyable non-moveable class can still be transfered. One is: own_initializer_list makeComponets() { return {std::make_unique(), std::make_unique()}; } auto && list = makeComponets(); However, I believe in this case the standard will guarantee that list is no longer dangling. In situation as above, the standard requires that own_initializer_list will be constructed on call side, as creation of stack array is part the construction of own_initializer_list, the array will be placed on call side. And the second: auto* p = new own_initializer_list{std::make_unique(), std::make_unique()}; The paper still does not qualify if this is safe. The array may be placed both on stack (dangling), or on the heap with own_initializer_list object. Choosing the second resolution and making own_initializer_list non-moveable will eliminate all dangling reference problems occuring in situation when own_initializer_list is stored by value. Storing it by reference, will provide to dangling reference, as for any other class. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_238_235391780.1442775774412 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a question regarding the rationale for keeping own_= initializer_list<T> movable. This still may lead to several dangling = reference problems, for example most common one is to treat own_initializer= _list<T> as normal container and store as class member, for example:<= br>//Building a static composite
struct Component;
typedef std::uniqu= e_ptr<Component> ComponentPtr;

struct Composite
{
=C2=A0= Composite(own_initializer_list<ComponentPtr>&& a_list) : a_l= ist(m_list) {}
=C2=A0=C2=A0
private:
=C2=A0 own_initializer_list&= lt;ComponentPtr> m_list;
};

Composite c{std::make_unique<Co= ncreteComposite1>(), std::make_unique<ConcreteComposite2>()};
/= /The member m_list is dangling here

//Selecting the list of initiali= zers
boost::optional<own_initializer_list<ComponentPtr>> lis= t;
if (useImplementation1)
=C2=A0 list.emplace({std::make_unique<C= oncreteComposite1>()});
else
=C2=A0 list.emplace({std::make_unique= <ConcreteComposite2>()});
//list is dangling now

Both situa= tions are non-trivial to understand and requires knowledge about internal i= mplementation (stack array) and are source of errors in the program. Both o= f them would be fixed by making the own_initializer_list non-copyable and n= on-moveable. The cost of the change would be that you will be no longer abl= e to write:
auto list =3D {"ala"s, "ola"s};
//Wil= l requires move constructor to intializer from temporary on left hand side.= However the syntax:
auto&& list =3D {"ala"s, "ol= a"s};
//Will still be valid.
The functions will be required to a= ccept own_initializer_list<ComponentPtr>&&, but I do not thin= k that this is a problem;

There is a situation, when the non-copyabl= e non-moveable class can still be transfered. One is:
own_initializer_li= st<ComponentPtr> makeComponets()
{
=C2=A0 return {std::make_un= ique<ConcreteComposite1>(), std::make_unique<ConcreteComposite2>= ;()};
}

auto && list =3D makeComponets();
However, I b= elieve in this case the standard will guarantee that list is no longer dang= ling. In situation as above, the standard requires that own_initializer_lis= t<ComponentPtr> will be constructed on call side, as creation of stac= k array is part the construction of own_initializer_list<ComponentPtr>= ;, the array will be placed on call side.

And the second:
auto* p= =3D new own_initializer_list<ComponentPtr>{std::make_unique<Concr= eteComposite1>(), std::make_unique<ConcreteComposite2>()};
The = paper still does not qualify if this is safe. The array may be placed both = on stack (dangling), or on the heap with own_initializer_list<T> obje= ct. Choosing the second resolution and making own_initializer_list non-move= able will eliminate all dangling reference problems occuring in situation w= hen own_initializer_list<T> is stored by value. Storing it by referen= ce, will provide to dangling reference, as for any other class.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_238_235391780.1442775774412-- ------=_Part_237_781490530.1442775774412-- .