size of passed array

[Adrian Hawryluk]

OK, I looked at the code, what can I say except that it appears to be
poor code. I guess they just forgot that you might need the size of the
array.

Doh!

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Alf P. Steinbach]

* Adrian Hawryluk:

John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form because it
doesn't try to pretend that x is an array when it isn't.
Sorry, you are wrong, x can decompose into a pointer, but it is _not_ a
pointer.

Yes it is.

No it isn't.

Hey, Adrian, stop.

As a function argument, "float x[]" and "float* x", as well as e.g.
"float x[10]", are exactly equivalent.

There are some other such type collapses. E.g., as a function argument
"void foo()" and "void (*foo)()" are exactly equivalent. And as a
function argument, "int const x" and "int x" are nearly equivalent: the
top level "const" affects what can be done with the argument in the
function's body, but it doesn't affect the function signature.


[snip]

void foo2(float x[])
{
float f = 0.0f;
x = &f;
}

_If_ that does work, it cannot be portable to all compilers, and I would
deem it as a compiler bug.

It is indeed standard C++ (and also standard C).

Try this:

void foo(float *x)
{
++x;
float element1 = *x;
}

void bar(float[] x)

Java'ism: syntax error.

 

[Gavin Deane]

John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer,

Yes it is.

No it isn't.

For the avoidance of doubt, I am talking about the formal parameter x
inside someFunction. There is no code you can write *inside*
someFunction that can depend on whether the calling function passed an
actual pointer or an array name that decayed to a pointer to its first
element.

A pointer definition (float *x) can have its value changed,
whereas an array definition (float x[]) cannot change its base location.

I'm not sure what you mean here. Are you suggesting that some part of
the following code should not compile? Or that the behaviour of some
part of it is undefined? Or have I misunderstood you? In both foo1 and
foo2, x is a (non-const) pointer to (non-const) float.
[snip]

void foo2(float x[])
{
float f = 0.0f;
x = &f;
}

_If_ that does work, it cannot be portable to all compilers, and I would
deem it as a compiler bug.

It's fully portable to all conforming C++ compilers.

Try this:

void foo(float *x)
{
++x;
float element1 = *x;

}

void bar(float[] x)

The above is a syntax error. Did you mean float x[] ?

{
++x; // compilation error

Assuming the above change to the syntax, this compiles fine with
Comeau online, as I would expect it to. What compiler are you using?

float element1 = *x;

}

void zozo(float * const x)
{
++x; // different compilation error
float element1 = *x;

}

No disagreement there.

http://www.cplusplus.com/articles/siavoshkc1.html

That article says nothing about "passing arrays" to functions, the
subject of this discussion. It just discusses some differences between
an array and a pointer being used within the same function as they are
declared.

Gavin Deane

 

[Old Wolf]

John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form because it
doesn't try to pretend that x is an array when it isn't.
Sorry, you are wrong, x can decompose into a pointer, but it is _not_ a
pointer.

Yes it is.

No it isn't.

Please get a clue before engaging in this sort of argument.

void foo2(float x[])
{
float f = 0.0f;
x = &f;
}

_If_ that does work, it cannot be portable to all compilers, and I would
deem it as a compiler bug.

Can you show us even one compiler that does not have this supposed
bug?

void bar(float[] x)
{
++x; // compilation error

The compilation error is due to (float[] x) which is a syntax error.

Unless you can point to a _specific_ location in the C++ spec that
states unequivocally that a float[] is *the same as* and not *equivalent
to* a float *, then forget it. If it don't quack like a duck in /all/
respects, then it ain't a duck.

8.3.5 Functions [func.dcl]
#3 ... After determining the type of each parameter, any parameter
of type "array of T" or "function returning T" is adjusted to be
"pointer to T" or "pointer to function returning T,"
respectively.

void foo(float* x) {}
void foo(float x[]) {}

No, this is an ambiguous overload, not the same thing. Some compilers
may allow it to look the same for added simplicity, but it is *not* the
same!
LOL


http://www.cplusplus.com/articles/siavoshkc1.html

That link has nothing to do with this topic.

For further enlightenment, please read:
http://c-faq.com/aryptr/aryptrparam.html

The C89 rules on this topic are the same as the C++ ones, so you would
do well to read the rest of chapter 6.

 

[Adrian Hawryluk]

* Adrian Hawryluk:

On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
(e-mail address removed)> wrote:
John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form because it
doesn't try to pretend that x is an array when it isn't.
Sorry, you are wrong, x can decompose into a pointer, but it is _not_ a
pointer.

Yes it is.

No it isn't.

Hey, Adrian, stop.

What, ya gonna call ya mama on me?

As a function argument, "float x[]" and "float* x", as well as e.g.
"float x[10]", are exactly equivalent.

Equivalence should not be interpreted as being the same, it should be
interpreted as being equivalent (a fine distinction, but one just the
same). And in fact, you cannot use them interchangeably as I have
shown, so they are not even that.

There are some other such type collapses. E.g., as a function argument
"void foo()" and "void (*foo)()" are exactly equivalent.

Your definition of 'exactly' must be a very interesting one to have.
"void foo()" and "void (*foo)()" are not the same. Try assigning a
function with the same signature to the former and see what you get.
You can use one in place of the other, but not the other in place of the
one.

And as a
function argument, "int const x" and "int x" are nearly equivalent: the
top level "const" affects what can be done with the argument in the
function's body, but it doesn't affect the function signature.

The keyword here is /nearly/. Having a /nearly/ equivalent function
signature will generate an ambiguity in the compiler which it will not
be able to resolve, but this does not come even close to proving that
they are the /same/. Here is a (non-rigorous) proof by contradiction:

Assume A is the same a B
f(A) == f(B)
f(A) doesn't make sense
thus A != B

[snip]

void foo2(float x[])
{
float f = 0.0f;
x = &f;
}

_If_ that does work, it cannot be portable to all compilers, and I
would deem it as a compiler bug.

It is indeed standard C++ (and also standard C).

Show me the spec that says it is.

Try this:

void foo(float *x)
{
++x;
float element1 = *x;
}

void bar(float[] x)

Java'ism: syntax error.

What does that supposed to mean? That syntax came waaaaaaaaaay before
Java was ever around. I was there!


Adrian

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Adrian Hawryluk]

