By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,778 Members | 1,890 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,778 IT Pros & Developers. It's quick & easy.

size of passed array

P: n/a
Hi everyone,

I need to build a function to plug it in a program (that I didnt make or
can change) that should be called something like this:
float someFunction(float x[])
{
...

}
the problem is, I cannot use someFunction(float x[], int sizex) so I
cannot know the size of the array.
Is there a way I can calculate the size of the static array from inside
the function e.g. sizeof(x)/sizeof(float) or something similar?

Thank you
V.

--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #1
Share this Question
Share on Google+
29 Replies


P: n/a
Vasileios Zografos wrote:
Hi everyone,

I need to build a function to plug it in a program (that I didnt make or
can change) that should be called something like this:
float someFunction(float x[])
{
...

}
the problem is, I cannot use someFunction(float x[], int sizex) so I
cannot know the size of the array.
Is there a way I can calculate the size of the static array from inside
the function e.g. sizeof(x)/sizeof(float) or something similar?

Thank you
V.
No. This is a good reason not to use arrays, use vectors instead.

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.

You need to read up on arrays and pointers in a good C++ book.

john
Mar 10 '07 #2

P: n/a
Vasileios Zografos wrote:
Hi everyone,

I need to build a function to plug it in a program (that I didnt make or
can change) that should be called something like this:
float someFunction(float x[])
{
...

}
the problem is, I cannot use someFunction(float x[], int sizex) so I
cannot know the size of the array.
Is there a way I can calculate the size of the static array from inside
the function e.g. sizeof(x)/sizeof(float) or something similar?

Thank you
V.
If I understand this right, you have to write a function, which can be
called from various places in someone else's code, and could be called
with different size arrays, but you are not allowed to know what the
size of the array is.

Such a function is impossible to write. Either you have misunderstood
what you are supposed to do, or the person who wrote the other code is a
very poor programmer.

john
Mar 10 '07 #3

P: n/a
John Harrison wrote:
If I understand this right, you have to write a function, which can be
called from various places in someone else's code, and could be called
with different size arrays, but you are not allowed to know what the
size of the array is.

Such a function is impossible to write. Either you have misunderstood
what you are supposed to do, or the person who wrote the other code is a
very poor programmer.

john
Hi John,
yes I think you are probably right. Maybe I misunderstood the
requirements because indeed it sounds impossible. I will check again.
Thank you
V.

--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #4

P: n/a
John Harrison wrote:
If I understand this right, you have to write a function, which can be
called from various places in someone else's code, and could be called
with different size arrays, but you are not allowed to know what the
size of the array is.

Such a function is impossible to write. Either you have misunderstood
what you are supposed to do, or the person who wrote the other code is a
very poor programmer.

john
Hi again,
well the function call from the main program looks like this:
float (*funk)(float [])

What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)

Thank you
V.

--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #5

P: n/a
Vasileios Zografos wrote:
John Harrison wrote:
>If I understand this right, you have to write a function, which can be
called from various places in someone else's code, and could be called
with different size arrays, but you are not allowed to know what the
size of the array is.

Such a function is impossible to write. Either you have misunderstood
what you are supposed to do, or the person who wrote the other code is
a very poor programmer.

john


Hi again,
well the function call from the main program looks like this:
float (*funk)(float [])

What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)

Thank you
V.
No, its a pointer to a float.

It is impossible to pass an array to a function in C or C++. You
*always* pass a pointer to the first element of the array.

If you write this

void func(float[] x)
{
}

the compiler understands it like this

void func(float* x)
{
}

Here's proof

void func(float[] x);

int main()
{
float array[10];
cout << sizeof array << '\n';
func(array);
}

void func(float[] x)
{
cout << sizeof x << '\n';
}

Run this program, the output will be

40
4

The actual numbers might be different on your computer, but the point is
that 'array' really is an array so it's size is 40, but x really is a
pointer, so it's size is 4.

It a bad habit (in my opinion) to use the 'func(float[] x)' notation
because it just consufes beginners into thinking that something is an
array when really it is a pointer.

You really need a good C++ book, to explain the differences and
similarities between arrays and pointers. This is always a confusing
subject for beginners.

john
Mar 10 '07 #6

P: n/a
>
Hi again,
well the function call from the main program looks like this:
float (*funk)(float [])
That isn't a function call. It's a declaration of a function pointer.
The function pointer points a ta function which takes a pointer to float
as it's only argument.
>
What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)
As I said, that isn't a function call, so there is no passed parameter.
>
Thank you
V.
john
Mar 10 '07 #7

