Topic: Suggestion for banning arrays as parameters
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 24 Nov 2014 19:39:01 -0800
Raw View
On Monday 24 November 2014 15:14:17 sasho648 wrote:
> > @Douglas Boffey "Not really" is not an argument. And I'm not proposing
> > to include 'passing an array by value' but just to drop support for this
> > misleading syntax of 'array' formal parameters.
>
> @Bo Persson 40, 60 - is this really an useful post?
I thought it was. He linked your proposal, but was arguing that 40 years too
late there's way too much legacy.
This is not the same as the auto and register keywords inherited from B and C,
since those had very limited use and meant nothing even when used. Deprecating
a language construct has to have a VERY compelling use and needs to examine
how much code will break. I think your proposal fails both checks.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Thiago Macieira <thiago@macieira.org>
Date: Tue, 25 Nov 2014 09:04:11 -0800
Raw View
On Tuesday 25 November 2014 04:19:09 sasho648 wrote:
> @ Thiago Macieira There is actually a very similar breaking change
> introduced with 'C++ 11' which is the '
> <http://stackoverflow.com/questions/4434140/narrowing-conversions-in-c0x-is-> it-just-me-or-does-this-sound-like-a-breakin>*narrowing conversion'
> <http://stackoverflow.com/questions/4434140/narrowing-conversions-in-c0x-is-> it-just-me-or-does-this-sound-like-a-breakin>. *Such ill-formed
> constructions aren't something rare in 'old' C++ code, as the question
> shows but fixing it is simple. And also many compilers are still accepting
> it with only a warning (like 'gcc' for example). So I don't see why can't
> the same happen with formal parameter arrays?
The narrowing conversion problem passed the test I put forward. It had a very
good reason for being and it help catch possibly broken code.
Array parameters aren't wrong today and wherever they're used, they are used
for legitimate uses. In fact, as recently as yesterday, I saw someone posting
this:
int main(int argc, char *argv[])
This is too ingrained in people's coding styles that arrays and pointers are
the same thing.
Anyway, C++ has a way to pass an actual array. I don't see why we should
deviate even further from C.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Tue, 25 Nov 2014 12:42:18 -0500
Raw View
On Tue, Nov 25, 2014 at 12:37 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> On 2014-11-25 12:04, Thiago Macieira wrote:
>> Array parameters aren't wrong today and wherever they're used, they are used
>> for legitimate uses. In fact, as recently as yesterday, I saw someone posting
>> this:
>>
>> int main(int argc, char *argv[])
>>
>> This is too ingrained in people's coding styles that arrays and pointers are
>> the same thing.
>
> What about deprecating just "sized" arrays?
>
As an irresponsible library person, I think it's a good idea. And the
way matches what we have in smart pointers: unique_ptr<T[]> and
the coming shared_ptr<T[]>.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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: Thiago Macieira <thiago@macieira.org>
Date: Tue, 25 Nov 2014 09:50:34 -0800
Raw View
On Tuesday 25 November 2014 12:37:38 Matthew Woehlke wrote:
> > int main(int argc, char *argv[])
> >
> > This is too ingrained in people's coding styles that arrays and pointers
> > are the same thing.
>
> What about deprecating just "sized" arrays?
>
> IIUC, right now 'int foo[]' and 'int foo[3]' mean exactly the same thing
> (as parameters) to the compiler. However I bet lots of people make the
> mistake of thinking that specifying a size provides some additional
> guarantees as to what can be passed.
That makes sense. C99 added an actually safe version of passing the sized
array, but I don't know any compiler that actually implements that:
void f(int foo[static 3]);
All compilers I've tried in the past treat that as if the static were not
there.
> > Anyway, C++ has a way to pass an actual array. I don't see why we should
> > deviate even further from C.
>
> ...and deprecating would be a good way to encourage people to start
> actually *using* better methods :-).
>
> That said... std::array isn't always the answer. What if I need to pass
> an "array" by reference, but the caller doesn't have a std::array?
> (Maybe I want to do something to a subset of a larger block of memory,
> or have a std::vector, or...)
I wasn't talking about std::array. I meant passing the array by reference:
void f(int (&foo)[3])
In this case, only an array of 3 ints can be passed. Not a pointer, not a
larger array, not a smaller one.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 25 Nov 2014 13:53:13 -0800
Raw View
--047d7b33da2417b6930508b5f045
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 25, 2014 at 12:53 PM, Myriachan <myriachan@gmail.com> wrote:
> On Tuesday, November 25, 2014 10:09:11 AM UTC-8, Matthew Woehlke wrote:
>>
>> On 2014-11-25 12:50, Thiago Macieira wrote:
>> > On 2014-11-25 12:04, Thiago Macieira wrote:
>> >> Anyway, C++ has a way to pass an actual array. I don't see why we
>> should
>> >> deviate even further from C.
>> >
>> > I wasn't talking about std::array. I meant passing the array by
>> reference:
>> >
>> > void f(int (&foo)[3])
>>
>> Ah. Right, I've done that. However, I've run into instances where I
>> *want* to pass (part of) a larger array to such a function. It would be
>> nice to have a way to do that, that still has guarantees (static where
>> possible, runtime otherwise) that the passed array isn't too small.
>>
>> A typical example is a function that works with RGB colors expressed as
>> tuples (usually float/double), but I want to use that on the RGB portion
>> of an RGBA array. (Interestingly, *GLSL* provides mechanisms for this
>> :-)...)
>>
>>
> I've run into a similar problem, that you can't use a vector4 as a
> vector3, except that they were vectors in =E2=84=9D=C2=B3, not color-spac=
e.
>
> I think that any solution to this needs to address the annoyance that
> T(*)[S] doesn't decay to T(*)[] implicitly, and likewise for references.
>
That's EWG issue 118 (http://cplusplus.github.io/EWG/ewg-active.html#118);
I have a paper with the wording changes, but I didn't present it at Urbana
because it depends on CWG330 / N4178. I intend to present it at Lenexa.
> Similarly, removing the pointless restriction that T(*)[] is an illegal
> function parameter type.
>
That restriction no longer exists; it was removed by core issue 393 (
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#393) which was
moved at Urbana.
> Then perhaps static_cast could be changed to permit converting from
> T(*)[S1] to T(*)[S2] for S1 >=3D S2 in addition to the automatic decay?
>
Reducing the bound in this case seems like it could be an implicit
conversion; increasing the bound would presumably require a static_cast.
But this raises problems, since it either removes the ability of an
optimizer to assume that T(&)[N] decays to a pointer through which exactly
N elements can be accessed, or results in that pointer being a somehow
different value from the value you'd get decaying the original pointer.
Both of these options seem strange.
--=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/.
--047d7b33da2417b6930508b5f045
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 25, 2014 at 12:53 PM, Myriachan <span dir=3D"ltr"><<a href=3D"ma=
ilto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday=
, November 25, 2014 10:09:11 AM UTC-8, Matthew Woehlke wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x">On 2014-11-25 12:50, Thiago Macieira wrote:
<br>> On 2014-11-25 12:04, Thiago Macieira wrote:
<br>>> Anyway, C++ has a way to pass an actual array. I don't see=
why we should
<br>>> deviate even further from C.
<br>>=20
<br>> I wasn't talking about std::array. I meant passing the array b=
y reference:
<br>>=20
<br>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0void f(int (&f=
oo)[3])
<br>
<br>Ah. Right, I've done that. However, I've run into instances whe=
re I
<br>*want* to pass (part of) a larger array to such a function. It would be
<br>nice to have a way to do that, that still has guarantees (static where
<br>possible, runtime otherwise) that the passed array isn't too small.
<br>
<br>A typical example is a function that works with RGB colors expressed as
<br>tuples (usually float/double), but I want to use that on the RGB portio=
n
<br>of an RGBA array. (Interestingly, *GLSL* provides mechanisms for this
<br>:-)...)
<br>
<br></blockquote></span><div><br>I've run into a similar problem, that =
you can't use a vector4 as a vector3, except that they were vectors in =
=E2=84=9D=C2=B3, not color-space.</div></div></blockquote><div>=C2=A0<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>I think that any solution to thi=
s needs to address the annoyance that <span style=3D"font-family:'couri=
er new',monospace">T(*)[S]</span> doesn't decay to <span style=3D"f=
ont-family:'courier new',monospace">T(*)[]</span> implicitly, and l=
ikewise for references.</div></div></blockquote><div><br></div><div>That=
9;s EWG issue 118 (<a href=3D"http://cplusplus.github.io/EWG/ewg-active.htm=
l#118">http://cplusplus.github.io/EWG/ewg-active.html#118</a>); I have a pa=
per with the wording changes, but I didn't present it at Urbana because=
it depends on CWG330 / N4178. I intend to present it at Lenexa.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Similarly, removing =
the pointless restriction that <span style=3D"font-family:'courier new&=
#39;,monospace">T(*)[]</span> is an illegal function parameter type.</div><=
/div></blockquote><div><br></div><div>That restriction no longer exists; it=
was removed by core issue 393 (<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/cwg_active.html#393">http://www.open-std.org/jtc1/sc22/wg21/doc=
s/cwg_active.html#393</a>) which was moved at Urbana.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Then perhaps <span style=3D"font-fa=
mily:'courier new',monospace">static_cast</span> could be changed t=
o permit converting from <span style=3D"font-family:'courier new',m=
onospace">T(*)[S1]</span> to <span style=3D"font-family:'courier new=
9;,monospace">T(*)[S2]</span> for <span style=3D"font-family:'courier n=
ew',monospace">S1</span> >=3D <span style=3D"font-family:'courie=
r new',monospace">S2</span> in addition to the automatic decay?</div></=
div></blockquote><div><br></div><div>Reducing the bound in this case seems =
like it could be an implicit conversion; increasing the bound would presuma=
bly require a static_cast. But this raises problems, since it either remove=
s the ability of an optimizer to assume that T(&)[N] decays to a pointe=
r through which exactly N elements can be accessed, or results in that poin=
ter being a somehow different value from the value you'd get decaying t=
he original pointer. Both of these options seem strange.</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 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 />
--047d7b33da2417b6930508b5f045--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 25 Nov 2014 19:24:18 -0800
Raw View
On Tuesday 25 November 2014 14:00:41 sasho648 wrote:
> You're talking real? So in this case declaring a variable like this:
>
> int *pArray;
>
> will be the same as declaring it like this:
>
>
> int pArray[200];
>
> If you can't distinguish pointers from arrays you should really stop using
> 'C++' forever.
That's not what I meant and you know it. We're talking about function
parameters (it's right there in the subject!) and there these two functions
are the same:
void f(int *pArray);
void f(int pArray[]);
That's too ingrained in people's coding styles.
> Not legal:
>
> int Func(int *)[5];
>
> *Compiler thoughts:
>
> An return value with an array type, I can't implement this so I'll stop
> compiling and report the user.
You have to go back to early days of C and think "I don't know how to return
an array". Additionally, since arrays decay to pointers, it's impossible to
know the size of the array that the caller must allocate so that the callee
can receive it.
Note that you can return an array if it's inside an aggregate:
struct Array { int v[5]; };
Array Func(int *);
Because now the size is known and there's no pointer decay.
> Legal:
>
> int *Func(int [5]);
>
>
> *Compiler thoughts:
>
> An argument with an array type, hmm - Let's not get the user mad again and
> implicitly convert it to a pointer, I believe he will like that.
Again, that's a simplistic view of what the process went behind the C language
evolution. Being allowed to pass an array is a consequence of array decay to
pointer.
> About the arrays of unknown bounds - I believe is a good idea to deprecate
> them too as being a formal parameters because, they fall into category
> 'arrays' too.
I don't think that's going to happen for the reason I gave above: way too many
people know that parameters of array types are the same as parameters of
pointer types. The C standard explicitly recommends that.
> I see your thoughts that a pointer and an array with unknown
> size can be written the same thing but if you use them as a variable
> declarations, the difference will clearly occur. An example:
>
>
> int *pArray;
>
>
> int Array[] = {0, 1, 2, 3, 4};
>
>
> pArray = Array;
>
>
> cout << sizeof(Array) << endl;
>
>
> cout << sizeof(pArray) << endl;
>
>
> The difference of 'sizeof(Array)' and 'sizeof(pArray)' is clear and some
> users could try to do the same in a function declared with a formal
> parameter array with unknown bounds (named 'arg_0'), in which the
> 'sizeof(arg_0)' will not show the size of the actual array but instead of
> it's first element pointer which is not an expected behavior.
Deprecating that Array[] there in declaration will NEVER happen. It would lead
to code like this:
int fibonacci[20] = { 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377,
610, 987, 1597, 2584, 4181 };
for (size_t i = 0; i < sizeof(fibonacci)/sizeof(fibonacci[0]); ++i)
std::cout << "fib(" << i << ") = " << fibonacci[i] << std::endl;
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: sasho648 <sasho648@mail.bg>
Date: Wed, 26 Nov 2014 02:52:56 -0800 (PST)
Raw View
------=_Part_158_1628414084.1416999176419
Content-Type: multipart/alternative;
boundary="----=_Part_159_1223912420.1416999176419"
------=_Part_159_1223912420.1416999176419
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
26 =D0=BD=D0=BE=D0=B5=D0=BC=D0=B2=D1=80=D0=B8 2014, =D1=81=D1=80=D1=8F=D0=
=B4=D0=B0, 05:24:23 UTC+2, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
> That's not what I meant and you know it. We're talking about function
> parameters (it's right there in the subject!) and there these two functio=
ns
> are the same:
>
> void f(int *pArray);
> void f(int pArray[]);=20
=20
I see you work for Intel. You want to keep job, huh?
Have I ever said something else - it is just that some people, including me=
=20
find this implicit conversion for confusing.
You have to go back to early days of C and think "I don't know how to=20
> return=20
> an array". Additionally, since arrays decay to pointers, it's impossible=
=20
> to=20
> know the size of the array that the caller must allocate so that the=20
> callee=20
> can receive it.=20
> Note that you can return an array if it's inside an aggregate:=20
> struct Array { int v[5]; };=20
> Array Func(int *);=20
> Because now the size is known and there's no pointer decay.
Quote from here <http://en.cppreference.com/w/cpp/language/array>:
*Array to pointer decay*
>
> There is an implicit conversion=20
> <http://en.cppreference.com/w/cpp/language/implicit_cast> from lvalues=20
> and rvalues of array type to rvalues of pointer type: it constructs a=20
> pointer to the first element of an array.=20
The arrays to pointer implicit conversion is for lvalues and rvalues of=20
array type. This have nothing to do with variable declarations and memory=
=20
allocation but instead with the variable usage after being declared. The=20
only place where array declarations are magically converted into pointer is=
=20
in function formal parameters.
Deprecating that Array[] there in declaration will NEVER happen. It would=
=20
> lead=20
> to code like this:=20
>
> int fibonacci[20] =3D { 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 3=
77,=20
> 610, 987, 1597, 2584, 4181 };=20
> for (size_t i =3D 0; i < sizeof(fibonacci)/sizeof(fibonacci[0]); ++i)=20
> std::cout << "fib(" << i << ") =3D " << fibonacci[i] << std::endl=
;=20
>
Er, what? I don't see what would lead to? Also what declaration are you=20
talking about because I'm talking about the one as a formal parameter.
--=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_159_1223912420.1416999176419
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div>26 =D0=BD=D0=BE=D0=B5=D0=BC=D0=B2=D1=80=D0=B8 201=
4, =D1=81=D1=80=D1=8F=D0=B4=D0=B0, 05:24:23 UTC+2, Thiago Macieira =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-col=
or: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">That'=
s not what I meant and you know it. We're talking about function<br> parame=
ters (it's right there in the subject!) and there these two functions<br> a=
re the same:<br> <br> void f(int *pArray);<br> &=
nbsp; void f(int pArray[]); </blockquote><div> </=
div><div><br></div><div>I see you work for Intel. You want to keep job, huh=
?<br><br>Have I ever said something else - it is just that some people, inc=
luding me find this implicit conversion for confusing.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">You have to go back to early days of C and thi=
nk "I don't know how to return <br>an array". Additionally, since arra=
ys decay to pointers, it's impossible to <br>know the size of the arra=
y that the caller must allocate so that the callee <br>can receive it.=
<br>Note that you can return an array if it's inside an aggregate:&nb=
sp;<br>struct Array { int v[5]; }; <br>Array Func(int *); <br>Bec=
ause now the size is known and there's no pointer decay.</blockquote><div><=
br></div><div>Quote from <a href=3D"http://en.cppreference.com/w/cpp/langua=
ge/array">here</a>:<br><br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex;"><b>Array to pointer=
decay</b><br><br>There is an <a href=3D"http://en.cppreference.com/w/cpp/l=
anguage/implicit_cast">implicit conversion</a> from lvalues and rvalues of =
array type to rvalues of pointer type: it constructs a pointer to the first=
element of an array. </blockquote><div><br> The arrays to pointe=
r implicit conversion is for lvalues and rvalues of array type. T=
his have nothing to do with variable declarations and memory allocation but=
instead with the variable usage after being declared. The only place where=
array declarations are magically converted into pointer is in function for=
mal parameters.</div></div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-co=
lor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Depr=
ecating that Array[] there in declaration will NEVER happen. It would lead&=
nbsp;<br>to code like this: <br><br>int fibonacci[20] =3D { 1, 1, 2, 3=
, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, <br>  =
; 61=
0, 987, 1597, 2584, 4181 }; <br>for (size_t i =3D 0; i < sizeof(fib=
onacci)/sizeof(<wbr>fibonacci[0]); ++i) <br> &n=
bsp; std::cout << "fib(" << i << ") =3D =
" << fibonacci[i] << std::endl; <br></blockquote><div><br>=
</div><div>Er, what? I don't see what would lead to? Also what declaration =
are you talking about because I'm talking about the one as a formal paramet=
er.</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_159_1223912420.1416999176419--
------=_Part_158_1628414084.1416999176419--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 26 Nov 2014 13:16:52 +0200
Raw View
On 26 November 2014 at 12:52, sasho648 <sasho648@mail.bg> wrote:
> Quote from here:
>
>> Array to pointer decay
>>
>> There is an implicit conversion from lvalues and rvalues of array type to
>> rvalues of pointer type: it constructs a pointer to the first element of an
>> array.
> The arrays to pointer implicit conversion is for lvalues and rvalues of
> array type. This have nothing to do with variable declarations and memory
> allocation but instead with the variable usage after being declared. The
> only place where array declarations are magically converted into pointer is
> in function formal parameters.
Do tell me what this piece of code does:
char foo[42];
char* bar = foo;
--
---
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: David Krauss <potswa@gmail.com>
Date: Wed, 26 Nov 2014 19:18:42 +0800
Raw View
On 2014=E2=80=9311=E2=80=9326, at 7:16 PM, Ville Voutilainen <ville.voutila=
inen@gmail.com> wrote:
> On 26 November 2014 at 12:52, sasho648 <sasho648@mail.bg> wrote:
>> The arrays to pointer implicit conversion is for lvalues and rvalues of
>> array type. This have nothing to do with variable declarations and memor=
y
>> allocation but instead with the variable usage after being declared. The
>> only place where array declarations are magically converted into pointer=
is
>> in function formal parameters.
>=20
> Do tell me what this piece of code does:
>=20
> char foo[42];
> char* bar =3D foo;
He=E2=80=99s right, that=E2=80=99s a conversion but not a magic transformat=
ion.
--=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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 26 Nov 2014 13:20:42 +0200
Raw View
On 26 November 2014 at 13:18, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9311=E2=80=9326, at 7:16 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>
>> On 26 November 2014 at 12:52, sasho648 <sasho648@mail.bg> wrote:
>>> The arrays to pointer implicit conversion is for lvalues and rvalues of
>>> array type. This have nothing to do with variable declarations and memo=
ry
>>> allocation but instead with the variable usage after being declared. Th=
e
>>> only place where array declarations are magically converted into pointe=
r is
>>> in function formal parameters.
>>
>> Do tell me what this piece of code does:
>>
>> char foo[42];
>> char* bar =3D foo;
>
> He=E2=80=99s right, that=E2=80=99s a conversion but not a magic transform=
ation.
Right, these terms like "magic transformation" are not quite familiar
to me, so I can't
know what people are talking about here.
But hey, I can summarize this proposal: it's not-a-defect, feel free
to move on to something
meaningful.
--=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/.
.
Author: sasho648 <sasho648@mail.bg>
Date: Wed, 26 Nov 2014 03:43:49 -0800 (PST)
Raw View
------=_Part_249_1588527004.1417002229046
Content-Type: multipart/alternative;
boundary="----=_Part_250_1099190780.1417002229046"
------=_Part_250_1099190780.1417002229046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
26 =D0=BD=D0=BE=D0=B5=D0=BC=D0=B2=D1=80=D0=B8 2014, =D1=81=D1=80=D1=8F=D0=
=B4=D0=B0, 13:20:43 UTC+2, Ville Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>
> On 26 November 2014 at 13:18, David Krauss <pot...@gmail.com <javascript:=
>>=20
> wrote:=20
> >=20
> > On 2014=E2=80=9311=E2=80=9326, at 7:16 PM, Ville Voutilainen <ville.vo.=
...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> >> On 26 November 2014 at 12:52, sasho648 <sash...@mail.bg <javascript:>>=
=20
> wrote:=20
> >>> The arrays to pointer implicit conversion is for lvalues and rvalues=
=20
> of=20
> >>> array type. This have nothing to do with variable declarations and=20
> memory=20
> >>> allocation but instead with the variable usage after being declared.=
=20
> The=20
> >>> only place where array declarations are magically converted into=20
> pointer is=20
> >>> in function formal parameters.=20
> >>=20
> >> Do tell me what this piece of code does:=20
> >>=20
> >> char foo[42];=20
> >> char* bar =3D foo;=20
> >=20
> > He=E2=80=99s right, that=E2=80=99s a conversion but not a magic transfo=
rmation.=20
>
>
> Right, these terms like "magic transformation" are not quite familiar=20
> to me, so I can't=20
> know what people are talking about here.=20
>
> But hey, I can summarize this proposal: it's not-a-defect, feel free=20
> to move on to something=20
> meaningful.=20
>
I'll tell you what this means - when the parser finds an formal parameter=
=20
of a function declared as an array it will automatically adjust it's type=
=20
to a pointer of it's first element. This is stated in 8.3.5/5:
After determining the type of each parameter, any parameter of type =E2=80=
=9Carray=20
> of T=E2=80=9D or =E2=80=9Cfunction returning T=E2=80=9D is adjusted to be=
=E2=80=9Cpointer to T=E2=80=9D or=20
> =E2=80=9Cpointer to function returning T,=E2=80=9D respectively.
Which means that if a function is declared like:
void Func(int [5]);
it will be immediately transformed to:
void Func(int *);
The code :
char foo[42];=20
char* bar =3D foo;
uses the 'array to pointer decay', as the variable 'foo' is implicitly=20
casted to a pointer. Note that this is a variable cast and the "magic=20
transformation" I'm talking about is an formal parameter declaration=20
automatic type adjustment. There is quite a difference right?
--=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_250_1099190780.1417002229046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>26 =D0=BD=D0=BE=D0=B5=D0=BC=D0=B2=D1=80=D0=B8 2014=
, =D1=81=D1=80=D1=8F=D0=B4=D0=B0, 13:20:43 UTC+2, Ville Voutilainen =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On 26 November 2014 at 13:18, David Krauss <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"gcMzZ7jN-8sJ" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">pot...@gmail.com</a>> wrote:
<br>>
<br>> On 2014=E2=80=9311=E2=80=9326, at 7:16 PM, Ville Voutilainen <<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"gcMzZ7jN-=
8sJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>> wrote:
<br>>
<br>>> On 26 November 2014 at 12:52, sasho648 <<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"gcMzZ7jN-8sJ" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">sash...@mail.bg</a>> wrote:
<br>>>> The arrays to pointer implicit conversion is for lvalues a=
nd rvalues of
<br>>>> array type. This have nothing to do with variable declarat=
ions and memory
<br>>>> allocation but instead with the variable usage after being=
declared. The
<br>>>> only place where array declarations are magically converte=
d into pointer is
<br>>>> in function formal parameters.
<br>>>
<br>>> Do tell me what this piece of code does:
<br>>>
<br>>> char foo[42];
<br>>> char* bar =3D foo;
<br>>
<br>> He=E2=80=99s right, that=E2=80=99s a conversion but not a magic tr=
ansformation.
<br>
<br>
<br>Right, these terms like "magic transformation" are not quite familiar
<br>to me, so I can't
<br>know what people are talking about here.
<br>
<br>But hey, I can summarize this proposal: it's not-a-defect, feel free
<br>to move on to something
<br>meaningful.
<br></blockquote><div><br></div><div><br></div><div>I'll tell you what this=
means - when the parser finds an formal parameter of a function declared a=
s an array it will automatically adjust it's type to a pointer of it's firs=
t element. This is stated in <span style=3D"color: rgb(0, 0, 0); font-=
family: Arial, 'Liberation Sans', 'DejaVu Sans', sans-serif; font-size: 14p=
x; line-height: 17.8048000335693px;">8.3.5/5:</span></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-=
left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: =
solid; padding-left: 1ex;"><span style=3D"color: rgb(0, 0, 0); font-family:=
Arial, 'Liberation Sans', 'DejaVu Sans', sans-serif; font-size: 14px; line=
-height: 17.8048000335693px; background-color: rgb(238, 238, 238);">After d=
etermining the type of each parameter, any parameter of type =E2=80=9Carray=
of T=E2=80=9D or =E2=80=9Cfunction returning T=E2=80=9D is adjusted to be =
=E2=80=9Cpointer to T=E2=80=9D or =E2=80=9Cpointer to function returning T,=
=E2=80=9D respectively.</span></blockquote><div><br></div><div>Which means =
that if a function is declared like:</div><div><br></div><div class=3D"pret=
typrint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wo=
rd; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div=
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Func</=
span><span style=3D"color: #660;" 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"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">]);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></div></code></div><div><br></div><div>it will be i=
mmediately transformed to:</div><div><br></div><div><div class=3D"prettypri=
nt" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; b=
ackground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Func</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*);</span></div></code></div><br><br></div=
><div><br></div><div> The code :</div><div><br></div><div class=3D"pre=
ttyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-w=
ord; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">42</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> <br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> bar </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span></div></code></div><br><div>uses the 'array to pointer d=
ecay', as the variable '<span style=3D"color: rgb(0, 0, 0); font-fami=
ly: monospace; background-color: rgb(250, 250, 250);">foo' is implicitly ca=
sted to a pointer. Note that this is a variable cast and the </span>"m=
agic transformation" I'm talking about is an formal parameter declaration a=
utomatic type adjustment. There is quite a difference right?</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_250_1099190780.1417002229046--
------=_Part_249_1588527004.1417002229046--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 26 Nov 2014 10:50:50 -0800
Raw View
On Wednesday 26 November 2014 02:52:56 sasho648 wrote:
> Deprecating that Array[] there in declaration will NEVER happen. It would
>
> > lead
> > to code like this:
> >
> > int fibonacci[20] = { 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233,
> > 377,
> >
> > 610, 987, 1597, 2584, 4181 };
> >
> > for (size_t i = 0; i < sizeof(fibonacci)/sizeof(fibonacci[0]); ++i)
> >
> > std::cout << "fib(" << i << ") = " << fibonacci[i] << std::endl;
>
> Er, what? I don't see what would lead to? Also what declaration are you
> talking about because I'm talking about the one as a formal parameter.
That's exactly the problem. You missed the off-by-one error when reading the
code.
Anyway, I had interpreted from your email that you wanted to forbid declaring
arrays as:
int array[] = { 1, 2, 3, 4, 5 };
That's never going to happen. If you didn't mean that, then let's move on.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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: Jens Maurer <Jens.Maurer@gmx.net>
Date: Fri, 28 Nov 2014 08:45:45 +0100
Raw View
On 11/27/2014 09:49 PM, sasho648 wrote:
> Let's sum up my proposals:
>=20
> 1st proposal:
>=20
> Changing 8.3.5/5 from this:
>=20
> After determining the type of each parameter, any parameter of type =E2=
=80=9Carray of T=E2=80=9D or =E2=80=9Cfunction returning T=E2=80=9D is adju=
sted to be =E2=80=9Cpointer to T=E2=80=9D or =E2=80=9Cpointer to function r=
eturning T,=E2=80=9D respectively.
>=20
> To something like this
>=20
> Parameters of type =E2=80=9Carray of T=E2=80=9D and =E2=80=9Cfunction ret=
urning T=E2=80=9D are not allowed.
This would be one more point where C++ and C became incompatible.
I'd appreciate getting some information about how widespread the
pattern is in C code (which might be compiled in C++ mode), and
thus how much code would break. Since this appears in function
signatures, even "plain" header files (e.g., for operating system
functions) could be affected.
Jens
--=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/.
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Fri, 28 Nov 2014 21:52:12 +0100
Raw View
On 11/28/2014 08:49 PM, sasho648 wrote:
> @Jens Maurer Compiling existing 'C' code in 'C++' which uses function
> parameters declared as arrays could be done by using the "C" linkage
> construct - "extern"C"". So 8.3.5/5 will look something like this:
> After determining the type of each parameter, any parameter of type
> =E2=80=9Carray of T=E2=80=9D or =E2=80=9Cfunction returning T=E2=80=9D is=
adjusted to be =E2=80=9Cpointer to
> T=E2=80=9D or =E2=80=9Cpointer to function returning T,=E2=80=9D respecti=
vely, only if the
> function is declared to be with 'C' linkage. Otherwise parameters of
> type =E2=80=9Carray of T=E2=80=9D and =E2=80=9Cfunction returning T=E2=80=
=9D are not allowed.
"extern C" currently only has effect on name mangling and calling
convention, but not on the acceptable syntax for declarations, except
where there is an actual conflict (e.g. templates cannot be
"extern C"). It seems odd to allow something in extern "C" blocks
that is prohibited in extern "C++" blocks.
Jens
--=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/.
.
Author: sasho648 <sasho648@mail.bg>
Date: Fri, 28 Nov 2014 13:02:24 -0800 (PST)
Raw View
------=_Part_4524_172477695.1417208544803
Content-Type: multipart/alternative;
boundary="----=_Part_4525_1877180062.1417208544803"
------=_Part_4525_1877180062.1417208544803
Content-Type: text/plain; charset=UTF-8
Then we will not implement this. Actually after reading some articles
<http://stackoverflow.com/questions/1201593/c-subset-of-c-where-not-examples>it
seems that 'C++' never supported old 'C' code fully.
--
---
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_4525_1877180062.1417208544803
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Then we will not implement this. Actually after reading some <a href="http://stackoverflow.com/questions/1201593/c-subset-of-c-where-not-examples">articles </a>it seems that 'C++' never supported old 'C' code fully.</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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_4525_1877180062.1417208544803--
------=_Part_4524_172477695.1417208544803--
.