Topic: Change return type of operator 'new []' into some
Author: Alexander Marinov <sasho648@mail.bg>
Date: Fri, 20 Mar 2015 12:18:08 -0700 (PDT)
Raw View
------=_Part_959_388972802.1426879088595
Content-Type: multipart/alternative;
boundary="----=_Part_960_525661746.1426879088595"
------=_Part_960_525661746.1426879088595
Content-Type: text/plain; charset=UTF-8
The problem is that operators 'new' and 'new []' have the same return-value
type which is not good. I think it's better to know if a pointer will point
to a single object or to multiple ones just by looking into the code.
Of-course seeing the instance of either 'new []' or 'new' is
self-explanatory but then comes the variable where it is stored. I suggest
instead of 'T *', 'new []' to return 'T (*)[]' which is named pointer to
array of unknown bound. This way we can more clearly distinguish variable
proposes. Some examples:
struct S
{
int *mvar;
int (*pKey)[];
double (*table)[];
}
The above shows variables intend way better then declaring all of them the
same.
Note that this type already exists with few limitations which were recently
lifted (pointer or reference to one was forbidden in function parameter
types).
If we introduce the return type of 'new []' to be 'T (*)[]' instead of 'T
*' we introduce another level of clarity which is always a good thing. Some
examples:
auto p_int = new int; //'p_int' is of type 'int *'
extern int arr_size; //some 'lvalue'
auto p_int_0 = new int[arr_size]; //'p_int_0' is of type 'int (*)[]'
p_int = p_int_0; //error can't convert from 'int (*)[]' to 'int *'
void func(int *), func(int (*)[]);
func(p_int); //here 'void func(int *)' is instanced
func(p_int_0); //here 'void func(int (*)[])' is instanced
Another good addition will be limiting operator 'new []' to only accept
constant-expressions as it's argument and so allocating arrays with fixed
size to invoke the 'new' operator. Examples:
auto p_int_1 = new int[90]; //here 'p_int_1' is of type 'int (*)[90]',
operator 'new' is invoked
auto p_int_2 = new int[arr_size]; //here 'p_int_2' is of type 'int (*)[]',
operator 'new []' is invoked
Tell me what do you think about this suggestion?
--
---
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_960_525661746.1426879088595
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The problem is that operators 'new' and 'new []' have the =
same return-value type which is not good. I think it's better to know if a =
pointer will point to a single object or to multiple ones just by looking i=
nto the code. Of-course seeing the instance of either 'new []' or 'new' is =
self-explanatory but then comes the variable where it is stored. I suggest =
instead of 'T *', 'new []' to return 'T (*)[]' which is named pointer to ar=
ray of unknown bound. This way we can more clearly distinguish variable pro=
poses. Some examples:<br><br><div class=3D"prettyprint" style=3D"border: 1p=
x solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(25=
0, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> S<br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">mvar</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">pKey</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)[];</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">double</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(*</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">table</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)[];</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">}</span></div></code></div><div><br></div><div><br></div><div>=
The above shows variables intend way better then declaring all of them the =
same.</div><div><br></div><div>Note that this type already exists with few =
limitations which were recently lifted (pointer or reference to one was for=
bidden in function parameter types).</div><div><br></div><div>If we introdu=
ce the return type of 'new []' to be 'T (*)[]' instead of 'T *' we introduc=
e another level of clarity which is always a good thing. Some examples:<br>=
<br></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 18=
7, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> p_int </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">new</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//'p_int' is of type 'int *'=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">extern</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> arr_size</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//some 'lvalue'</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> p_int_0 </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">new</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">arr_size</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">//'p_int_0' is of type 'int (*)[]'</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>=
p_int </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p_int_0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//error can't convert from 'int=
(*)[]' to 'int *'</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">*),</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(*)[]);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br><br>func</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">p_int</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">//here 'void fun=
c(int *)' is instanced</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br><br>func</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">p_int_0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">//here 'voi=
d func(int (*)[])' is instanced</span></div></code></div><div><br><br></div=
><div><br></div><div>Another good addition will be limiting operator 'new [=
]' to only accept constant-expressions as it's argument and so allocating a=
rrays with fixed size to invoke the 'new' operator. Examples:<br><br><br></=
div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187=
); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> p_int_1 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">new</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">90</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">//here 'p_int_1' is of type 'int (*)[90]', operat=
or 'new' is invoked</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> p_int_2 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">new</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">arr_size</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//here 'p_int_2' is of type 'int (*)[]', operator 'new []' is i=
nvoked</span></div></code></div><br><div><span style=3D"color: rgb(0, 0, 0)=
; font-family: monospace; background-color: rgb(250, 250, 250);"><br>Tell m=
e what do you think about this suggestion?</span></div><div><br></div><div>=
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_960_525661746.1426879088595--
------=_Part_959_388972802.1426879088595--
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Fri, 20 Mar 2015 22:44:40 +0100
Raw View
What is the purpose of this proposal? It will break existing code and
it is very difficult to find a place where anyone would consider using
new [] (not to mention new) writing new C++ code.
/Peter
On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <sasho648@mail.bg> wrote:
> The problem is that operators 'new' and 'new []' have the same return-value
> type which is not good. I think it's better to know if a pointer will point
> to a single object or to multiple ones just by looking into the code.
> Of-course seeing the instance of either 'new []' or 'new' is
> self-explanatory but then comes the variable where it is stored. I suggest
> instead of 'T *', 'new []' to return 'T (*)[]' which is named pointer to
> array of unknown bound. This way we can more clearly distinguish variable
> proposes. Some examples:
>
> struct S
> {
> int *mvar;
>
> int (*pKey)[];
>
> double (*table)[];
> }
>
>
> The above shows variables intend way better then declaring all of them the
> same.
>
> Note that this type already exists with few limitations which were recently
> lifted (pointer or reference to one was forbidden in function parameter
> types).
>
> If we introduce the return type of 'new []' to be 'T (*)[]' instead of 'T *'
> we introduce another level of clarity which is always a good thing. Some
> examples:
>
> auto p_int = new int; //'p_int' is of type 'int *'
>
>
> extern int arr_size; //some 'lvalue'
>
>
> auto p_int_0 = new int[arr_size]; //'p_int_0' is of type 'int (*)[]'
>
>
> p_int = p_int_0; //error can't convert from 'int (*)[]' to 'int *'
>
>
> void func(int *), func(int (*)[]);
>
>
> func(p_int); //here 'void func(int *)' is instanced
>
>
> func(p_int_0); //here 'void func(int (*)[])' is instanced
>
>
>
> Another good addition will be limiting operator 'new []' to only accept
> constant-expressions as it's argument and so allocating arrays with fixed
> size to invoke the 'new' operator. Examples:
>
>
> auto p_int_1 = new int[90]; //here 'p_int_1' is of type 'int (*)[90]',
> operator 'new' is invoked
>
>
> auto p_int_2 = new int[arr_size]; //here 'p_int_2' is of type 'int (*)[]',
> operator 'new []' is invoked
>
>
> Tell me what do you think about this suggestion?
>
>
> --
>
> ---
> 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/.
--
---
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/.
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 21 Mar 2015 00:53:46 -0700 (PDT)
Raw View
------=_Part_1391_1459619838.1426924426881
Content-Type: multipart/alternative;
boundary="----=_Part_1392_1124917585.1426924426881"
------=_Part_1392_1124917585.1426924426881
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
First it'll add another level of clarification which is always a good thing=
=20
as I said. But another (which I came up recently with) is that it'll make=
=20
redundant the 'delete []' operator. It'll be replaced by a special overload=
=20
of the 'delete ' with parameter of type 'T (*)[]'. This will definitely=20
easy our lives, doesn't it?
Some examples:
auto p_int_0 =3D new int[arr_size];
auto p_int =3D new int;
delete p_int_0; //operator 'delete' special overload for 'T (*)[]' is=20
instanced
delete p_int; //operator 'delete' general is instanced for all other types
This will be possible as 'int []' is incomplete type anyway so a single=20
object with it can't be constructed.
*Sometimes I wonder what drink people have worked on this standard.*
=20
=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 20 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 2=
3:45:33 UTC+2, Peter Koch Larsen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> What is the purpose of this proposal? It will break existing code and=20
> it is very difficult to find a place where anyone would consider using=20
> new [] (not to mention new) writing new C++ code.=20
>
> /Peter=20
>
> On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <sash...@mail.bg=20
> <javascript:>> wrote:=20
> > The problem is that operators 'new' and 'new []' have the same=20
> return-value=20
> > type which is not good. I think it's better to know if a pointer will=
=20
> point=20
> > to a single object or to multiple ones just by looking into the code.=
=20
> > Of-course seeing the instance of either 'new []' or 'new' is=20
> > self-explanatory but then comes the variable where it is stored. I=20
> suggest=20
> > instead of 'T *', 'new []' to return 'T (*)[]' which is named pointer t=
o=20
> > array of unknown bound. This way we can more clearly distinguish=20
> variable=20
> > proposes. Some examples:=20
> >=20
> > struct S=20
> > {=20
> > int *mvar;=20
> >=20
> > int (*pKey)[];=20
> >=20
> > double (*table)[];=20
> > }=20
> >=20
> >=20
> > The above shows variables intend way better then declaring all of them=
=20
> the=20
> > same.=20
> >=20
> > Note that this type already exists with few limitations which were=20
> recently=20
> > lifted (pointer or reference to one was forbidden in function parameter=
=20
> > types).=20
> >=20
> > If we introduce the return type of 'new []' to be 'T (*)[]' instead of=
=20
> 'T *'=20
> > we introduce another level of clarity which is always a good thing. Som=
e=20
> > examples:=20
> >=20
> > auto p_int =3D new int; //'p_int' is of type 'int *'=20
> >=20
> >=20
> > extern int arr_size; //some 'lvalue'=20
> >=20
> >=20
> > auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type 'int (*)[]'=
=20
> >=20
> >=20
> > p_int =3D p_int_0; //error can't convert from 'int (*)[]' to 'int *'=20
> >=20
> >=20
> > void func(int *), func(int (*)[]);=20
> >=20
> >=20
> > func(p_int); //here 'void func(int *)' is instanced=20
> >=20
> >=20
> > func(p_int_0); //here 'void func(int (*)[])' is instanced=20
> >=20
> >=20
> >=20
> > Another good addition will be limiting operator 'new []' to only accept=
=20
> > constant-expressions as it's argument and so allocating arrays with=20
> fixed=20
> > size to invoke the 'new' operator. Examples:=20
> >=20
> >=20
> > auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type 'int (*)[90]'=
,=20
> > operator 'new' is invoked=20
> >=20
> >=20
> > auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of type 'int=20
> (*)[]',=20
> > operator 'new []' is invoked=20
> >=20
> >=20
> > Tell me what do you think about this suggestion?=20
> >=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>
--=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_1392_1124917585.1426924426881
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">First it'll add another level of clarification which is al=
ways a good thing as I said. But another (which I came up recently with) is=
that it'll make redundant the 'delete []' operator. It'll be replaced by a=
special overload of the 'delete ' with parameter of type 'T (*)[]'. This w=
ill definitely easy our lives, doesn't it?<div><br></div><div>Some examples=
:<br><br><span style=3D"font-family: monospace; color: rgb(0, 0, 136); back=
ground-color: rgb(250, 250, 250);"></span></div><div class=3D"prettyprint" =
style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backg=
round-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p_int=
_0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">arr_size</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> p_int </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">new</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">delete</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> p_int_0</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">//operator 'delete' special overload for 'T (*)[]' is insta=
nced</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">dele=
te</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p_int</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//operator 'delete' general =
is instanced for all other types</span></div></code></div><div><font color=
=3D"#666600" face=3D"monospace"><br></font></div><div><font color=3D"#66660=
0" face=3D"monospace"><br></font></div><div>This will be possible as 'int [=
]' is incomplete type anyway so a single object with it can't be constructe=
d.</div><div><br></div><div><i>Sometimes I wonder what drink people have wo=
rked on this standard.</i><div> <br><br>=D0=BF=D0=B5=D1=82=D1=8A=D0=BA=
, 20 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 23:45:33 UTC+2, Peter Koch Lars=
en =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">What is the purpose of this proposal? It will break existin=
g code and
<br>it is very difficult to find a place where anyone would consider using
<br>new [] (not to mention new) writing new C++ code.
<br>
<br>/Peter
<br>
<br>On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nIkm1xZ35SwJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">sash...@mail.bg</a>> wrote:
<br>> The problem is that operators 'new' and 'new []' have the same ret=
urn-value
<br>> type which is not good. I think it's better to know if a pointer w=
ill point
<br>> to a single object or to multiple ones just by looking into the co=
de.
<br>> Of-course seeing the instance of either 'new []' or 'new' is
<br>> self-explanatory but then comes the variable where it is stored. I=
suggest
<br>> instead of 'T *', 'new []' to return 'T (*)[]' which is named poin=
ter to
<br>> array of unknown bound. This way we can more clearly distinguish v=
ariable
<br>> proposes. Some examples:
<br>>
<br>> struct S
<br>> {
<br>> int *mvar;
<br>>
<br>> int (*pKey)[];
<br>>
<br>> double (*table)[];
<br>> }
<br>>
<br>>
<br>> The above shows variables intend way better then declaring all of =
them the
<br>> same.
<br>>
<br>> Note that this type already exists with few limitations which were=
recently
<br>> lifted (pointer or reference to one was forbidden in function para=
meter
<br>> types).
<br>>
<br>> If we introduce the return type of 'new []' to be 'T (*)[]' instea=
d of 'T *'
<br>> we introduce another level of clarity which is always a good thing=
.. Some
<br>> examples:
<br>>
<br>> auto p_int =3D new int; //'p_int' is of type 'int *'
<br>>
<br>>
<br>> extern int arr_size; //some 'lvalue'
<br>>
<br>>
<br>> auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type 'int (*=
)[]'
<br>>
<br>>
<br>> p_int =3D p_int_0; //error can't convert from 'int (*)[]' to 'int =
*'
<br>>
<br>>
<br>> void func(int *), func(int (*)[]);
<br>>
<br>>
<br>> func(p_int); //here 'void func(int *)' is instanced
<br>>
<br>>
<br>> func(p_int_0); //here 'void func(int (*)[])' is instanced
<br>>
<br>>
<br>>
<br>> Another good addition will be limiting operator 'new []' to only a=
ccept
<br>> constant-expressions as it's argument and so allocating arrays wit=
h fixed
<br>> size to invoke the 'new' operator. Examples:
<br>>
<br>>
<br>> auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type 'int (*)=
[90]',
<br>> operator 'new' is invoked
<br>>
<br>>
<br>> auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of type 'i=
nt (*)[]',
<br>> operator 'new []' is invoked
<br>>
<br>>
<br>> Tell me what do you think about this suggestion?
<br>>
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"nIkm1xZ35SwJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">std=
-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"nIkm1xZ35SwJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">std-pr...@isocpp.org</a>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://=
groups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=
=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>p=
roposals/</a>.
<br></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1392_1124917585.1426924426881--
------=_Part_1391_1459619838.1426924426881--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Sat, 21 Mar 2015 09:08:57 +0100
Raw View
--001a1135fe3edc099b0511c7f15a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
what's the benefit of this against :
unique_ptr<T> p =3D new T; // or even make_unique
unique_ptr<T[]> p =3D new T[4];
there you have your different type of "return" + ownership and lifetime
management all rolled in one.
2015-03-21 8:53 GMT+01:00 Alexander Marinov <sasho648@mail.bg>:
> First it'll add another level of clarification which is always a good
> thing as I said. But another (which I came up recently with) is that it'l=
l
> make redundant the 'delete []' operator. It'll be replaced by a special
> overload of the 'delete ' with parameter of type 'T (*)[]'. This will
> definitely easy our lives, doesn't it?
>
> Some examples:
>
> auto p_int_0 =3D new int[arr_size];
>
>
> auto p_int =3D new int;
>
>
> delete p_int_0; //operator 'delete' special overload for 'T (*)[]' is
> instanced
>
>
> delete p_int; //operator 'delete' general is instanced for all other type=
s
>
>
> This will be possible as 'int []' is incomplete type anyway so a single
> object with it can't be constructed.
>
> *Sometimes I wonder what drink people have worked on this standard.*
>
>
> =D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 20 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3.,=
23:45:33 UTC+2, Peter Koch Larsen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>
>> What is the purpose of this proposal? It will break existing code and
>> it is very difficult to find a place where anyone would consider using
>> new [] (not to mention new) writing new C++ code.
>>
>> /Peter
>>
>> On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <sash...@mail.bg>
>> wrote:
>> > The problem is that operators 'new' and 'new []' have the same
>> return-value
>> > type which is not good. I think it's better to know if a pointer will
>> point
>> > to a single object or to multiple ones just by looking into the code.
>> > Of-course seeing the instance of either 'new []' or 'new' is
>> > self-explanatory but then comes the variable where it is stored. I
>> suggest
>> > instead of 'T *', 'new []' to return 'T (*)[]' which is named pointer
>> to
>> > array of unknown bound. This way we can more clearly distinguish
>> variable
>> > proposes. Some examples:
>> >
>> > struct S
>> > {
>> > int *mvar;
>> >
>> > int (*pKey)[];
>> >
>> > double (*table)[];
>> > }
>> >
>> >
>> > The above shows variables intend way better then declaring all of them
>> the
>> > same.
>> >
>> > Note that this type already exists with few limitations which were
>> recently
>> > lifted (pointer or reference to one was forbidden in function paramete=
r
>> > types).
>> >
>> > If we introduce the return type of 'new []' to be 'T (*)[]' instead of
>> 'T *'
>> > we introduce another level of clarity which is always a good thing.
>> Some
>> > examples:
>> >
>> > auto p_int =3D new int; //'p_int' is of type 'int *'
>> >
>> >
>> > extern int arr_size; //some 'lvalue'
>> >
>> >
>> > auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type 'int (*)[]'
>> >
>> >
>> > p_int =3D p_int_0; //error can't convert from 'int (*)[]' to 'int *'
>> >
>> >
>> > void func(int *), func(int (*)[]);
>> >
>> >
>> > func(p_int); //here 'void func(int *)' is instanced
>> >
>> >
>> > func(p_int_0); //here 'void func(int (*)[])' is instanced
>> >
>> >
>> >
>> > Another good addition will be limiting operator 'new []' to only accep=
t
>> > constant-expressions as it's argument and so allocating arrays with
>> fixed
>> > size to invoke the 'new' operator. Examples:
>> >
>> >
>> > auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type 'int (*)[90]=
',
>> > operator 'new' is invoked
>> >
>> >
>> > auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of type 'int
>> (*)[]',
>> > operator 'new []' is invoked
>> >
>> >
>> > Tell me what do you think about this suggestion?
>> >
>> >
>> > --
>> >
>> > ---
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > Visit this group at
>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
> --
>
> ---
> 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/.
>
--=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/.
--001a1135fe3edc099b0511c7f15a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>what's the benefit of this against :<br><br>=
</div>unique_ptr<T> p =3D new T; // or even make_unique<br>unique_ptr=
<T[]> p =3D new T[4];<br><br></div>there you have your different type=
of "return" + ownership and lifetime management all rolled in on=
e.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-=
03-21 8:53 GMT+01:00 Alexander Marinov <span dir=3D"ltr"><<a href=3D"mai=
lto:sasho648@mail.bg" target=3D"_blank">sasho648@mail.bg</a>></span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">First it'll add anothe=
r level of clarification which is always a good thing as I said. But anothe=
r (which I came up recently with) is that it'll make redundant the '=
;delete []' operator. It'll be replaced by a special overload of th=
e 'delete ' with parameter of type 'T (*)[]'. This will def=
initely easy our lives, doesn't it?<div><br></div><div>Some examples:<b=
r><br><span style=3D"font-family:monospace;color:rgb(0,0,136);background-co=
lor:rgb(250,250,250)"></span></div><div style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div>=
<span class=3D""><span style=3D"color:#008">auto</span><span style=3D"color=
:#000"> p_int_0 </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">new</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#008">int</span><span style=3D"color:=
#660">[</span><span style=3D"color:#000">arr_size</span><span style=3D"colo=
r:#660">];</span><span style=3D"color:#000"><br><br><br></span></span><span=
class=3D""><span style=3D"color:#008">auto</span><span style=3D"color:#000=
"> p_int </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">new</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">int</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br><br><br></span></span><span style=3D"=
color:#008">delete</span><span style=3D"color:#000"> p_int_0</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">//operator 'delete' special overload for 'T (*)=
[]' is instanced</span><span style=3D"color:#000"><br><br><br></span><s=
pan style=3D"color:#008">delete</span><span style=3D"color:#000"> p_int</sp=
an><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#800">//operator 'delete' general is instanced f=
or all other types</span></div></code></div><div><font color=3D"#666600" fa=
ce=3D"monospace"><br></font></div><div><font color=3D"#666600" face=3D"mono=
space"><br></font></div><div>This will be possible as 'int []' is i=
ncomplete type anyway so a single object with it can't be constructed.<=
/div><div><br></div><div><i>Sometimes I wonder what drink people have worke=
d on this standard.</i><div>=C2=A0<br><br>=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 2=
0 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 23:45:33 UTC+2, Peter Koch Larsen =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">What is the =C2=A0purpose of this proposal? It will brea=
k existing code and
<br>it is very difficult to find a place where anyone would consider using
<br>new [] (not to mention new) writing new C++ code.
<br>
<br>/Peter
<br>
<br></span><div><div class=3D"h5">On Fri, Mar 20, 2015 at 8:18 PM, Alexande=
r Marinov <<a rel=3D"nofollow">sash...@mail.bg</a>> wrote:
<br>> The problem is that operators 'new' and 'new []' h=
ave the same return-value
<br>> type which is not good. I think it's better to know if a point=
er will point
<br>> to a single object or to multiple ones just by looking into the co=
de.
<br>> Of-course seeing the instance of either 'new []' or 'n=
ew' is
<br>> self-explanatory but then comes the variable where it is stored. I=
suggest
<br>> instead of 'T *', 'new []' to return 'T (*)[]&=
#39; which is named pointer to
<br>> array of unknown bound. This way we can more clearly distinguish v=
ariable
<br>> proposes. Some examples:
<br>>
<br>> struct S
<br>> {
<br>> =C2=A0 int *mvar;
<br>>
<br>> =C2=A0 int (*pKey)[];
<br>>
<br>> =C2=A0 double (*table)[];
<br>> }
<br>>
<br>>
<br>> The above shows variables intend way better then declaring all of =
them the
<br>> same.
<br>>
<br>> Note that this type already exists with few limitations which were=
recently
<br>> lifted (pointer or reference to one was forbidden in function para=
meter
<br>> types).
<br>>
<br>> If we introduce the return type of 'new []' to be 'T (=
*)[]' instead of 'T *'
<br>> we introduce another level of clarity which is always a good thing=
.. Some
<br>> examples:
<br>>
<br>> auto p_int =3D new int; //'p_int' is of type 'int *=
9;
<br>>
<br>>
<br>> extern int arr_size; //some 'lvalue'
<br>>
<br>>
<br>> auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type=
'int (*)[]'
<br>>
<br>>
<br>> p_int =3D p_int_0; //error can't convert from 'int (*)[]&#=
39; to 'int *'
<br>>
<br>>
<br>> void func(int *), func(int (*)[]);
<br>>
<br>>
<br>> func(p_int); //here 'void func(int *)' is instanced
<br>>
<br>>
<br>> func(p_int_0); //here 'void func(int (*)[])' is instanced
<br>>
<br>>
<br>>
<br>> Another good addition will be limiting operator 'new []' t=
o only accept
<br>> constant-expressions as it's argument and so allocating arrays=
with fixed
<br>> size to invoke the 'new' operator. Examples:
<br>>
<br>>
<br>> auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type =
'int (*)[90]',
<br>> operator 'new' is invoked
<br>>
<br>>
<br>> auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of=
type 'int (*)[]',
<br>> operator 'new []' is invoked
<br>>
<br>>
<br>> Tell me what do you think about this suggestion?
<br>>
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br></div></div>> email to <a rel=3D"nofollow">std-proposal...@<u></u>is=
ocpp.org</a>.
<br>> To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br><span class=3D"">> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/<u></u>i=
socpp.org/group/std-<u></u>proposals/</a>.
<br></span></blockquote></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135fe3edc099b0511c7f15a--
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 21 Mar 2015 03:13:25 -0700 (PDT)
Raw View
------=_Part_1452_70858266.1426932805550
Content-Type: multipart/alternative;
boundary="----=_Part_1453_1208936224.1426932805550"
------=_Part_1453_1208936224.1426932805550
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It's that some programmers like simplicity and performance in their=20
programs. This 'unique_ptr' will mostly cost some of it. In every case=20
whoever want to write that - I'm sure that this conversion from built-in=20
pointer to this class will be preserved.
Also here the possibility of mistake is increased as generally 'typeid(new=
=20
T) =3D=3D typeid(new T[])' and so those construct are also possible and wil=
l be=20
compiled fine producing hardly-traceable run-time errors:
unique_ptr<int[]> p { new int }; // no compiler error or even warning //=20
produces UB if object is destructed (almost surely)
unique_ptr<int > p1 { new int[4] }; //same as above
This is not a good thing.
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 10:08:58 UTC+2, Joel Falcou =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> what's the benefit of this against :
>
> unique_ptr<T> p =3D new T; // or even make_unique
> unique_ptr<T[]> p =3D new T[4];
>
> there you have your different type of "return" + ownership and lifetime=
=20
> management all rolled in one.
>
> 2015-03-21 8:53 GMT+01:00 Alexander Marinov <sash...@mail.bg <javascript:=
>
> >:
>
>> First it'll add another level of clarification which is always a good=20
>> thing as I said. But another (which I came up recently with) is that it'=
ll=20
>> make redundant the 'delete []' operator. It'll be replaced by a special=
=20
>> overload of the 'delete ' with parameter of type 'T (*)[]'. This will=20
>> definitely easy our lives, doesn't it?
>>
>> Some examples:
>>
>> auto p_int_0 =3D new int[arr_size];
>>
>>
>> auto p_int =3D new int;
>>
>>
>> delete p_int_0; //operator 'delete' special overload for 'T (*)[]' is=20
>> instanced
>>
>>
>> delete p_int; //operator 'delete' general is instanced for all other=20
>> types
>>
>>
>> This will be possible as 'int []' is incomplete type anyway so a single=
=20
>> object with it can't be constructed.
>>
>> *Sometimes I wonder what drink people have worked on this standard.*
>> =20
>>
>> =D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 20 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3.=
, 23:45:33 UTC+2, Peter Koch Larsen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>>
>>> What is the purpose of this proposal? It will break existing code and=
=20
>>> it is very difficult to find a place where anyone would consider using=
=20
>>> new [] (not to mention new) writing new C++ code.=20
>>>
>>> /Peter=20
>>>
>>> On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <sash...@mail.bg>=20
>>> wrote:=20
>>> > The problem is that operators 'new' and 'new []' have the same=20
>>> return-value=20
>>> > type which is not good. I think it's better to know if a pointer will=
=20
>>> point=20
>>> > to a single object or to multiple ones just by looking into the code.=
=20
>>> > Of-course seeing the instance of either 'new []' or 'new' is=20
>>> > self-explanatory but then comes the variable where it is stored. I=20
>>> suggest=20
>>> > instead of 'T *', 'new []' to return 'T (*)[]' which is named pointer=
=20
>>> to=20
>>> > array of unknown bound. This way we can more clearly distinguish=20
>>> variable=20
>>> > proposes. Some examples:=20
>>> >=20
>>> > struct S=20
>>> > {=20
>>> > int *mvar;=20
>>> >=20
>>> > int (*pKey)[];=20
>>> >=20
>>> > double (*table)[];=20
>>> > }=20
>>> >=20
>>> >=20
>>> > The above shows variables intend way better then declaring all of the=
m=20
>>> the=20
>>> > same.=20
>>> >=20
>>> > Note that this type already exists with few limitations which were=20
>>> recently=20
>>> > lifted (pointer or reference to one was forbidden in function=20
>>> parameter=20
>>> > types).=20
>>> >=20
>>> > If we introduce the return type of 'new []' to be 'T (*)[]' instead o=
f=20
>>> 'T *'=20
>>> > we introduce another level of clarity which is always a good thing.=
=20
>>> Some=20
>>> > examples:=20
>>> >=20
>>> > auto p_int =3D new int; //'p_int' is of type 'int *'=20
>>> >=20
>>> >=20
>>> > extern int arr_size; //some 'lvalue'=20
>>> >=20
>>> >=20
>>> > auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type 'int (*)[]=
'=20
>>> >=20
>>> >=20
>>> > p_int =3D p_int_0; //error can't convert from 'int (*)[]' to 'int *'=
=20
>>> >=20
>>> >=20
>>> > void func(int *), func(int (*)[]);=20
>>> >=20
>>> >=20
>>> > func(p_int); //here 'void func(int *)' is instanced=20
>>> >=20
>>> >=20
>>> > func(p_int_0); //here 'void func(int (*)[])' is instanced=20
>>> >=20
>>> >=20
>>> >=20
>>> > Another good addition will be limiting operator 'new []' to only=20
>>> accept=20
>>> > constant-expressions as it's argument and so allocating arrays with=
=20
>>> fixed=20
>>> > size to invoke the 'new' operator. Examples:=20
>>> >=20
>>> >=20
>>> > auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type 'int (*)[90=
]',=20
>>> > operator 'new' is invoked=20
>>> >=20
>>> >=20
>>> > auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of type 'int=
=20
>>> (*)[]',=20
>>> > operator 'new []' is invoked=20
>>> >=20
>>> >=20
>>> > Tell me what do you think about this suggestion?=20
>>> >=20
>>> >=20
>>> > --=20
>>> >=20
>>> > ---=20
>>> > You received this message because you are subscribed to the Google=20
>>> Groups=20
>>> > "ISO C++ Standard - Future Proposals" group.=20
>>> > To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>> an=20
>>> > email to std-proposal...@isocpp.org.=20
>>> > To post to this group, send email to std-pr...@isocpp.org.=20
>>> > Visit this group at=20
>>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=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_1453_1208936224.1426932805550
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's that some programmers like simplicity and performance=
in their programs. This 'unique_ptr' will mostly cost some of it. In every=
case whoever want to write that - I'm sure that this conversion from built=
-in pointer to this class will be preserved.<div><br></div><div>Also here t=
he possibility of mistake is increased as generally 'typeid(new T) =3D=3D t=
ypeid(new T[])' and so those construct are also possible and will be compil=
ed fine producing hardly-traceable run-time errors:<br><br>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">unique_ptr</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">[]></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> p </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">new</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// no compiler error or even warning // produces UB if object is=
destructed (almost surely)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br><br>unique_ptr</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> p1 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//same as above</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></di=
v></code></div><pre><span style=3D" color:#000000;"><br></span><!--EndFragm=
ent--></pre><pre><font color=3D"#000000">This is not a good thing.</font></=
pre><br>=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D0=BC=D0=B0=D1=80=D1=82 2=
015 =D0=B3., 10:08:58 UTC+2, Joel Falcou =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
>what's the benefit of this against :<br><br></div>unique_ptr<T> p =
=3D new T; // or even make_unique<br>unique_ptr<T[]> p =3D new T[4];<=
br><br></div>there you have your different type of "return" + ownership and=
lifetime management all rolled in one.<br></div><div><br><div class=3D"gma=
il_quote">2015-03-21 8:53 GMT+01:00 Alexander Marinov <span dir=3D"ltr"><=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Qig6IaA=
kYP4J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">sash...@mail.bg</a>&=
gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">First it'll =
add another level of clarification which is always a good thing as I said. =
But another (which I came up recently with) is that it'll make redundant th=
e 'delete []' operator. It'll be replaced by a special overload of the 'del=
ete ' with parameter of type 'T (*)[]'. This will definitely easy our lives=
, doesn't it?<div><br></div><div>Some examples:<br><br><span style=3D"font-=
family:monospace;color:rgb(0,0,136);background-color:rgb(250,250,250)"></sp=
an></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-wo=
rd;background-color:rgb(250,250,250)"><code><div><span><span style=3D"color=
:#008">auto</span><span style=3D"color:#000"> p_int_0 </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">new</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">int</span><span style=3D"color:#660">[</span><span style=3D"color:#0=
00">arr_size</span><span style=3D"color:#660">];</span><span style=3D"color=
:#000"><br><br><br></span></span><span><span style=3D"color:#008">auto</spa=
n><span style=3D"color:#000"> p_int </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">new</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">int</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br><br><br></=
span></span><span style=3D"color:#008">delete</span><span style=3D"color:#0=
00"> p_int_0</span><span style=3D"color:#660">;</span><span style=3D"color:=
#000"> </span><span style=3D"color:#800">//operator 'delete' special overlo=
ad for 'T (*)[]' is instanced</span><span style=3D"color:#000"><br><br><br>=
</span><span style=3D"color:#008">delete</span><span style=3D"color:#000"> =
p_int</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
</span><span style=3D"color:#800">//operator 'delete' general is instanced =
for all other types</span></div></code></div><div><font color=3D"#666600" f=
ace=3D"monospace"><br></font></div><div><font color=3D"#666600" face=3D"mon=
ospace"><br></font></div><div>This will be possible as 'int []' is incomple=
te type anyway so a single object with it can't be constructed.</div><div><=
br></div><div><i>Sometimes I wonder what drink people have worked on this s=
tandard.</i><div> <br><br>=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 20 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 23:45:33 UTC+2, Peter Koch Larsen =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span>W=
hat is the purpose of this proposal? It will break existing code and
<br>it is very difficult to find a place where anyone would consider using
<br>new [] (not to mention new) writing new C++ code.
<br>
<br>/Peter
<br>
<br></span><div><div>On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <=
;<a rel=3D"nofollow">sash...@mail.bg</a>> wrote:
<br>> The problem is that operators 'new' and 'new []' have the same ret=
urn-value
<br>> type which is not good. I think it's better to know if a pointer w=
ill point
<br>> to a single object or to multiple ones just by looking into the co=
de.
<br>> Of-course seeing the instance of either 'new []' or 'new' is
<br>> self-explanatory but then comes the variable where it is stored. I=
suggest
<br>> instead of 'T *', 'new []' to return 'T (*)[]' which is named poin=
ter to
<br>> array of unknown bound. This way we can more clearly distinguish v=
ariable
<br>> proposes. Some examples:
<br>>
<br>> struct S
<br>> {
<br>> int *mvar;
<br>>
<br>> int (*pKey)[];
<br>>
<br>> double (*table)[];
<br>> }
<br>>
<br>>
<br>> The above shows variables intend way better then declaring all of =
them the
<br>> same.
<br>>
<br>> Note that this type already exists with few limitations which were=
recently
<br>> lifted (pointer or reference to one was forbidden in function para=
meter
<br>> types).
<br>>
<br>> If we introduce the return type of 'new []' to be 'T (*)[]' instea=
d of 'T *'
<br>> we introduce another level of clarity which is always a good thing=
.. Some
<br>> examples:
<br>>
<br>> auto p_int =3D new int; //'p_int' is of type 'int *'
<br>>
<br>>
<br>> extern int arr_size; //some 'lvalue'
<br>>
<br>>
<br>> auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type 'int (*=
)[]'
<br>>
<br>>
<br>> p_int =3D p_int_0; //error can't convert from 'int (*)[]' to 'int =
*'
<br>>
<br>>
<br>> void func(int *), func(int (*)[]);
<br>>
<br>>
<br>> func(p_int); //here 'void func(int *)' is instanced
<br>>
<br>>
<br>> func(p_int_0); //here 'void func(int (*)[])' is instanced
<br>>
<br>>
<br>>
<br>> Another good addition will be limiting operator 'new []' to only a=
ccept
<br>> constant-expressions as it's argument and so allocating arrays wit=
h fixed
<br>> size to invoke the 'new' operator. Examples:
<br>>
<br>>
<br>> auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type 'int (*)=
[90]',
<br>> operator 'new' is invoked
<br>>
<br>>
<br>> auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of type 'i=
nt (*)[]',
<br>> operator 'new []' is invoked
<br>>
<br>>
<br>> Tell me what do you think about this suggestion?
<br>>
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br></div></div>> email to <a rel=3D"nofollow">std-proposal...@<u></u>is=
ocpp.org</a>.
<br>> To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br><span>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://=
groups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=
=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;">http://groups.google.com/a/<u></u>iso<wbr>cpp.org/group/std=
-<u></u>proposals/</a>.
<br></span></blockquote></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Qig6IaAkYP4J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Qig6IaAkYP4J" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1453_1208936224.1426932805550--
------=_Part_1452_70858266.1426932805550--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Sat, 21 Mar 2015 11:37:37 +0100
Raw View
--001a1135fe3e850cca0511ca05f3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
unique_ptr is a simple wrapper around T* , there is no overhead cost
involved.
You 're mistaking unique_ptr with shared_ptr which indeed have an overhead
2015-03-21 11:13 GMT+01:00 Alexander Marinov <sasho648@mail.bg>:
> It's that some programmers like simplicity and performance in their
> programs. This 'unique_ptr' will mostly cost some of it. In every case
> whoever want to write that - I'm sure that this conversion from built-in
> pointer to this class will be preserved.
>
> Also here the possibility of mistake is increased as generally 'typeid(ne=
w
> T) =3D=3D typeid(new T[])' and so those construct are also possible and w=
ill be
> compiled fine producing hardly-traceable run-time errors:
>
> unique_ptr<int[]> p { new int }; // no compiler error or even warning //
> produces UB if object is destructed (almost surely)
>
>
> unique_ptr<int > p1 { new int[4] }; //same as above
>
>
> This is not a good thing.
>
>
> =D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D0=BC=D0=B0=D1=80=D1=82 2015 =
=D0=B3., 10:08:58 UTC+2, Joel Falcou =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>
>> what's the benefit of this against :
>>
>> unique_ptr<T> p =3D new T; // or even make_unique
>> unique_ptr<T[]> p =3D new T[4];
>>
>> there you have your different type of "return" + ownership and lifetime
>> management all rolled in one.
>>
>> 2015-03-21 8:53 GMT+01:00 Alexander Marinov <sash...@mail.bg>:
>>
>>> First it'll add another level of clarification which is always a good
>>> thing as I said. But another (which I came up recently with) is that it=
'll
>>> make redundant the 'delete []' operator. It'll be replaced by a special
>>> overload of the 'delete ' with parameter of type 'T (*)[]'. This will
>>> definitely easy our lives, doesn't it?
>>>
>>> Some examples:
>>>
>>> auto p_int_0 =3D new int[arr_size];
>>>
>>>
>>> auto p_int =3D new int;
>>>
>>>
>>> delete p_int_0; //operator 'delete' special overload for 'T (*)[]' is
>>> instanced
>>>
>>>
>>> delete p_int; //operator 'delete' general is instanced for all other
>>> types
>>>
>>>
>>> This will be possible as 'int []' is incomplete type anyway so a single
>>> object with it can't be constructed.
>>>
>>> *Sometimes I wonder what drink people have worked on this standard.*
>>>
>>>
>>> =D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 20 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3=
.., 23:45:33 UTC+2, Peter Koch Larsen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>>>
>>>> What is the purpose of this proposal? It will break existing code and
>>>> it is very difficult to find a place where anyone would consider using
>>>> new [] (not to mention new) writing new C++ code.
>>>>
>>>> /Peter
>>>>
>>>> On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <sash...@mail.bg>
>>>> wrote:
>>>> > The problem is that operators 'new' and 'new []' have the same
>>>> return-value
>>>> > type which is not good. I think it's better to know if a pointer wil=
l
>>>> point
>>>> > to a single object or to multiple ones just by looking into the code=
..
>>>> > Of-course seeing the instance of either 'new []' or 'new' is
>>>> > self-explanatory but then comes the variable where it is stored. I
>>>> suggest
>>>> > instead of 'T *', 'new []' to return 'T (*)[]' which is named pointe=
r
>>>> to
>>>> > array of unknown bound. This way we can more clearly distinguish
>>>> variable
>>>> > proposes. Some examples:
>>>> >
>>>> > struct S
>>>> > {
>>>> > int *mvar;
>>>> >
>>>> > int (*pKey)[];
>>>> >
>>>> > double (*table)[];
>>>> > }
>>>> >
>>>> >
>>>> > The above shows variables intend way better then declaring all of
>>>> them the
>>>> > same.
>>>> >
>>>> > Note that this type already exists with few limitations which were
>>>> recently
>>>> > lifted (pointer or reference to one was forbidden in function
>>>> parameter
>>>> > types).
>>>> >
>>>> > If we introduce the return type of 'new []' to be 'T (*)[]' instead
>>>> of 'T *'
>>>> > we introduce another level of clarity which is always a good thing.
>>>> Some
>>>> > examples:
>>>> >
>>>> > auto p_int =3D new int; //'p_int' is of type 'int *'
>>>> >
>>>> >
>>>> > extern int arr_size; //some 'lvalue'
>>>> >
>>>> >
>>>> > auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type 'int (*)[=
]'
>>>> >
>>>> >
>>>> > p_int =3D p_int_0; //error can't convert from 'int (*)[]' to 'int *'
>>>> >
>>>> >
>>>> > void func(int *), func(int (*)[]);
>>>> >
>>>> >
>>>> > func(p_int); //here 'void func(int *)' is instanced
>>>> >
>>>> >
>>>> > func(p_int_0); //here 'void func(int (*)[])' is instanced
>>>> >
>>>> >
>>>> >
>>>> > Another good addition will be limiting operator 'new []' to only
>>>> accept
>>>> > constant-expressions as it's argument and so allocating arrays with
>>>> fixed
>>>> > size to invoke the 'new' operator. Examples:
>>>> >
>>>> >
>>>> > auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type 'int
>>>> (*)[90]',
>>>> > operator 'new' is invoked
>>>> >
>>>> >
>>>> > auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of type 'int
>>>> (*)[]',
>>>> > operator 'new []' is invoked
>>>> >
>>>> >
>>>> > Tell me what do you think about this suggestion?
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > ---
>>>> > 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-proposal...@isocpp.org.
>>>> > To post to this group, send email to std-pr...@isocpp.org.
>>>> > Visit this group at
>>>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>> --
>>>
>>> ---
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>> proposals/.
>>>
>>
>> --
>
> ---
> 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/.
>
--=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/.
--001a1135fe3e850cca0511ca05f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>unique_ptr is a simple wrapper around T* , there is n=
o overhead cost involved.<br></div>You 're mistaking unique_ptr with sh=
ared_ptr which indeed have an overhead<br></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">2015-03-21 11:13 GMT+01:00 Alexander Marinov=
<span dir=3D"ltr"><<a href=3D"mailto:sasho648@mail.bg" target=3D"_blank=
">sasho648@mail.bg</a>></span>:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">It's that some programmers like simplicity and performance i=
n their programs. This 'unique_ptr' will mostly cost some of it. In=
every case whoever want to write that - I'm sure that this conversion =
from built-in pointer to this class will be preserved.<div><br></div><div>A=
lso here the possibility of mistake is increased as generally 'typeid(n=
ew T) =3D=3D typeid(new T[])' and so those construct are also possible =
and will be compiled fine producing hardly-traceable run-time errors:<br><b=
r>
<div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgr=
ound-color:rgb(250,250,250)"><code><div><span style=3D"color:#000">unique_p=
tr</span><span style=3D"color:#660"><</span><span style=3D"color:#008">i=
nt</span><span style=3D"color:#660">[]></span><span style=3D"color:#000"=
> p </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">new</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">};</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#800">// no compiler error or even warning // produces UB =
if object is destructed (almost surely)</span><span style=3D"color:#000"><b=
r><br><br>unique_ptr</span><span style=3D"color:#660"><</span><span styl=
e=3D"color:#008">int</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">></span><span style=3D"color:#000"> p1 </span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">new</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">int</span><span style=3D"color:#660">[</span><span style=3D"color:=
#066">4</span><span style=3D"color:#660">]</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">};</span><span style=3D"color:#000"> </=
span><span style=3D"color:#800">//same as above</span><span style=3D"color:=
#000"><br></span></div></code></div><pre><span style=3D"color:#000000"><br>=
</span></pre><pre><font color=3D"#000000">This is not a good thing.</font><=
/pre><br>=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 21 =D0=BC=D0=B0=D1=80=D1=82 =
2015 =D0=B3., 10:08:58 UTC+2, Joel Falcou =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"lt=
r"><div><div>what's the benefit of this against :<br><br></div>unique_p=
tr<T> p =3D new T; // or even make_unique<br>unique_ptr<T[]> p =
=3D new T[4];<br><br></div>there you have your different type of "retu=
rn" + ownership and lifetime management all rolled in one.<br></div></=
span><div><div class=3D"h5"><div><br><div class=3D"gmail_quote">2015-03-21 =
8:53 GMT+01:00 Alexander Marinov <span dir=3D"ltr"><<a rel=3D"nofollow">=
sash...@mail.bg</a>></span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">First it'll add another level of clarification which is always=
a good thing as I said. But another (which I came up recently with) is tha=
t it'll make redundant the 'delete []' operator. It'll be r=
eplaced by a special overload of the 'delete ' with parameter of ty=
pe 'T (*)[]'. This will definitely easy our lives, doesn't it?<=
div><br></div><div>Some examples:<br><br><span style=3D"font-family:monospa=
ce;color:rgb(0,0,136);background-color:rgb(250,250,250)"></span></div><div =
style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-=
color:rgb(250,250,250)"><code><div><span><span style=3D"color:#008">auto</s=
pan><span style=3D"color:#000"> p_int_0 </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008">new=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</s=
pan><span style=3D"color:#660">[</span><span style=3D"color:#000">arr_size<=
/span><span style=3D"color:#660">];</span><span style=3D"color:#000"><br><b=
r><br></span></span><span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> p_int </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">new</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">int</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br><br><br></span></span><=
span style=3D"color:#008">delete</span><span style=3D"color:#000"> p_int_0<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span=
><span style=3D"color:#800">//operator 'delete' special overload fo=
r 'T (*)[]' is instanced</span><span style=3D"color:#000"><br><br><=
br></span><span style=3D"color:#008">delete</span><span style=3D"color:#000=
"> p_int</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#800">//operator 'delete' general is=
instanced for all other types</span></div></code></div><div><font face=3D"=
monospace" color=3D"#666600"><br></font></div><div><font face=3D"monospace"=
color=3D"#666600"><br></font></div><div>This will be possible as 'int =
[]' is incomplete type anyway so a single object with it can't be c=
onstructed.</div><div><br></div><div><i>Sometimes I wonder what drink peopl=
e have worked on this standard.</i><div>=C2=A0<br><br>=D0=BF=D0=B5=D1=82=D1=
=8A=D0=BA, 20 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 23:45:33 UTC+2, Peter =
Koch Larsen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span>What is the =C2=A0purpose of this proposal? It will bre=
ak existing code and
<br>it is very difficult to find a place where anyone would consider using
<br>new [] (not to mention new) writing new C++ code.
<br>
<br>/Peter
<br>
<br></span><div><div>On Fri, Mar 20, 2015 at 8:18 PM, Alexander Marinov <=
;<a rel=3D"nofollow">sash...@mail.bg</a>> wrote:
<br>> The problem is that operators 'new' and 'new []' h=
ave the same return-value
<br>> type which is not good. I think it's better to know if a point=
er will point
<br>> to a single object or to multiple ones just by looking into the co=
de.
<br>> Of-course seeing the instance of either 'new []' or 'n=
ew' is
<br>> self-explanatory but then comes the variable where it is stored. I=
suggest
<br>> instead of 'T *', 'new []' to return 'T (*)[]&=
#39; which is named pointer to
<br>> array of unknown bound. This way we can more clearly distinguish v=
ariable
<br>> proposes. Some examples:
<br>>
<br>> struct S
<br>> {
<br>> =C2=A0 int *mvar;
<br>>
<br>> =C2=A0 int (*pKey)[];
<br>>
<br>> =C2=A0 double (*table)[];
<br>> }
<br>>
<br>>
<br>> The above shows variables intend way better then declaring all of =
them the
<br>> same.
<br>>
<br>> Note that this type already exists with few limitations which were=
recently
<br>> lifted (pointer or reference to one was forbidden in function para=
meter
<br>> types).
<br>>
<br>> If we introduce the return type of 'new []' to be 'T (=
*)[]' instead of 'T *'
<br>> we introduce another level of clarity which is always a good thing=
.. Some
<br>> examples:
<br>>
<br>> auto p_int =3D new int; //'p_int' is of type 'int *=
9;
<br>>
<br>>
<br>> extern int arr_size; //some 'lvalue'
<br>>
<br>>
<br>> auto p_int_0 =3D new int[arr_size]; //'p_int_0' is of type=
'int (*)[]'
<br>>
<br>>
<br>> p_int =3D p_int_0; //error can't convert from 'int (*)[]&#=
39; to 'int *'
<br>>
<br>>
<br>> void func(int *), func(int (*)[]);
<br>>
<br>>
<br>> func(p_int); //here 'void func(int *)' is instanced
<br>>
<br>>
<br>> func(p_int_0); //here 'void func(int (*)[])' is instanced
<br>>
<br>>
<br>>
<br>> Another good addition will be limiting operator 'new []' t=
o only accept
<br>> constant-expressions as it's argument and so allocating arrays=
with fixed
<br>> size to invoke the 'new' operator. Examples:
<br>>
<br>>
<br>> auto p_int_1 =3D new int[90]; //here 'p_int_1' is of type =
'int (*)[90]',
<br>> operator 'new' is invoked
<br>>
<br>>
<br>> auto p_int_2 =3D new int[arr_size]; //here 'p_int_2' is of=
type 'int (*)[]',
<br>> operator 'new []' is invoked
<br>>
<br>>
<br>> Tell me what do you think about this suggestion?
<br>>
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br></div></div>> email to <a rel=3D"nofollow">std-proposal...@<u></u>is=
ocpp.org</a>.
<br>> To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br><span>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/<u></u>i=
so<u></u>cpp.org/group/std-<u></u>proposals/</a>.
<br></span></blockquote></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/<u></u>isocpp.org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div><div class=3D"HOEnZb"><div class=3D"h5=
">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135fe3e850cca0511ca05f3--
.
Author: gmisocpp@gmail.com
Date: Sat, 21 Mar 2015 08:57:27 -0700 (PDT)
Raw View
------=_Part_2460_1884740225.1426953447714
Content-Type: multipart/alternative;
boundary="----=_Part_2461_1445168325.1426953447714"
------=_Part_2461_1445168325.1426953447714
Content-Type: text/plain; charset=UTF-8
On Saturday, March 21, 2015 at 11:13:25 PM UTC+13, Alexander Marinov wrote:
>
> It's that some programmers like simplicity and performance in their
> programs. This 'unique_ptr' will mostly cost some of it. In every case
> whoever want to write that - I'm sure that this conversion from built-in
> pointer to this class will be preserved.
>
> Also here the possibility of mistake is increased as generally 'typeid(new
> T) == typeid(new T[])' and so those construct are also possible and will be
> compiled fine producing hardly-traceable run-time errors:
>
> unique_ptr<int[]> p { new int }; // no compiler error or even warning //
> produces UB if object is destructed (almost surely)
>
>
I strongly agree this particularly example is important to fix however we
to fix it.
I've made this mistake several times typing this:
auto p = std::make_unique<char[]>(1024); // and forgetting the []
I suggest it's better to type something like this:
auto p = make_array_ptr<char>(N);
It invokes better muscle memory and avoids the problem and is clearer to
read.
--
---
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_2461_1445168325.1426953447714
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, March 21, 2015 at 11:13:25 PM UTC+13,=
Alexander Marinov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">It's=
that some programmers like simplicity and performance in their programs. T=
his 'unique_ptr' will mostly cost some of it. In every case whoever want to=
write that - I'm sure that this conversion from built-in pointer to this c=
lass will be preserved.<div><br></div><div>Also here the possibility of mis=
take is increased as generally 'typeid(new T) =3D=3D typeid(new T[])' and s=
o those construct are also possible and will be compiled fine producing har=
dly-traceable run-time errors:<br><br>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code><div><=
span style=3D"color: rgb(0, 0, 0);">unique_ptr</span><span style=3D"color: =
rgb(102, 102, 0);"><</span><span style=3D"color: rgb(0, 0, 136);">int</s=
pan><span style=3D"color: rgb(102, 102, 0);">[]></span><span style=3D"co=
lor: rgb(0, 0, 0);"> p </span><span style=3D"color: rgb(102, 102, 0);">{</s=
pan><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(=
0, 0, 136);">new</span><span style=3D"color: rgb(0, 0, 0);"> </span><span s=
tyle=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(0, 0, 0=
);"> </span><span style=3D"color: rgb(102, 102, 0);">};</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(136, 0, 0);">//=
no compiler error or even warning // produces UB if object is destructed (=
almost surely)</span><span style=3D"color: rgb(0, 0, 0);"><br><br></span></=
div></code></div></div></div></blockquote><div><br></div><div>I strongly ag=
ree this particularly example is important to fix however we to f=
ix it.</div><div>I've made this mistake several times typing this:</di=
v><div><br></div><div>auto p =3D std::make_unique<char[]>(1024);=
// and forgetting the []</div><div><br></div><div>I suggest it's bett=
er to type something like this:</div><div>auto p =3D make_ar=
ray_ptr<char>(N);</div><div><br></div><div>It invokes better mus=
cle memory and avoids the problem and is clearer to read.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2461_1445168325.1426953447714--
------=_Part_2460_1884740225.1426953447714--
.