find size of 2D array's row and column

[Talguy]

I am passing a dynamically sized 2D array into a function. How would I be able to tell the row size and column size the array. I know I can do this to find the total number of elements in the array:

foo(const _T ***m_data) {
     int dataSize = sizeof(*m_data)/sizeof(double);
}

[NeoKyrgyz]

If it's dynamically allocated "array" (A pointer to the adress where R pointers a stored, each in terms pointing a beginning of the mermory that holds C number of T typed items), it seems for me that you can't learn it without using some marks (i.e. NULL at the end)

Or Have you tried?
int **array;
...
int row = sizeof(*array)/(sizeof (int *));
int col = sizeof (**array)/(sizeof (int *));

Not sure though, just suggestions.

[Dave Sinkula]

I am passing a dynamically sized 2D array into a function. How would I be able to tell the row size and column size the array.

When you make the request for dynamic allocation, you know the size. Pass that to the function. The information is not present in the pointer.

[NeoKyrgyz]

When you call malloc, it gives you a pointer to the dynamically allocated memory. The first few bytes show how much memory is being allocated so that "free" knows how much space to release. If you are very curious you can try ty play with these bytes in order to find the size of the dynamically allocated memory. (it's in theory, I've not tried it myself :)).

[siddhant3s]

>>Or Have you tried?
He don't have to as your advices are very incorrect.

To the OP:
There is NO WAY you could get the size of an passed array inside a function. Why? Because arrays cannot be passed. The compiler converts the definitions like this:

void f1(int a[])
{
...
}

to this:

void f1(int* a)
{
...
}

So, when you pass an array, you are actually passing a simple pointer. And hence, there is NO WAY you could tell if a pointer is pointing to an array or not.

The only suggestion is to make your function definition like this:

void f1(int a[], int row, int col)
{
...
}

and let the function user pass the rows and columns as the parameter.

[Narue]

>When you call malloc, it gives you a pointer to the dynamically allocated memory.
That's correct! Congratulations.

>The first few bytes show how much memory is being allocated
>so that "free" knows how much space to release.
Bzzt! Wrong. There's nothing stopping implementations from storing the size elsewhere, such as an internal list where you can't access it without specifically asking for an implementation-specific entity:

#include <cstddef>
#include <iostream>
#include <map>

namespace JSW {
    struct __memory_record {
        void *_addr;
        std::size_t _size;

        __memory_record ( void *addr = 0, std::size_t size = 0 )
            : _addr ( addr ), _size ( size )
        {}
    };

    std::map<void*, __memory_record> __mm;

    void *__internal_malloc ( std::size_t size )
    {
        void *p = 0;

        // Magic:
        //   * Allocate size bytes
        //   * Provide generic alignment
        //   * Don't store size in the memory

        return p;
    }

    void __internal_free ( void *p, std::size_t size )
    {
        // Magic:
        //   * Release size bytes starting at p
        //   * Assume a valid pointer (non-null)
    }

    void *malloc ( std::size_t size )
    {
        void *p = __internal_malloc ( size );

        if ( p != 0 )
            __mm[p] = __memory_record ( p, size );

        return p;
    }

    void free ( void *p )
    {
        if ( p != 0 )
            __internal_free ( p, __mm[p]._size );
    }
}

int main()
{
    int *p = (int*)JSW::malloc ( sizeof *p );

    if ( p != 0 ) {
        *p = 12345;
        std::cout<< p <<'\t'<< *p <<'\n';
    }

    JSW::free ( p );
}

>If you are very curious you can try ty play with these bytes
>in order to find the size of the dynamically allocated memory.
You can indeed. This is one way to learn how your implementation works. But when doing so, be aware that what you learn not only applies just to that specific compiler, but also to that specific version of the compiler. Vendors can and often do change the internal workings of the compiler on the assumption that end-users don't break the contract of not mucking about in the private stuff.

>it's in theory, I've not tried it myself
In theory you shouldn't open your mouth unless you know what you're talking about. If you haven't even bothered to try your suggestion, how can you have any confidence in its accuracy?