P: n/a
John Harrison wrote:
>>
Hi again,
well the function call from the main program looks like this:
float (*funk)(float [])

That isn't a function call. It's a declaration of a function pointer.
The function pointer points a ta function which takes a pointer to float
as it's only argument.
>>
What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)

As I said, that isn't a function call, so there is no passed parameter.
>>
Thank you
V.

john
Hi,
yes its not the function call but I instead pasted the declaration so
people can see what kind of parameters it takes. The actual call is:

(*funk)(psum);

but that wouldn't be very helpful would it? :)
Anyway, yes I know the difference between pass by value of by ref and
the default pass by reference way of passing arrays in C++
The problem is that I need to know how many members are in this float
array and I am not sure how to do that.

So if you see a function declaration like that:
float (*funk)(float [])
and the only info to go with it is:
"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

how can I know what ndim is from INSIDE the function?
Any ideas?

Thanks
V.
--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #8

P: n/a
* John Harrison:
>
It is impossible to pass an array to a function in C or C++. You
*always* pass a pointer to the first element of the array.
In C, but not in C++.

E.g.

void foo( int (&a)[10] ) {}

accepts an array of ten 'int', and nothing else. The array is passed by
reference.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 10 '07 #9

P: n/a
Vasileios Zografos wrote:
John Harrison wrote:
>>>
Hi again,
well the function call from the main program looks like this:
float (*funk)(float [])


That isn't a function call. It's a declaration of a function pointer.
The function pointer points a ta function which takes a pointer to
float as it's only argument.
>>>
What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)


As I said, that isn't a function call, so there is no passed parameter.
>>>
Thank you
V.

john

Hi,
yes its not the function call but I instead pasted the declaration so
people can see what kind of parameters it takes. The actual call is:

(*funk)(psum);

but that wouldn't be very helpful would it? :)
Anyway, yes I know the difference between pass by value of by ref and
the default pass by reference way of passing arrays in C++
The problem is that I need to know how many members are in this float
array and I am not sure how to do that.

So if you see a function declaration like that:
float (*funk)(float [])
and the only info to go with it is:
"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

how can I know what ndim is from INSIDE the function?
Any ideas?
Well I've said it a few times, the answer is you cannot.

john
Mar 10 '07 #10

P: n/a
Alf P. Steinbach wrote:
* John Harrison:
>>
It is impossible to pass an array to a function in C or C++. You
*always* pass a pointer to the first element of the array.


In C, but not in C++.

E.g.

void foo( int (&a)[10] ) {}

accepts an array of ten 'int', and nothing else. The array is passed by
reference.
Yes, it's true, my mistake. But not a possibility that's helpful to the
OP I think.

john
Mar 10 '07 #11

P: n/a
John Harrison wrote:
Vasileios Zografos wrote:
>John Harrison wrote:
>>>>
Hi again,
well the function call from the main program looks like this:
float (*funk)(float [])

That isn't a function call. It's a declaration of a function pointer.
The function pointer points a ta function which takes a pointer to
float as it's only argument.
What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)

As I said, that isn't a function call, so there is no passed parameter.
Thank you
V.
john


Hi,
yes its not the function call but I instead pasted the declaration so
people can see what kind of parameters it takes. The actual call is:

(*funk)(psum);

but that wouldn't be very helpful would it? :)
Anyway, yes I know the difference between pass by value of by ref and
the default pass by reference way of passing arrays in C++
The problem is that I need to know how many members are in this float
array and I am not sure how to do that.

So if you see a function declaration like that:
float (*funk)(float [])
and the only info to go with it is:
"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

how can I know what ndim is from INSIDE the function?
Any ideas?


Well I've said it a few times, the answer is you cannot.

john
In fact the comment

"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

makes me think of Pascal. Are you sure this program hasn't been (badly)
ported from Pascal? In Pascal you would be able to get the size of the
vector from inside the function.

john
Mar 10 '07 #12

P: n/a
John Harrison wrote:
John Harrison wrote:
>Vasileios Zografos wrote:
>>John Harrison wrote:

>
Hi again,
well the function call from the main program looks like this:
>
>
float (*funk)(float [])

That isn't a function call. It's a declaration of a function
pointer. The function pointer points a ta function which takes a
pointer to float as it's only argument.

>
What is the passed parameter? An array of float right? If not, what
exactly is it? Help :)

