Making 2D array with malloc()

so I'm trying out some used in malloc and generally understand how to use it for 1d arrays, but having trouble with 2d arrays.

So I just want to to create a 2d array with all 1's. Would also be great to differentiate the first array from the second. I.e. first array has 3 second has 10;

Thanks!!

Code:

#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;

int main()
{
    int ** test;
    int size = 3;
    test = (int**) malloc (size*sizeof(int));

    for(int o = 0; o<size; o++)
    {
        for(int i=0;i<size;i++)
        {
            test[o][i] = 1;
            cout << test[o][i];
        }
    }
    return 0;
}

Think of it as "an array of arrays". Space has to be allocated and freed for the outer one as well as all of the inner arrays.

There's a couple ways to do it. See the first couple of examples here.

If you're writing C++, shouldn't you be using new? If you still want to use malloc, you should be including cstdlib. And try to avoid using o as a variable name; too easily mistaken for a 0.

Originally Posted by oogabooga

There's a couple ways to do it. See the first couple of examples here.

I'm getting an error:

Code:

C:\Documents and Settings\Jon\My Documents\2d malloc\main.cpp||In function 'int main()':|
C:\Documents and Settings\Jon\My Documents\2d malloc\main.cpp|11|error: invalid conversion from 'void*' to 'int**'|
C:\Documents and Settings\Jon\My Documents\2d malloc\main.cpp|13|error: invalid conversion from 'void*' to 'int*'|
||=== Build finished: 2 errors, 0 warnings ===|

here is the code:

Code:

#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;

int main()
{
    int i, o, ncolumns = 2, nrows = 3;

	int** test = malloc(nrows * sizeof(int*));
	for(i = 0; i < 2; i++)
		test[i] = malloc(ncolumns * sizeof(int));


    for(o = 0; o<nrows; o++)
    {
        for( i=0;i<ncolumns;i++)
        {
            test[o][i] = 1;
            cout << test[o][i];
        }
    }
    return 0;
}

Originally Posted by rags_to_riches

If you're writing C++, shouldn't you be using new? If you still want to use malloc, you should be including cstdlib. And try to avoid using o as a variable name; too easily mistaken for a 0.

Is there any advantage? I'm thinking I might want to use malloc() bc CUDA uses it.

Malloc returns a void pointer. In C, this is automagically compatible with any type. In C++, you have to cast it to type:

Code:

int** test = (int**)malloc(nrows * sizeof(int*));

Is there any advantage?

In this case, not particularly, but in general it is a bad habit to use malloc/free in C++ because new/delete deal with objects (constructors and destructors) properly whereas the C functions do not.

very nice, it works but is a bit funky

if i put this code, it exits with -1073741819 (0xC0000005)

Code:

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main()
{
    int i, o, ncolumns = 2, nrows = 3;

    int** test = (int**)malloc(nrows * sizeof(int*));
	for(i = 0; i < 2; i++)
		test[i] = (int*)malloc(ncolumns * sizeof(int));


    for(o = 0; o<=nrows; o++)
    {
        for( i=0;i<=ncolumns;i++)
        {
            test[o][i] = 1;
            cout << test[o][i];
        }
    }

    return 0;
}

but if i put this, it just completely errors...

Code:

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main()
{
    int i, o, ncolumns = 2, nrows = 3;

    int** test = (int**)malloc(nrows * sizeof(int*));
	for(i = 0; i < 2; i++)
		test[i] = (int*)malloc(ncolumns * sizeof(int));


    for(o = 0; o<=nrows-1; o++)
    {
        for( i=0;i<=ncolumns-1;i++)
        {
            test[o][i] = 1;
            cout << test[o][i];
        }
    }

    return 0;
}

What gives? I don't think it has anything to do with free() i put it on and made no difference

This is wrong:

Code:

for(i = 0; i < 2; i++)
    test[i] = (int*)malloc(ncolumns * sizeof(int));

The magic number 2 should have been nrows.

This is poor style:

Code:

for(o = 0; o<=nrows-1; o++)
{
    for( i=0;i<=ncolumns-1;i++)
    {
        test[o][i] = 1;
        cout << test[o][i];
    }
}

I suggest:

Code:

for (int i = 0; i < nrows; ++i)
{
    for (int j = 0; j < ncolumns; ++j)
    {
        test[i][j] = 1;
        cout << test[i][j];
    }
}

Using r and c instead of i and j respectively also makes sense, but more importantly, notice the use of < instead of <= when the array index starts from 0. Also, notice that I declared the variables near first use.

Oh, and you really should free what you malloc.

Originally Posted by oogabooga

There's a couple ways to do it. See the first couple of examples here.

Ugh, that's an annoying FAQ entry:

You can keep the array's contents contiguous, at the cost of making later reallocation of individual rows more difficult, with a bit of explicit pointer arithmetic:

The implication is simply allocating a chunk of memory then indexing it is somehow less elegant than an array of pointers.. With some FUD about some mythical need to reallocate individual rows and the scary term "explicit pointer arithmetic."

Allocating an array of pointers and then allocating the rows and managing all that just so you can have the [row][col] notation is just... totally pointless. Especially in C++ where you can easily abstract this away into a multi-dimensional iterator

Originally Posted by brewbuck

The implication is simply allocating a chunk of memory then indexing it is somehow less elegant than an array of pointers.. With some FUD about some mythical need to reallocate individual rows and the scary term "explicit pointer arithmetic."

I think you're reading FUD into a statement where there is none I don't see an implication that the method is less elegant. I think that needing to reallocate individual rows is a possibility that cannot always be dismissed (even if we're not talking about a "jagged" array of arrays), I don't see what's so scary about "explicit pointer arithmetic" compared to the scary "multi-dimensional iterator"

What I don't like is that the statement points out a potential cost without pointing out the definite benefit of a fixed number of allocations, but maybe that benefit is just plain obvious.