On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
(e-mail address removed)> wrote:
John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer,
Yes it is.

No it isn't.

For the avoidance of doubt, I am talking about the formal parameter x
inside someFunction. There is no code you can write *inside*
someFunction that can depend on whether the calling function passed an
actual pointer or an array name that decayed to a pointer to its first
element.

It is indeed a decayed type.

void foo2(float x[])
{
float f = 0.0f;
x = &f;
}

_If_ that does work, it cannot be portable to all compilers, and I would
deem it as a compiler bug.

It's fully portable to all conforming C++ compilers.

Try this:

void foo(float *x)
{
++x;
float element1 = *x;

}

void bar(float[] x)

The above is a syntax error. Did you mean float x[] ?

Oops, sorry, yes.

Assuming the above change to the syntax, this compiles fine with
Comeau online, as I would expect it to. What compiler are you using?

Ok, it does work.

No disagreement there.



That article says nothing about "passing arrays" to functions, the
subject of this discussion. It just discusses some differences between
an array and a pointer being used within the same function as they are
declared.

You are right, I am wrong in the case of arrays are /exactly/ the same
as a pointer. My mistake.


Adrian


--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Adrian Hawryluk]

* Adrian Hawryluk:

Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
(e-mail address removed)> wrote:
John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form because it
doesn't try to pretend that x is an array when it isn't.
Sorry, you are wrong, x can decompose into a pointer, but it is
_not_ a
pointer.

You are right John.

Your definition of 'exactly' must be a very interesting one to have.
"void foo()" and "void (*foo)()" are not the same. Try assigning a
function with the same signature to the former and see what you get. You
can use one in place of the other, but not the other in place of the one.

I still hold my ground on that though Alf.

[snip]


Adrian

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Adrian Hawryluk]

On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
(e-mail address removed)> wrote:
John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form because it
doesn't try to pretend that x is an array when it isn't.
Sorry, you are wrong, x can decompose into a pointer, but it is _not_ a
pointer.
Yes it is.

No it isn't.

Please get a clue before engaging in this sort of argument.

Whatever Old, you never learn if you don't make some mistakes.

For further enlightenment, please read:
http://c-faq.com/aryptr/aryptrparam.html

Thanks for the link.

The C89 rules on this topic are the same as the C++ ones, so you would
do well to read the rest of chapter 6.

I only have this one:
http://www.open-std.org/jtc1/sc22/wg21/docs/wp/html/oct97/

Do you have a more recent one?


Adrian

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Adrian Hawryluk]

* Adrian Hawryluk:
Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
(e-mail address removed)> wrote:
John Harrison wrote:
BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form
because it
doesn't try to pretend that x is an array when it isn't.
Sorry, you are wrong, x can decompose into a pointer, but it is
_not_ a
pointer.

You are right John.

Your definition of 'exactly' must be a very interesting one to have.
"void foo()" and "void (*foo)()" are not the same. Try assigning a
function with the same signature to the former and see what you get.
You can use one in place of the other, but not the other in place of
the one.

I still hold my ground on that though Alf.

But I am again wrong. I didn't see 'as a function argument'.


Adrian

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================

 

[Adrian Hawryluk]

BTW in 'float someFunction(float x[])' x is *not* an array, it is a
pointer, it is exactly the same as if you had written 'float
someFunction(float* x)'. You should prefer the second form because it
doesn't try to pretend that x is an array when it isn't.

I think that this is stylistic, and John shouldn't try and force saying
that one representation is better than the other. I personally would
say that using 'float someFunction(float x[])' is better because it
describes the /intent/ of what is being passed, an array. 'float
someFunction(float* x)' however describes an intent of passing only one
value, unless backup with documentation.

However, using only one parameter showing the intent of passing an array
had better be backed up with either a terminator value element or a size
parameter.

If the size is immutable, then perhaps an array reference as Alf
described would be in order, i.e. ('float someFunction(float (&x)[20])'.

If it can take many different sizes, then a template may be good,
depending on how many you are considering.

The original question, which turned out to be a function pointer that
took a float array as a parameter, was determined to be stylistically
just bad though, since no terminator value was specified and it was not
anchored to any particular number of elements.

Any comments?


Adrian

--
==========================================================
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
==========================================================