Archived

This topic is now archived and is closed to further replies.

earl3982

dynamic multidimensional arrays in c...

Recommended Posts

Identical, except you''ll be using malloc() and free() instead of new and delete. Read the docs on those functions.



Don''t listen to me. I''ve had too much coffee.

Share this post


Link to post
Share on other sites
I suppose you could code your own clas... oh, only C? I meant you could code your own structure *wink wink* that functions as a dynamic array. Implementation isn''t hard. all you have to do is allocate the memory dynamical through class methods and overload the [] operator, but if you want multidimentional array support, I don''t know how you can accomodate for consecutive [] opreators (like array[10][5]). You might have to code a Get(...) function for that. Details are up to you.

Share this post


Link to post
Share on other sites
Zipster, c structures cant have member functions. there is no operator overload or any fancy features of c++. most ppl compile code using a c++ compiler which treats all code as c++ (ie vc++) thus never actual see the restrictions of c.

allocating a multi dimensioanl array is easy, just search the forums for plenty of example code or both types (planar and linear).

Share this post


Link to post
Share on other sites
quote:
Original post by a person
Zipster, c structures cant have member functions. there is no operator overload or any fancy features of c++. most ppl compile code using a c++ compiler which treats all code as c++ (ie vc++) thus never actual see the restrictions of c.

allocating a multi dimensioanl array is easy, just search the forums for plenty of example code or both types (planar and linear).


A C structure can have a function pointer member, however, a function has to be assigned to it before it can be called.



int foo(int i, int j)
{
return i*j;
}

typedef int (*foo_t)(int,int);

typedef struct tagMyStruct {
int x;
int y;
foo_t foofunc;
} MyStruct;

MyStruct mine;
mine.foofunc = foo;
// do stuff like assign values to mine.x and mine.y
int z = mine.foo(mine.x, mine.y);



As for the multidimensional arrays - the secret words are "pointer pointers"

Share this post


Link to post
Share on other sites
how about


  
int width = something;
int height = something;
int x;
int y;
int* array = malloc(sizeof(int)*width*height);
for(y=0;y<height;y++) {
for(x=0;x<width;x++) {
array[x+width*y] = something(x,y);
}
}


and, as a useful struct:


  
typedef struct {
int* data;
int width;
int height;
} array2d;

void set(array2d array,int x,int y,int data) {
if(x<0||x>array.width) return;
if(y<0||y>array.height) return;
array.data[x+array.width*y] = data;
}

int get(array2d array,int x,int y,int* data) {
if(x<0||x>array.width) return -1;
if(y<0||y>array.height) return -1;
*data = array.data[x+array.width*y];
return 0;
}

/*or*/
int get_withouterror(array2d array,int x,int y) {
if(x<0||x>array.width) return 0;
if(y<0||y>array.height) return 0;
return array.data[x+array.width*y];
}


this is fully with errorchecks, if you don''t want them, you can remove them, but its unsave then..

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
quote:
Original post by Zipster
Thank God I started programming after C++ came around, C sounds like it blowed! Heh


Um, yeah, that''s why it''s used to write os kernels and device drivers...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I used to write device drivers for Windows in C++.
The Symbian OS for palm is written in C++.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
I used to write device drivers for Windows in C++.
The Symbian OS for palm is written in C++.


Yes and BeOS was also written in C++. But *nix is written in C. The Windows kernels are all written in C. Quake and Quake 2 were written in C too. The thing is, for a C++ programmer to bag on C is like baggin'' on your parents. You might think it''s cool at the time, but later on you realize how foolish it was and what an ass it made you look like because the whole while you were really baggin'' on yourself. C++ != OOP - it just makes OOP in C easier.

Share this post


Link to post
Share on other sites
quote:
Original post by LessBread
[quote]Original post by Anonymous Poster
I used to write device drivers for Windows in C++.
The Symbian OS for palm is written in C++.


Yes and BeOS was also written in C++. But *nix is written in C. The Windows kernels are all written in C. Quake and Quake 2 were written in C too. The thing is, for a C++ programmer to bag on C is like baggin'' on your parents. You might think it''s cool at the time, but later on you realize how foolish it was and what an ass it made you look like because the whole while you were really baggin'' on yourself. C++ != OOP - it just makes OOP in C easier.

Good call LessBread! Hear, Hear!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hey! I wasn''t baggin'' on C, I am coding in C at the moment for the PS1.
C programmers who moan about C++ yet provide no arguments in their favour is what gets my goat.

Share this post


Link to post
Share on other sites
umm, no. function pointers may seem like member functions but they are in no way the same thing.

struct foo
{
int a, b, c;
}bar;

int setA(struct foo *bar, int newA)
{
int oldA=bar->a;
bar->a = newA;
return oldA;
}

that is similar to how member functions are handled in C. when you create a vtable with function pointers then you are creating what would be similar to virtual function constructs.

in either case you have to call the function as a normal C function passing the struct to the function (in c++ this is implicit and done for you by the compiler).

