220 25065 article Path: news.gmane.org!not-for-mail From: Dale Weiler Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: new auto Date: Tue, 8 Mar 2016 10:34:05 -0800 (PST) Lines: 521 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_248_1811077598.1457462045647" X-Trace: ger.gmane.org 1457462055 17272 80.91.229.3 (8 Mar 2016 18:34:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 18:34:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDY6ZG4YRMNRBHVW7S3AKGQEZEHIAQI@isocpp.org Tue Mar 08 19:34:11 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f200.google.com ([209.85.160.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1adMSO-0005eH-J3 for gclcip-std-proposals@m.gmane.org; Tue, 08 Mar 2016 19:34:08 +0100 Original-Received: by mail-yk0-f200.google.com with SMTP id w83sf28804925ykf.0 for ; Tue, 08 Mar 2016 10:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=EmiGJsqGrjR4FrD5RY6OSN01F3noljSHm9dCYFHMGQ4=; b=q6GLJoPs7NQZ+bG/CejuTrzrl3BDnzlqHVbt5eQBmPbHaaPyUsFNoB/9XCf0raPvE0 3PuJfsw4Q2A8G2dX3QTTtOCGPkB2Q7eQ+2xYUPhWv1Pf4zTVI2anUE0vzBEqF/uh37Oi XmwY2XlVt+zYzbjKKA8L2oedFzmIG0UQFZV0IPX7UXysjt8kVLDQU4+fY9mkT7TenFil On8xOg1pmp8bMjBEAXI173jvMEW1T+vsP909Ym2EWYAA8WO37eSwOk8rZLtvljVd6ftO LPzIpIgb/JOahXposclxlDcrB6Nl0MQSElWR1NWvhUt+7+iJhyEVqMchzB2w9pBo0Snc 1VUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=EmiGJsqGrjR4FrD5RY6OSN01F3noljSHm9dCYFHMGQ4=; b=RS74hXmnvFF9ImEMFSkmDqniqWlHFZdmiLrRH8zQmhK2nUwAQiMOjBNQeh99fyfDWr NvnKxMnmDZ4uWTOdqZG7kfnVnGX9M3lvo1GxBpXpaYbjupq6CwevJQGwwHnBBUw3Vx6B +w/UTjLWjAaDnpdyYBi3RbUxjcLkPdriZmrMdkNY492JU3HgdeNig6VoVKTLSgsdcVPx 471nO4hed9hRhFJPezap5ebYLwU9HfEQBRYFIQuy6hKYBFrG8ogWo9ImwUMr+xlxF66c PiIyQVzujrhF8QnFD3MWbpvOEjIFeLM9Qivylif6V5jZs1Nbxvt/uN1GMV+Rwl8IxB63 nKBA== 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:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe; bh=EmiGJsqGrjR4FrD5RY6OSN01F3noljSHm9dCYFHMGQ4=; b=FumaoXcO2HRtpUvcB11sWHxBk7dNPFQUjAiUBLtX6Om/nBiLx2pfjdZrNMet6P5Mfm PJ23ajnNn4K4y0vAosunjVs6TiEU8X6zaYDtC5Ctf7TljWCOyjiQr9qRIbcaxa6UNVdx z7me7T7GO9z+0CbtGGbRfFxAg3YpT8jNpCo/0+jALqdvEoLnpTLSnxgUSXNwuzfBxwnK 8GetTiTg3Z6E6Vl8m6zoXw81N9bHURF2owXnkjqemnVtDy+MB3Kr9Y3yHpkxn20MR1Mf eq42CGOCwQ+LvgYLcHL5cwTi7bC+5+BJ4gwauvBuIImn2K0r4yiZQVVAWmprFQGz9Q9g vgVw== X-Gm-Message-State: AD7BkJIW63B+LvnQNHCig5B4r7Ak960j5Q5aTr2PNf3F8MBFLAsIMjtJZTAxPql3tihWTg== X-Received: by 10.13.236.84 with SMTP id v81mr674822ywe.2.1457462047787; Tue, 08 Mar 2016 10:34:07 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.142.7 with SMTP id rs7ls316790igb.14.gmail; Tue, 08 Mar 2016 10:34:06 -0800 (PST) X-Received: by 10.50.73.234 with SMTP id o10mr374065igv.10.1457462046494; Tue, 08 Mar 2016 10:34:06 -0800 (PST) X-Original-Sender: weilercdale@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: Original-Sender: std-proposals@isocpp.org List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:25065 Archived-At: ------=_Part_248_1811077598.1457462045647 Content-Type: multipart/alternative; boundary="----=_Part_249_237990868.1457462045648" ------=_Part_249_237990868.1457462045648 Content-Type: text/plain; charset=UTF-8 Exibit class A { A(); T *a; }; Need to know type of *a* here to call new correctly: A::A() : a(new T) { } Imagine the class member type changes but implementing code stays the same, thus it allocates an incorrect amount of memory for the object and calls the wrong constructor. How do we solve this? A::A() : a (new typename remove_reference::type) { } Not that pretty but does handle this case. What's interesting is in these contexts the compiler knows the type from the binding side: T *a = new T; T *b(new T); We can see this is true with container types too: unique_ptr a = make_unique(...); unique_ptr b(new T(...)); shared_ptr c = make_shared(...); shared_ptr d(new T(...)); Lets review our original example now with *new auto:* A::A() : a(new auto) { } Changes of the class member type does not affect implementing code, since *auto* knows the type Consistent with other forms of initialization as well: T *a = new auto; T *a(new auto); Ambigious *new auto(expr)* already exists in C++, it's defined such that new allocates storage for type of *expr* and constructs with value of *expr*. We argue this behavior is inconsistent with the rest of the language as*auto* is treated as a non-type and as a function-style cast in this example. With explicit initialization this would be preferred behavior of the syntax, which shouldn't break anything either: T *a = new auto(...); T *b(new auto(...)); Assuming existing C++ code uses *new auto(expr)*, the binding side of the expression must have same type as the new expression, otherwise a compile error results. The only time this is not the case is when a *reinterpret_cast* is used on the result of the new expression which is undefined unless the pointer types are compatible. When the binding side is of the same type as the new expression the result is consistent with this proposal and does not break existing C++ code that uses *new auto(expr)*. Visibility What we obtain is improved visibility for containment and consistency with respect to *auto* and other language syntax. For example *make_unique* and *make_shared* can be made much simpler and better: template unique_ptr make_unique(A&&... a) { // Note we don't use new T here since that prevents visibility return { new auto(forward(a)...) }; } template shared_ptr make_shared(A&&... a) { // Ditto no use of new T here either return { new auto(forward(a)...) }; } Now *make_unique* and *make_shared* can access private constructors, since `auto` avoids the visibility problem in this construct: class A { A() { ... } public: void x() { auto x = make_unique(); // Works! ... } }; However outside class scope: auto x = make_unique(); // Does not work since private (as expected) Yes it works for arrays too: int *x = new auto[10]; // 10 integers (uninitialized) int *y = new auto[10](100); // 10 integers (initialized to 100 -- 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/d98f26dc-e801-4e74-bcbc-7e085986de63%40isocpp.org. ------=_Part_249_237990868.1457462045648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Exibit