As I said, that isn't a function call, so there is no passed parameter.

>
Thank you
V.
>

john
Hi,
yes its not the function call but I instead pasted the declaration so
people can see what kind of parameters it takes. The actual call is:

(*funk)(psum);

but that wouldn't be very helpful would it? :)
Anyway, yes I know the difference between pass by value of by ref and
the default pass by reference way of passing arrays in C++
The problem is that I need to know how many members are in this float
array and I am not sure how to do that.

So if you see a function declaration like that:
float (*funk)(float [])
and the only info to go with it is:
"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

how can I know what ndim is from INSIDE the function?
Any ideas?


Well I've said it a few times, the answer is you cannot.

john

In fact the comment

"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

makes me think of Pascal. Are you sure this program hasn't been (badly)
ported from Pascal? In Pascal you would be able to get the size of the
vector from inside the function.

john
hehe :) I am not that dumb...honestly
In case you are wondering the code snippet is from Numerical recipes in
C. Its the simplex optimisation code.
Yes ok I CAN actually change the function to call "func" in a different
way, but i want to know why they programmed the code like that. And its
NOT pseudocode.
Ok so its C not C++ but I think the question can be answered in this
newsgroup

--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #13

P: n/a
>
hehe :) I am not that dumb...honestly
In case you are wondering the code snippet is from Numerical recipes in
C. Its the simplex optimisation code.
Yes ok I CAN actually change the function to call "func" in a different
way, but i want to know why they programmed the code like that. And its
NOT pseudocode.
Ok so its C not C++ but I think the question can be answered in this
newsgroup
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.

john
Mar 10 '07 #14

P: n/a
John Harrison wrote:
>>
hehe :) I am not that dumb...honestly
In case you are wondering the code snippet is from Numerical recipes
in C. Its the simplex optimisation code.
Yes ok I CAN actually change the function to call "func" in a
different way, but i want to know why they programmed the code like
that. And its NOT pseudocode.
Ok so its C not C++ but I think the question can be answered in this
newsgroup

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.

john
Yes I guess so. Probably my only choice is to change the function calls
and declarations.
Ok John (and the rest of the people) thanks for going through the
trouble of checking the code. I appreciate it.

V.

--
Posted via a free Usenet account from http://www.teranews.com

Mar 10 '07 #15

P: n/a
Vasileios Zografos wrote:
John Harrison wrote:
>>
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.

john


Yes I guess so. Probably my only choice is to change the function calls
and declarations.
Ok John (and the rest of the people) thanks for going through the
trouble of checking the code. I appreciate it.
When you do, use std::vector rather than adding the size as a parameter.

--
Ian Collins.
Mar 10 '07 #16

P: n/a
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. A pointer definition (float *x) can have its value changed,
whereas an array definition (float x[]) cannot change its base location.
Of course, you could define your pointer as a constant pointer (float
* const x). But if you are passing an array, then don't hide it as a
pointer, use the array syntax.

Really though, if you are passing an array either:

1. don't, use a container class such as vector
2. pass the bounds of the first element as a separate variable
3. pass a pointer to the array and use a template function. Be warned
though, using a template can cause extra code bloat (a new function
is emitted for each different size array pointer passed). Also the
extra dereference may also add extra overhead, though I think that
should be optimised out. Here is an example.
template <int SIZE>
int f(int (*a)[SIZE])
{
int element0 = (*a)[0];
return SIZE;
}

int a[10];
int b[20];
cout << f(&a) << endl; // prints 10
cout << f(&b) << endl; // prints 20
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/
================================================== ========
Mar 12 '07 #17

P: n/a
Vasileios Zografos wrote:
John Harrison wrote:
>John Harrison wrote:
>>Vasileios Zografos wrote:

John Harrison wrote:

>>
>Hi again,
>well the function call from the main program looks like this:
>>
>>
>float (*funk)(float [])
>
>
>
That isn't a function call. It's a declaration of a function
pointer. The function pointer points a ta function which takes a
pointer to float as it's only argument.
>
>>
>What is the passed parameter? An array of float right? If not,
>what exactly is it? Help :)
>
>
>
As I said, that isn't a function call, so there is no passed
parameter.
>
>>
>Thank you
>V.
>>
>
john
Hi,
yes its not the function call but I instead pasted the declaration
so people can see what kind of parameters it takes. The actual call
is:

(*funk)(psum);