in any case the "member" function you showed will not affect the struct at all since you are not passing the struct to the function. there is no magically way for the compiler to know what struct you are accessing since a c compiler does not deal with member functions at all. no implicit passing of the struct occers.

in short its not the same as member functions in c++, it may be similar, but you have to pass the struct anyway. thus you have a group of functions that can operate on the struct, but the compiler cant know which struct to operate on unless you pass it. in c++ this happens automagically since it understands structs with member functions and knows which struct gets passed to the member function implicitly.

davepermen, thats nice, but the code is quite slow. its easier (and much faster) to deal with the array directly.

c does have some awful restrictions. the worst one i hate is the "all varibles MUST be declared at the start of a code block before ANY code".

what many ppl fail to realize is that the fundamental differences between c and c++ are there. most happen to use c++ compilers and think they are coding in c. they are not. if you use a c++ compiler the code is treated as c++. no matter how strict you stick to the c standard, a c++ compiler treats it as c++ code. sure the code is very procedural and does not use c++ features like objects, but it dont matter. stylisticly its c code, but that dont mean a thing to a c++ compiler.

its also silly to think that c++ just makes OOP easier in c. this is not true. c and c++ are two different langauges with two different standards and boards. sure they are similar and most c code will compile using a c++ compiler with a few tweaks (ie c++ has stricter type checking).

c code tends to be at a slightly lower level since there are no objects to deal with and thus its more of a "what you code is what you get" vs the compiler deciding to inline things, make certain funcitons accessed pointers vs standard c functions. there are implicit parm passing with ALL member functions that are not static. many ppl that complain about c++ actually use c++ compilers so they are being even more ignorent then they realize. c code can be faster, or cause certain practices that lead to more optimized code generation (ie no STL which may do more then you want). you have some slight control over code generation since its procedural code. sure you could code procdural in c++, and get the benefits of c style coding. personally i maintain a stlight c style coding even though i use a c++ compiler.

a c++ coder has ever right to complain about c. there ares ome bad restrictions (again the "all varibles must be declared at the start of a code block") that can make some code harder to read.

Share this post


Link to post
Share on other sites
umm, no. function pointers may seem like member functions but they are in no way the same thing.

struct foo
{
int a, b, c;
}bar;

int setA(struct foo *bar, int newA)
{
int oldA=bar->a;
bar->a = newA;
return oldA;
}

that is similar to how member functions are handled in C. when you create a vtable with function pointers then you are creating what would be similar to virtual function constructs.

in either case you have to call the function as a normal C function passing the struct to the function (in c++ this is implicit and done for you by the compiler).

in any case the "member" function you showed will not affect the struct at all since you are not passing the struct to the function. there is no magically way for the compiler to know what struct you are accessing since a c compiler does not deal with member functions at all. no implicit passing of the struct occers.

in short its not the same as member functions in c++, it may be similar, but you have to pass the struct anyway. thus you have a group of functions that can operate on the struct, but the compiler cant know which struct to operate on unless you pass it. in c++ this happens automagically since it understands structs with member functions and knows which struct gets passed to the member function implicitly.

davepermen, thats nice, but the code is quite slow. its easier (and much faster) to deal with the array directly.

c does have some awful restrictions. the worst one i hate is the "all varibles MUST be declared at the start of a code block before ANY code".

what many ppl fail to realize is that the fundamental differences between c and c++ are there. most happen to use c++ compilers and think they are coding in c. they are not. if you use a c++ compiler the code is treated as c++. no matter how strict you stick to the c standard, a c++ compiler treats it as c++ code. sure the code is very procedural and does not use c++ features like objects, but it dont matter. stylisticly its c code, but that dont mean a thing to a c++ compiler.

its also silly to think that c++ just makes OOP easier in c. this is not true. c and c++ are two different langauges with two different standards and boards. sure they are similar and most c code will compile using a c++ compiler with a few tweaks (ie c++ has stricter type checking).

c code tends to be at a slightly lower level since there are no objects to deal with and thus its more of a "what you code is what you get" vs the compiler deciding to inline things, make certain funcitons accessed pointers vs standard c functions. there are implicit parm passing with ALL member functions that are not static. many ppl that complain about c++ actually use c++ compilers so they are being even more ignorent then they realize. c code can be faster, or cause certain practices that lead to more optimized code generation (ie no STL which may do more then you want). you have some slight control over code generation since its procedural code. sure you could code procdural in c++, and get the benefits of c style coding. personally i maintain a stlight c style coding even though i use a c++ compiler.

a c++ coder has ever right to complain about c. there ares ome bad restrictions (again the "all varibles must be declared at the start of a code block") that can make some code harder to read. though i think complaining about either is silly. use the right tool for the job. just like the d3d vs opengl debate, its a religous war. i perfer to use what works for me, though i feel it required to correct ppl who use c++ compilers and think those constructs work with a c compiler.

Share this post


Link to post
Share on other sites
i wanted to provide a save way, not a fast way. to speed this up is very simple, and, well, if c would know inlines it would get as fast as directly bar written (as i use to do this anyways)

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
quote:
Original post by a person
that is similar to how member functions are handled in C. when you create a vtable with function pointers then you are creating what would be similar to virtual function constructs.


