double pointer

[dade]

Hi,

i have some doubt on passing a double array as argumento to a fuction...

i have a variable like:
float A[50][50];

a function like:
int p(float **B);

main()
{
pippo(A);
}

from the compiler i get this warning :

warning #167: argument of type "float *" is incompatible with parameter of
type "float **"

what's wrong?

i tried also with pippo(&A[0][0]);

same result.

thanks

Davide

 

[Michiel.Salters]

Hi,

i have some doubt on passing a double array as argumen to to a fuction.

Use the STL, makes things a lot easier.

i have a variable like:
float A[50][50];

An array of arrays of floats.

a function like:
int p(float **B);

Which takes a pointer to a pointer to a float

int main()
{
pippo(A);
}

from the compiler i get this warning :

warning #167: argument of type "float *" is incompatible with parameter of
type "float **"

what's wrong?

(Besides p != pippo)

Type is wrong. If you have a function that takes a pointer to X, and
you pass
an array of X, the compiler will pass the address of the first element
of the
array. In this case, there's no solution for X. The compiler could
convert
the array A to a pointer float[50]* (pointer to an array of 50 floats)
but
that's it.

i tried also with pippo(&A[0][0]);

That's the address of the first float in the first array, so again a
float*.

In STL:

#include <vector>
std::vector<std::vector<float> > A(50,50);
int p(std::vector<std::vector<float> > const& B);
int main()
{
return p(A);
}

HTH,
Michiel Salters

 

[Alf P. Steinbach]

* dade:

i have some doubt on passing a double array as argumento to a fuction...

i have a variable like:
float A[50][50];

That's an area of memory containing 50*50 float values.

In passing, don't use all uppercase names except for macros.

a function like:
int p(float **B);

That's a pointer to (possibly the first element of an array of) pointer
to (possibly the first element of an array of) float.

main()

Must have result type 'int'.

{
pippo(A);

Presumably you meant

p( A );

}

Consider:

void f( float x[10][20] ) {}
void g( float x[][20] ) {} // Same as f.
void h( float (*x)[20] ) {} // Same as f.

int main()
{
float x[10][20];

f( x );
g( x );
h( x );
}

Hth.,

- Alf

 

[John Carson]

Hi,

i have some doubt on passing a double array as argumento to a
fuction...
i have a variable like:
float A[50][50];

a function like:
int p(float **B);

main()
{
pippo(A);
}

from the compiler i get this warning :

warning #167: argument of type "float *" is incompatible with
parameter of type "float **"

what's wrong?

i tried also with pippo(&A[0][0]);

same result.

thanks

Davide

Simple. A double pointer and a 2d array are different types.

With a 2d array, the compiler knows how long its rows are. Thus element

A[27][31]

can be found in position 27*50 + 31 because the first 27 rows each have 50
elements in them.

By contrast, with a double pointer the compiler knows nothing about row
lengths, which may be different for different rows. Thus

B[27][31]

works by finding the pointer at index 27, and then using it to find the
float at index 31. In general, there is no reason to expect this to be 27*50
+ 31 places from the first float value.

You have several choices.

1. If you know the row length (i.e., the number of columns) at compile time,
then you can make the function take an array argument, e.g., in the example
given, you would have

int p(float B[][50]);

2. If you don't know the row length at compile time, then you can
dynamically allocate the array using pointers so that the array has the
double pointer structure that the function, as originally defined, expects.

3. Forget about arrays and use vectors.

4. Use Boost multiarray.

http://www.boost.org/libs/multi_array/doc/

 

[dade]

thnaks for explanation:

but passing all the array

like

int p(floatB[][50]) there is no risk to get stack overflow?

another thing:
i like very much using STL and vector in particular but they are pretty slow
and i need to be very fast!

thanks

Davide

 

[red floyd]

another thing:
i like very much using STL and vector in particular but they are pretty slow
and i need to be very fast!

Hoare's Law (also attributed to Knuth): Premature optimization is the
root of all evil.

Use vector first. Profile your code. If it indicates a bottleneck in
vector, then -- AND ONLY THEN -- rewrite to use arrays.

 

[deane_gavin]

dade wrote:

<Please don't top-post. Put your reply below or interleaved with the
message you are responding to>

another thing:
i like very much using STL and vector in particular but they are pretty slow
and i need to be very fast!

You've got that the wrong way round. Who cares how fast your code is if
it doesn't work.