but that wouldn't be very helpful would it? :)
Anyway, yes I know the difference between pass by value of by ref
and the default pass by reference way of passing arrays in C++
The problem is that I need to know how many members are in this
float array and I am not sure how to do that.

So if you see a function declaration like that:
float (*funk)(float [])
and the only info to go with it is:
"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

how can I know what ndim is from INSIDE the function?
Any ideas?
Well I've said it a few times, the answer is you cannot.

john

In fact the comment

"the function funk(x) where x[1..ndim] is a vector in ndim dimensions"

makes me think of Pascal. Are you sure this program hasn't been
(badly) ported from Pascal? In Pascal you would be able to get the
size of the vector from inside the function.

john
hehe :) I am not that dumb...honestly
In case you are wondering the code snippet is from Numerical recipes in
C. Its the simplex optimisation code.
Yes ok I CAN actually change the function to call "func" in a different
way, but i want to know why they programmed the code like that. And its
NOT pseudocode.
Ok so its C not C++ but I think the question can be answered in this
newsgroup
The only way is to define the array with a termination value, such as 0
or other constant. Then you can read the array sequentially and if it
does not match, the element can be processed, otherwise you have reached
the end or the array.
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/
================================================== ========
Mar 12 '07 #18

P: n/a
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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.
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.

Comeau online compiles the code with no errors.

void foo1(float* x)
{
float f = 0.0f;
x = &f;
}

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

int main()
{
float array[10] = {0.0f};
foo1(array);
foo2(array);

float a_float = 0.0f;
foo1(&a_float);
foo2(&a_float);
}

Also, the following does not compile due to a redefinition error. If
float* x and float x[] were different types in the argument list, this
should be acceptable as two distinct overloads of foo. But it isn't.

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

Gavin Deane

Mar 12 '07 #19

P: n/a
Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
>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.
>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.

Try this:

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

void bar(float[] x)
{
++x; // compilation error
float element1 = *x;
}

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

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.
Also, the following does not compile due to a redefinition error. If
float* x and float x[] were different types in the argument list, this
should be acceptable as two distinct overloads of foo. But it isn't.

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!

http://www.cplusplus.com/articles/siavoshkc1.html
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/
================================================== ========
Mar 12 '07 #20

P: n/a
John Harrison wrote:
>>
hehe :) I am not that dumb...honestly
In case you are wondering the code snippet is from Numerical recipes
in C. Its the simplex optimisation code.
Yes ok I CAN actually change the function to call "func" in a
different way, but i want to know why they programmed the code like
that. And its NOT pseudocode.
Ok so its C not C++ but I think the question can be answered in this
newsgroup

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/
================================================== ========
Mar 12 '07 #21

P: n/a
* Adrian Hawryluk:
Gavin Deane wrote:
>On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
>>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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 12 '07 #22

P: n/a
On 12 Mar, 21:58, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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.

<snip>
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

Mar 12 '07 #23

P: n/a
On Mar 13, 10:58 am, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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.
Mar 12 '07 #24

P: n/a
Alf P. Steinbach wrote:
* Adrian Hawryluk:
>Gavin Deane wrote:
>>On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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/
================================================== ========
Mar 12 '07 #25

P: n/a
Gavin Deane wrote:
On 12 Mar, 21:58, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
>Gavin Deane wrote:
>>On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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.
>
>{
++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?
Ok, it does work.
> float element1 = *x;

}

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

}

No disagreement there.

<snip>
>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.
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/
================================================== ========
Mar 12 '07 #26

P: n/a
Adrian Hawryluk wrote:
Alf P. Steinbach wrote:
>* Adrian Hawryluk:
>>Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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.
>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.
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/
================================================== ========
Mar 12 '07 #27

P: n/a
Old Wolf wrote:
On Mar 13, 10:58 am, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
>Gavin Deane wrote:
>>On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
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/wg...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/
================================================== ========
Mar 12 '07 #28

P: n/a
Adrian Hawryluk wrote:
Adrian Hawryluk wrote:
>Alf P. Steinbach wrote:
>>* Adrian Hawryluk:
Gavin Deane wrote:
On 12 Mar, 18:48, Adrian Hawryluk <adrian.hawryluk-at-
gmail....@nospam.comwrote:
>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.
>>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.

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/
================================================== ========
Mar 13 '07 #29

P: n/a
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.
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/
================================================== ========
Mar 13 '07 #30

This discussion thread is closed

Replies have been disabled for this discussion.