Yes. I almost wrote that function pointers in structs were similar to virtual functions. My point was to suggest an approach that was similar to member functions, but not to say that there was such a thing in C.

quote:
Original post by a person
c does have some awful restrictions. the worst one i hate is the "all varibles MUST be declared at the start of a code block before ANY code".


That is no longer true. The C99 spec put an end to that restriction. It also introduced inlined functions and C++ style comments.

quote:
Original post by a person
its also silly to think that c++ just makes OOP easier in c. this is not true. c and c++ are two different langauges with two different standards and boards. sure they are similar and most c code will compile using a c++ compiler with a few tweaks (ie c++ has stricter type checking).

Yes the two languages are different languages, but not fundamentally different. I wrote the remark off the cuff and the word "just" should be read as "merely" not "only". Stroustrup is addressing the issues between the two languages this summer - check out cuj.com. His articles make an interesting read.


quote:
Original post by a person
a c++ coder has ever right to complain about c. there ares ome bad restrictions (again the "all varibles must be declared at the start of a code block") that can make some code harder to read.

And some people have cause to complain about their parents too. I think you give a good treatment of some of the misunderstandings that C++ coders have in regards to C though.

Share this post


Link to post
Share on other sites
I read somewhere that if you use the ".c" file extension instead of ".cpp", the compiler will switch to some C-only mode. It sounds like BS, but I can''t be sure of these things.

And please don''t think I don''t know the difference between C and C++ and how the compile treats the code and what I''m actually using. I just always thought that structures had member functions as part of C standard, due it part to a lot of the discussion on these very boards. Just about every week there''s a topic on "Structs v.s Classes" and it''s always the same response, "structures = classes except for default access". I don''t recall ever reading about the "but only in C++" clause. I do remember a few heated debates where people argued over the member function aspect, but neither side would clarify whether they were assuming in C or C++.

Share this post


Link to post
Share on other sites
quote:

in short its not the same as member functions in c++, it may be similar, but you have to pass the struct anyway. thus you have a group of functions that can operate on the struct, but the compiler cant know which struct to operate on unless you pass it. in c++ this happens automagically since it understands structs with member functions and knows which struct gets passed to the member function implicitly.



Either way can be used to implement OOP. It''s not as if implicit passing is faster or anything (if anything, it might slow you down when you don''t need to operate on your class -- unless the compiler is smart enough to remove that. Plus: No weird name mangling in C

---
Bart

Share this post


Link to post
Share on other sites
quote:
Original post by Zipster
I read somewhere that if you use the ".c" file extension instead of ".cpp", the compiler will switch to some C-only mode. It sounds like BS, but I can''t be sure of these things.

Test it! Try to instance a class or a template in a file with a .c extension and see what happens. Then you''ll know with certainty.

quote:
Original post by Zipster
I just always thought that structures had member functions as part of C standard, due it part to a lot of the discussion on these very boards. Just about every week there''s a topic on "Structs v.s Classes" and it''s always the same response, "structures = classes except for default access". I don''t recall ever reading about the "but only in C++" clause. I do remember a few heated debates where people argued over the member function aspect, but neither side would clarify whether they were assuming in C or C++.


Just because C++ wasn''t expressly stipulated, doesn''t mean that it wasn''t assumed as the default language. It might be that what you''ve picked up from these discussions regarding structures only applies to C++.

Share this post


Link to post
Share on other sites
quote:
Original post by davepermen
i wanted to provide a save way, not a fast way. to speed this up is very simple, and, well, if c would know inlines it would get as fast as directly bar written (as i use to do this anyways)

C has supported inline functions since 1999, but not all compilers support inline functions for C.

Share this post


Link to post
Share on other sites
looks like i am slightly outdated on the c standard, heh.

trzy: in c++, you can use static member functions and remove implicit passing for functions you dont need the struct to do the work you need.

a compiler cant optimize parms away since at anytime you may use them or the memory that they reserve.

Share this post


Link to post
Share on other sites
Well... off the top of my head, I would do something like this:

      
typedef char byte;

#include <stdlib.h>

#include <memory.h>

byte** allocArray(int xDim, int yDim)
{
int i;

byte** array2D;
byte* buf;

buf = malloc(xDim * yDim + (xDim*sizeof(byte*)));
array2D = (byte**)buf;

for(i=0; i<xDim; i++)
array2D[i] = &buf[i*yDim + (xDim*sizeof(byte*))];

#ifndef NDEBUG
memset(&array2D[0][0], 0xcd, xDim*yDim);
#endif
return array2D;
}

void freeArray(byte*** array)
{
free((void*)(*array));
#ifndef NDEBUG
*array = 0;
#endif
}

int main()
{
int i, j;
byte** myarray = allocArray(10, 12);
for(i=0; i<10; i++)
for(j=0; j<12; j++)
myarray[i][j]= 1;
freeArray(&myarray);
return 0;
}



edit: include bug...

[edited by - Magmai Kai Holmlor on July 30, 2002 12:28:52 AM]

Share this post


Link to post
Share on other sites