First, *make it work*, using the simplest and most reliable means
available. In this case that means ditching the 2D array and using a
vector of vectors. Until you have got your code working corrently,
don't even think about efficiency. Not for a moment.

Using simple and reliable tools, you will get your code working
encouragingly soon. Then, and *oly* then, you can consider speed.

When considering speed, it is very tempting to think "Now it's working,
I'm sure I can make it faster. Where shall I start". Or "Vector is a
class so must have some access overhead compared to arrays. I'll
convert my code to use arrays."

Stop yourself immediately if you start thinking like that. It's the
wrong approach.

The question to ask yourself is: "Does my code run sufficiently fast
that the end user will be satisfied?". It might not be as fast as you
think you could make it, but if it's *fast enough* now, who cares
whether it could be faster. You got it working sooner than expected by
using robust tools in your code. It's fast enough. Well done. You've
finished early so take the rest of the week off.

Of course, it might be that your program isn't fast enough. If that's
the case, the important point is that it is *much* easier to speed up
clearly written bug-free code than it is to debug messy prematurely
optimised code.

The approach you've taken has two stages:

1. Write prematurely optimised code.
2. Discover it doesn't work and have a hard time fixing it.

The right approach is:

1. Write clean, correct code
2. *If and only if necessary* speed it up (using a profiler to target
the bottlenecks).

The second approach has two advantages. Firstly, you might find you
don't need to do stage 2 at all. Secondly, if you do have to do it,
stage 2 of the second approach is a lot easier than stage 2 of the
first approach.

Gavin Deane

 

[deane_gavin]

The approach you've taken has two stages:

1. Write prematurely optimised code.
2. Discover it doesn't work and have a hard time fixing it.

The right approach is:

1. Write clean, correct code
2. *If and only if necessary* speed it up (using a profiler to target
the bottlenecks).

The second approach has two advantages. Firstly, you might find you
don't need to do stage 2 at all. Secondly, if you do have to do it,
stage 2 of the second approach is a lot easier than stage 2 of the
first approach.

Not to mention that following the first approach might still end up
with code that isn't fast enough for your users. The first approach is
really just equivalent to stage one of the second approach. If you've
prematurly optimised, that means you've guessed where the bottlenecks
are going to be. If your guess turns out to be wrong, then even after
all the headache of getting your code to finally work, you're still
going to have to optimise it to get rid of the actual bottlenecks.

Root of all evil indeed.

Gavin Deane

 

[dade]

i agree with your two rules, but vector were already tried in the past and
they are slow in some conditions (especially with old processor).
but i know they are very useful, in fact i use them (and other stl staffs)
in many other appplciations.

anyway for suggestions.

Davide

 

[deane_gavin]

<You're still top-posting. Please don't. Rearranged>

http://www.parashift.com/c++-faq-lite/how-to-post.html

i agree with your two rules, but vector were already tried in the past and
they are slow in some conditions (especially with old processor).
but i know they are very useful, in fact i use them (and other stl staffs)
in many other appplciations.

You may be doing all this anyway, but just in case ...

If you know how big your vectors need to be, you can use appropiate
constructor, or the resize, reserve or capacity member functions to
help the vectors manage their memory sensibly.

If you make the vector the right size to start with, it will never need
to do another memory allocation.

And pass them by reference rather than by value.

Gavin Deane

 

[peter koch]

dade skrev:

thnaks for explanation:

but passing all the array

like

int p(floatB[][50]) there is no risk to get stack overflow?

another thing:
i like very much using STL and vector in particular but they are pretty slow
and i need to be very fast!

They are? This is not my experience. More likely, you are using them
wrongly - such as by passing them by value which you certainly should
not do.
Also do not measure your code with a nonoptimized build. Lots of code
in the C++ library contains stuff such as inlined functions that add
lots of overhead to your debug executable but disappears in the
optimization phase.

/Peter

thanks

Davide

Hi,

i have some doubt on passing a double array as argumento to a fuction...

i have a variable like:
float A[50][50];

a function like:
int p(float **B);

main()
{
pippo(A);
}

from the compiler i get this warning :

warning #167: argument of type "float *" is incompatible with parameter of
type "float **"

what's wrong?

i tried also with pippo(&A[0][0]);

same result.

thanks

Davide

 

[John Carson]

thnaks for explanation:

but passing all the array

like

int p(floatB[][50]) there is no risk to get stack overflow?

None (unless, say, this is part of an infinite recursive call). The array is
still not being copied. The function is passed a pointer, but of the correct
type.