double pointer

Discussion in 'C++' started by dade, Dec 9, 2005.

  1. dade

    dade Guest

    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
     
    dade, Dec 9, 2005
    #1
    1. Advertising

  2. dade

    Guest

    dade wrote:
    > 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
     
    , Dec 9, 2005
    #2
    1. Advertising

  3. * 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

    --
    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?
     
    Alf P. Steinbach, Dec 9, 2005
    #3
  4. dade

    John Carson Guest

    "dade" <> wrote in message
    news:ZIfmf.28614$
    > 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/


    --
    John Carson
     
    John Carson, Dec 9, 2005
    #4
  5. dade

    dade Guest

    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


    "dade" <> ha scritto nel messaggio
    news:ZIfmf.28614$...
    > 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
    >
     
    dade, Dec 9, 2005
    #5
  6. dade

    red floyd Guest

    dade wrote:
    >
    > 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.
     
    red floyd, Dec 9, 2005
    #6
  7. dade

    Guest

    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
     
    , Dec 9, 2005
    #7
  8. dade

    Guest

    wrote:
    > 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
     
    , Dec 9, 2005
    #8
  9. dade

    dade Guest

    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

    <> ha scritto nel messaggio
    news:...
    >
    > 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
    >
     
    dade, Dec 10, 2005
    #9
  10. dade

    Guest

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

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

    dade wrote:
    > <> ha scritto nel messaggio
    > news:...
    > > 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.
    > >

    > 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
     
    , Dec 10, 2005
    #10
  11. dade

    peter koch Guest

    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
    >
    >
    > "dade" <> ha scritto nel messaggio
    > news:ZIfmf.28614$...
    > > 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
    > >
     
    peter koch, Dec 10, 2005
    #11
  12. dade

    John Carson Guest

    "dade" <> wrote in message
    news:c4jmf.28965$
    > 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.

    --
    John Carson
     
    John Carson, Dec 10, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sydex
    Replies:
    12
    Views:
    6,564
    Victor Bazarov
    Feb 17, 2005
  2. Replies:
    10
    Views:
    717
    Chris Torek
    Feb 4, 2005
  3. jimjim
    Replies:
    16
    Views:
    852
    Jordan Abel
    Mar 28, 2006
  4. asker123
    Replies:
    0
    Views:
    1,321
    asker123
    Jun 27, 2009
  5. Replies:
    4
    Views:
    1,286
    Fred Zwarts
    Jul 2, 2009
Loading...

Share This Page