class=
 A {
=C2=A0 A();
=C2=A0 T *a;
};


Need to know type of a here to call new correctly:

=C2=A0A::A() : a(=
new T) { }

Imagine the class member type changes but implementing code stays the
same, thus it allocates an incorrect amount of memory for the object and
calls the wrong constructor. How do we solve this? 
A::A() =
: a (new typename remove_reference<decltype(A::a)&=
gt;::type<=
/span>) { }


Not that pretty but does handle this case. What's interesting is in the=
se
contexts the compiler knows the type from the binding side:
T *a =3D new T=
;
T *b(new T);


We can see this is true with container types too:

unique_ptr<<=
span style=3D"color: #000;" class=3D"styled-by-prettify">T> a =3D make_unique<T>(...);
unique_ptr<T> b=
(new T(...));
shared_ptr<T> c =3D make_shared<T>(.=
...); 
s=
hared_ptr&=
lt;T> d(new T(...));

Lets review our original example now with new auto:

A::A() : a(new auto) { }

Changes of the class member type does =
not affect implementing code,
since auto knows the type

Consistent with other forms of initialization as well:
T *a =3D new auto;
T *a(new auto)=
;


Ambigious

new auto(expr) already exists in C++, it's defined such that new=
 allocates
storage for type of expr and constructs with value of =
expr.

We argue this behavior is inconsistent with the rest of the language as
auto is treated as a non-type and as a function-style cast in this e=
xample.

With explicit initialization this would be preferred behavior of the syntax=
,
which shouldn't break anything either:

T *a =3D new auto(...);T *b(new auto(...));

Assuming existing =
C++ code uses new auto(expr), the binding
side of the expression =
must have same type as the new expression,
otherwise a compile error res=
ults. The only time this is not the case
is when a reinterpret_cast is used on the result of the new expression which
is undefined unless=
 the pointer types are compatible. When the binding side
is of the same =
type as the new expression the result is consistent with
this proposal a=
nd does not break existing C++ code that uses new auto(expr).

Visibility

What we obtain is improved visib=
ility for containment and consistency
with respect to auto and other language syntax.

For example make_unique and make_shared can be made much simp=
ler and=20
better:

template <typename T, typename A...>
unique_ptr<T>=
; make_uni=
que(A&&... a) {
=C2=A0 // Note we don't use new T here since that prevent=
s visibility
=C2=A0 return =
{ new auto(forward<A&g=
t;(a)...) };
}
template <typename =
T,<=
span style=3D"color: #000;" class=3D"styled-by-prettify"> typename A...>
shared_ptr<T> make_shared(A&&... a)<=
/span> {
=C2=A0 // Ditto no use of new T he=
re either<=
br>=C2=A0 =
return { new auto(forward<A>=
;(a=
)...) };
} 


Now make_unique and make_shared can access private constructo=
rs,
since `auto` avoids the visibility problem in this construct:
class A {
=C2=A0 A() { .=
... =
}
public:
=C2=A0 void x() =
{
=C2=
=A0 =C2=A0 auto x =3D make_unique=
<A>(); // Works!
=C2=A0 =C2=A0 ...
=C2=A0 }
};

However outside class scope:
auto x =3D=
 make_unique<A>(); // Does not work since pr=
ivate (as expected)

Yes it works for arrays too:

int *x =3D new a=
uto[10]; // 10 integers (uninitialized)
int *y =3D =
new auto[10](100); // 10 integers (initialized to 100

--
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/d98f26dc-e801-4e74-bcbc-7e085986de63= %40isocpp.org.
------=_Part_249_237990868.1457462045648-- ------=_Part_248_1811077598.1457462045647-- .