220 24323 <8CB3C2A7-398E-4E83-9A9F-4596337F5F4A@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: variant construction/assignment from braced value Date: Fri, 12 Feb 2016 01:30:51 +0800 Lines: 211 Approved: news@gmane.org Message-ID: <8CB3C2A7-398E-4E83-9A9F-4596337F5F4A@gmail.com> References: <9A41B088-08C0-4222-8558-FA734F61BDE5@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F" X-Trace: ger.gmane.org 1455211882 1813 80.91.229.3 (11 Feb 2016 17:31:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Feb 2016 17:31:22 +0000 (UTC) Cc: Axel Naumann , =?utf-8?Q?Agust=C3=ADn_K-ballo_Berg=C3=A9?= To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCW25A7E3QCRBXUK6O2QKGQEZLVE66Y@isocpp.org Thu Feb 11 18:31:13 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 1aTv5E-0002zg-OD for gclcip-std-proposals@m.gmane.org; Thu, 11 Feb 2016 18:31:13 +0100 Original-Received: by mail-yw0-f199.google.com with SMTP id g127sf56773208ywf.0 for ; Thu, 11 Feb 2016 09:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references: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=E+0LybT6d303soZEEGqPyWziOmDckLHXf4L4Kj64si4=; b=q7hGxCVBIN4HZ93Xp99G55Su1zMXzC1FBdtsx0VIsJYA1HQv1kX5XlnClFTNO16Fr9 o9HeUrEyEQvHqAl3051CMkvwP9uaShVabyUF7X1VDhFxVkOIUhD/BFIDAjlKNrhNfukp 6QMtej+yW4xJyKSBOFGZGJUI9uHXUsXY0cpy9ane7UjKOHQUDhehXnIp2lX+6Bsw1WPB Suibf1JKXlUpuyEHiy+s3blaid78yMzO/IXzZ1HAoFvh2dMS7lqpT0He5aYOPtIHdkLt 7WFZQMPzG2+UxblHiLTYd95sCB6UsLRqYI003WTbgxxepNTKY8hRY1ucfrWc+C7FXjWq 6QXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references: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=E+0LybT6d303soZEEGqPyWziOmDckLHXf4L4Kj64si4=; b=gcRr0WgJmiWgVgobTorkK1wlN2AIzLboOXoE/LVjpTlTVYnIQw00Twvw1jvtOMo1A0 svCm26WyZ1XlCJ62b4GvMuh75oIHwR1Bz+RP8pSX5bF3mEQw4f6Sq0eoqcpXLRmbKyZo hko0g5+2gqdQCGfwV+fKjj4j77PK63fYj1vbM8DDWT+NdZDi+zj9pyJFN73OJuHp6DXH J9sc+2TzvNmAcYVzrhhtEUWKujYswCmvoLwrqlh5fOJpyqn+qfCegRPG2U4sXHPG4FW0 s3x4E73wiBNn3wULdIrEWVK5eUgG3nTA1Wm0r4H4LADhFqsLx6A2uswESHGbhvnJYLW4 +OKw== X-Gm-Message-State: AG10YOQbOCXFDY4c96Iv3Rc4MIsbXpGUkSFQr8ESgPDBqpTwrEA/tkeyz+LVZbnbBKGgVQ== X-Received: by 10.13.242.134 with SMTP id b128mr42458572ywf.28.1455211871594; Thu, 11 Feb 2016 09:31:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.7.14 with SMTP id 14ls549583ioh.102.gmail; Thu, 11 Feb 2016 09:31:10 -0800 (PST) X-Received: by 10.66.146.102 with SMTP id tb6mr467298pab.109.1455211870071; Thu, 11 Feb 2016 09:31:10 -0800 (PST) Original-Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com. [2607:f8b0:400e:c00::233]) by mx.google.com with ESMTPS id ks7si13725105pab.129.2016.02.11.09.31.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2016 09:31:10 -0800 (PST) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c00::233 as permitted sender) client-ip=2607:f8b0:400e:c00::233; Original-Received: by mail-pf0-x233.google.com with SMTP id c10so33099718pfc.2 for ; Thu, 11 Feb 2016 09:31:10 -0800 (PST) X-Received: by 10.98.34.209 with SMTP id p78mr8876757pfj.154.1455211869866; Thu, 11 Feb 2016 09:31:09 -0800 (PST) Original-Received: from [172.20.10.2] ([121.54.54.146]) by smtp.gmail.com with ESMTPSA id x13sm13663741pfa.72.2016.02.11.09.31.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 09:31:09 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3096.5) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c00::233 as permitted sender) smtp.mailfrom=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:24323 Archived-At: --Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2016=E2=80=9302=E2=80=9311, at 8:44 PM, Agust=C3=ADn K-ballo Berg=C3= =A9 wrote: >=20 > Speaking from my Eggs.Variant experience, the reason I designed that cons= tructor as doing overload resolution was to approximate what a true set of = constructors would do (imperfect), while leaving the door open to a proper = implementation in terms of inherited constructors (supports braced init lis= ts and stuff). >=20 > The reason I never changed that was that I implemented the proper solutio= n, or rather a simplified version that gets all the corner cases wrong (htt= ps://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2c332d28= 43cb0), and the implementation costs in terms of compilation-time and binar= y size were just too big. The inheriting constructors are causing quadratic bloat because each Nth in= heritance level needs to instantiate the N inherited constructors. (Inherit= ing constructors are more than just a name lookup hack.) That=E2=80=99s tough=E2=80=A6 perhaps limiting the depth to log(N) would he= lp, using an inheritance tree. How many types did it take to cause trouble? > The set of inherited constructor implementation does not really provide t= hat many different implementation challenges for the proposed `variant`. Si= nce it supports reference types as members, the number of constructors you'= d need for each type is the same as those needed for determining overload r= esolution (4 for object, 2 for non-const reference, 1 for const reference, = 0 for void). Hmm, & and const&& copy constructor overloads seem like a waste. They do pr= ovide parity with the template solution, but most of the standard library i= gnores those cases. > The only difference is that for a duplicated (decayed) type you'd need to= delete the corresponding constructors, given that inheritance would otherw= ise hide the rest and just pick the last rather than causing an ambiguity l= ike overloading resolution does. Right. Putting all the implementation at the leaves of a tree could help th= at, too. That=E2=80=99s easier said than done, of course. Here=E2=80=99s a technique= that could help. It=E2=80=99s at the fringes of conformance, but Clang and= GCC both let it pass. More fleshed-out demo at http://melpon.org/wandbox/p= ermlink/5ZOUb4tZ7vmOhvKL . struct b { // Base class wants to initialize derived state. constexpr b( int i ); }; struct d : b { using b::b; int s =3D s; // Self-assignment is free for a trivially-copyable type. }; constexpr b::b( int i ) { static_cast< d * >( this )->s =3D i; } // Start the derived lifetime = early. constexpr d q( 5 ); static_assert ( q.s =3D=3D 5, "" ); This technique could be used to initialize the trivially-copyable alternati= ves. Non-constexpr constructors could use placement new in the base leaf fo= llowed by a no-op union mem-initializer in the storage class. > In short, a proper set of non-template constructors is the way it was int= ended from the beginning, and it has been proved to be viable. Now if you c= ould get implementors to do something about the cost of those recursive ins= tantiation, then that would be great. Richard Smith is currently working to improve the model for inheriting cons= tructors, but I don=E2=80=99t suppose that will improve the bloat issue. It= =E2=80=99s too bad that implementation decided to link all the inline funct= ions. > On 2016=E2=80=9302=E2=80=9311, at 9:49 PM, Anthony Williams wrote: >=20 > That all depends on your implementation technique. My implementation at > https://bitbucket.org/anthonyw/variant handles that just fine: Well, that=E2=80=99s by deducing an initializer list and then passing its c= ontents. That doesn=E2=80=99t cover aggregates; it=E2=80=99s a separate dis= cussion. --=20 ---=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. Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos= als/. --Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2016=E2=80=9302= =E2=80=9311, at 8:44 PM, Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@hotmail.com> wrote:<= /div>
Speaking from my Eggs.Variant experience, the reason I designed that cons= tructor as doing overload resolution was to approximate what a true set of = constructors would do (imperfect), while leaving the door open to a proper = implementation in terms of inherited constructors (supports braced init lis= ts and stuff).

