220 5768 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Making std::vector> not be copy constructible, among other things Date: Fri, 23 Aug 2013 17:55:16 -0700 (PDT) Lines: 124 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_366_30059536.1377305716697" X-Trace: ger.gmane.org 1377305715 19162 80.91.229.3 (24 Aug 2013 00:55:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Aug 2013 00:55:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMKHJ4B6MARB5MI4CIAKGQEWMD6LLI@isocpp.org Sat Aug 24 02:55:19 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VD28M-0004XI-O9 for gclcip-std-proposals@m.gmane.org; Sat, 24 Aug 2013 02:55:19 +0200 Original-Received: by mail-gh0-f199.google.com with SMTP id g14sf1090965ghb.6 for ; Fri, 23 Aug 2013 17:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=allwqf/jdx/yWFdux/wvpFjF8Q+ub7U0WQhyWKLqJjI=; b=qkUKmTr2b4YnKZbYE4cgaEt+nJbbQsT5opmJDNdSP9e1ri4Twa+OgAyzY1FlsJvEH0 6lNielBkPeRGLCABzM66TqzepgxP2uedYjS2ywQexZUM0yy7P+gSVuGO5LA5wYbg2dZi T7Pb36BFye9a+zdqMmuHsHWsjz8+4O0DZEWkKAcvT5vAzds9BO1bDBCqAxZdm2fSRpIW jkSGxoCwOcEbg2saINfhuXla2bvrdvT5KLjsyGi6NaX//ZirhpLTXKcVbyk5AmBSZztt NSY5EZUXFMLlqNgYYUogpV/oC1cmGYHxpxrIqZ4Idh9/yXjDfsjUTpsR7gzCS41Z89Ez EW3g== X-Received: by 10.236.54.68 with SMTP id h44mr931603yhc.21.1377305717731; Fri, 23 Aug 2013 17:55:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.1.12 with SMTP id 12ls1780717qei.92.gmail; Fri, 23 Aug 2013 17:55:17 -0700 (PDT) X-Received: by 10.49.6.40 with SMTP id x8mr106857qex.5.1377305717160; Fri, 23 Aug 2013 17:55:17 -0700 (PDT) In-Reply-To: X-Original-Sender: lrdxgm@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:5768 Archived-At: ------=_Part_366_30059536.1377305716697 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Google's editor seems to eat my previous answer, if it didn't and was just= =20 delayed, then sorry for the double post) 2013. augusztus 23., p=C3=A9ntek 16:08:51 UTC+2 id=C5=91pontban R. Martinho= Fernandes=20 a k=C3=B6vetkez=C5=91t =C3=ADrta: > > First of all, let's make sure we are all aware of the fact that an=20 > expression that would normally be ill-formed may still count as=20 > "well-formed" for some purposes:=20 > http://stackoverflow.com/q/14815998/46642=20 > As one of the comments pointed out, std::is_constructible checks if there= =20 is a constructor, not if there is a well-formed constructor. The=20 constructor in question is still ill-formed everywhere. > Now, as far as I can see, the standard makes=20 > std::vector> have a copy constructor, even=20 > though it makes any program that instantiates it ill-formed as a=20 > consequence of its defined semantics. Please correct me if my reading=20 > of the standard here is wrong and makes all of this moot.=20 > I think that's not true, although I agree it is not obvious. Check 23.2.1 [container.requirements.general], table 96, there is a row for= =20 expressions with STL container copy constructors: X(a) Requires:T is CopyInsertable into X (see below). post: a =3D=3D X(a). CopyInsertable is: in addition to T being MoveInsertable into X, the following expression is= =20 well-formed: allocator_traits::construct(m, p, v) and its evaluation=20 causes the following postcondition to hold: The value of v is unchanged and= =20 is equivalent to *p. For the default allocator (what calls placement new in construct), it is=20 obvious that this is not true with unique_ptr. It's not that obvious, but= =20 you cannot write a custom allocator what can construct a unique_ptr with=20 the postcondition being valid too. Thus, the postcondition for X(a) is void, thus it is ill-formed in case of= =20 vector>, and for all containers with unique_ptr. Regards, Robert --=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 http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_366_30059536.1377305716697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Google's editor seems to eat my previous answer, if it di= dn't and was just delayed, then sorry for the double post)

2013. aug= usztus 23., p=C3=A9ntek 16:08:51 UTC+2 id=C5=91pontban R. Martinho Fernande= s a k=C3=B6vetkez=C5=91t =C3=ADrta:
First of all, let's make sure we are all aware of the fact that an
expression that would normally be ill-formed may still count as
"well-formed" for some purposes:
http://stackoverflow.com/q/14815998/46642
As one of the comments pointed out, std::is_construct= ible checks if there is a constructor, not if there is a well-formed constr= uctor. The constructor in question is still ill-formed everywhere.

<= /div>

Now, as far as I can see, the standard makes
std::vector<std::unique_ptr<void>> have a copy constru= ctor, even
though it makes any program that instantiates it ill-formed as a
consequence of its defined semantics. Please correct me if my reading
of the standard here is wrong and makes all of this moot.

I think that's not true, although I agree it is n= ot obvious.

Check 23.2.1 [container.requirements.general], table 96,= there is a row for expressions with STL container copy constructors:
X(a) Requires:T is CopyInsertable into X (s= ee below). post: a =3D=3D X(a).
CopyInsertable is:
in addition to T being MoveInsertable into X, the f= ollowing expression is well-formed: allocator_traits<A>::construct(m, p, v) and its e= valuation causes the following postcondition to hold: The value of v is unc= hanged and is equivalent to *p.
For the default allocator (what ca= lls placement new in construct), it is obvious that this is not true with u= nique_ptr. It's not that obvious, but you cannot write a custom allocator w= hat can construct a unique_ptr with the postcondition being valid too.
<= br>Thus, the postcondition for X(a) is void, thus it is ill-formed in case = of vector<unique_ptr<int>>, and for all containers with unique_= ptr.

Regards, Robert

--
 
---
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-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/<= /a>.
------=_Part_366_30059536.1377305716697-- .