The reason I never changed that= was that I implemented the proper solution, or rather a simplified version= that gets all the corner cases wrong (http= s://github.com/eggs-cpp/variant/commit/0372c94d99f3442e2fbe026d18b2c332d284= 3cb0), and the implementation costs in terms of compilation-time and bi= nary size were just too big.
The inheriting constructors are causing quadratic b= loat because each Nth inheritance level needs to instantiate the N inherite= d constructors. (Inheriting constructors are more than just a name lookup h= ack.)

That=E2=80=99s tough=E2=80=A6 per= haps limiting the depth to log(N) would help, using an inheritance tree. Ho= w many types did it take to cause trouble?

The set of inherit= ed constructor implementation does not really provide that many different i= mplementation challenges for the proposed `variant`. Since it supports refe= rence types as members, the number of constructors you'd need for each type= is the same as those needed for determining overload resolution (4 for obj= ect, 2 for non-const reference, 1 for const reference, 0 for void).

Hmm, & and const&a= mp;& copy constructor overloads seem like a waste. They do provi= de parity with the template solution, but most of the standard library igno= res those cases.

<= div class=3D"">
The only difference is that for a duplicated= (decayed) type you'd need to delete the corresponding constructors, given = that inheritance would otherwise hide the rest and just pick the last rathe= r than causing an ambiguity like overloading resolution does.

Right. Putting all= the implementation at the leaves of a tree could help that, too.

That=E2=80=99s easier said than done, of course.= Here=E2=80=99s a technique that could help. It=E2=80=99s at the fringes of= conformance, but Clang and GCC both let it pass. More fleshed-out demo at&= nbsp;http://melpon.org/wandbox/permlink/5ZOUb4tZ7vmOhvKL .
<= div>
struct b { = // Base class wants to initialize derived state.
   = ; constexpr b( int i );
};

struc= t d : b {
    using b::b;

    int s =3D s; // Self-assignment is free for a trivially= -copyable type.
};
constexpr b::b( int i )
    { static_cast< d * >( this )->s =3D i; } /= / Start the derived lifetime early.

constexpr = d q( 5 );
static_assert = ( q.s =3D=3D 5, ""&= nbsp;);

This technique could be used to initialize the trivial= ly-copyable alternatives. Non-constexpr constructors could use placement ne= w in the base leaf followed by a no-op union mem-initializer in the storage= class.

In short, a proper set of non-template constructors i= s the way it was intended from the beginning, and it has been proved to be = viable. Now if you could get implementors to do something about the cost of= those recursive instantiation, then that would be great.

Richard Smith is= currently working to improve the model for inheriting constructors, but I = don=E2=80=99t suppose that will improve the bloat issue. It=E2=80=99s too b= ad that implementation decided to link all the inline functions.


On 2016=E2= =80=9302=E2=80=9311, at 9:49 PM, Anthony Williams <anthony.ajw@gmail.com> wrote:
That all depends on your imp= lementation technique. My implementation at
https://bitbucket.org/a= nthonyw/variant handles that just fine:

Well, that=E2=80=99s by deducin= g an initializer list and then passing its contents. That doesn=E2=80=99t c= over aggregates; it=E2=80=99s a separate discussion.
<= br class=3D"">

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals= /.
--Apple-Mail=_CC029BC1-9EC2-41E7-87AC-7659D065A59F-- .