Array of C-strings

[Anon]

I'm a little confused on how to implement this properly. (Actually this exercise showed me I'm not sure how to do dynamic 2d arrays either in C)

What I'm trying to do is declare a dynamic 2d array of char. So what tried is:
This code, either segfaults or causes windows to assume I have a trojan, depending on luck.

code:

//counters declared at start of code   char** start = malloc(11*sizeof(char));   for (i=0;i<10;i++) {         start[i] = malloc(11*sizeof(char));   }   for (i=0;i<10;i++) {         free(start[i]);   }

My understanding of pointers/arrays in C is that should work, since I'm allocating spaced for 11 ptrs to char, and then allocating space to each of those ptrs for 11 chars.
Could someone point out where I'm going wrong? My guess was that since C allocates arrays as a bunch of sequential memory addresses, it might be the the for loop allocating blocks of memory to each array element that is screwing things up, but if thats the case then I'm obviously going about the whole process wrong.

Also, this is a little off-topic, but I dont think it merits it's own topic, I've noticed that some C-compilers support variable declarations in the middle of a block (inline declarations? I think thats the right term), while others require all variables to be declared at the start. Which is the ANSI standard?

EDIT:

Figured it out not three seconds after posting. Or so I hope. I was allocating space for a char, not a char* in the initial allocation. changing above to:

code:

//counters declared at start of code   char** start = malloc(11*sizeof(char*));   for (i=0;i<10;i++) {         start[i] = malloc(11*sizeof(char));   }   for (i=0;i<10;i++) {         free(start[i]);   }

makes it run. Would still appreciate feedback if this is a correct and safe way to intialize a 2d array

[OneOffDriveByPoster]

Anon @ Thu Feb 21, 2008 11:01 pm wrote:

code:

//counters declared at start of code   char** start = malloc(11*sizeof(char*));   for (i=0;i<10;i++) {         start[i] = malloc(11*sizeof(char));   }   for (i=0;i<10;i++) {         free(start[i]);   }

You are apparently making space for 11 pointers-to-char but only using 10. You can also free _start_ if you are done with it. Set the pointer to NULL after freeing it (just a good idea). Also, sizeof(char) is always 1 in standard C.

[Anon]

Thanks, for the help!
So, factoring your suggestions into my code I get:

code:

//counters declared at start of code   char** start = malloc(10);   for (i=0;i<10;i++) {    start[i] = malloc(11); //need 1 extra here only for null terminator   }   for (i=0;i<10;i++) {    free(start[i]);   } free(start); //free "start" as well start = NULL; //set start to NULL

Is this now safe/correct?

Thanks again for the help!

[md]

if your making strings of length 10, yes.

[OneOffDriveByPoster]

Anon @ Thu Feb 21, 2008 11:58 pm wrote:

code:

char** start = malloc(10);

sizeof(char *) again, can be different from sizeof(char). Anyhow, there is no value proposition to doing what you are doing unless if your arrays do change size. Maybe you should try that out?

[md]

I actually missed that; sizeof(char*) is 4 on most 32bit computers. it isn't however guaranteed to be so.

Using sizeof(char) and sizeof(char*) is always the best thing to do anyways, since it helps show where your numbers are coming from (magic numbers are bad mkay?)

[OneOffDriveByPoster]

md @ Fri Feb 22, 2008 12:00 pm wrote:

(magic numbers are bad mkay?)

I would agree, but 0 and 1 should be somewhat acceptable. AFAIK, writing sizeof(char) in this context is only good for reminding poeple when they change the type that is being allocated.

[Anon]

OneOffDriveByPoster @ Fri Feb 22, 2008 11:14 am wrote:

Anon @ Thu Feb 21, 2008 11:58 pm wrote:

code:

char** start = malloc(10);

sizeof(char *) again, can be different from sizeof(char). Anyhow, there is no value proposition to doing what you are doing unless if your arrays do change size. Maybe you should try that out?

yeah, I noticed that, another stupid mistake on my part.
It seems to me that using these numeric constants is a bad idea in terms of coding style, but it sounds reasonable that chars would be 1 byte on every compiler, so perhaps a preprocessor 'define' would make the code more readable?

code:

#ifndef SIZE_OF_CHAR #define SIZE_OF_CHAR 1 #endif

would that be better style?

Oh, and actually the only reason I'm using dynamic mem, is because I have to have a function return the result of the operations to this array, and in order to stop the variable going out of scope when the function ends, I have to return the address of the pointer. If there is a way to return a statically allocated array without having it go out of scope, I'm all ears. (Also, using 'static' wont work in this case, as I need to have a unique array each time the function is called)

[md]

the size of a character is not always 1; though for any code you write it almost certainly will be. That's the reason you use sizeof(); C++ doesn't guarantee a fixed size, only a minimum size.

[OneOffDriveByPoster]

md @ Sat Feb 23, 2008 6:55 pm wrote:

the size of a character is not always 1

We are talking about C, and sizeof(char) is always 1 or else your compiler is not worth using. The same is true for C++. You may be thinking of a character literal, or wchar_t or something.

[OneOffDriveByPoster]

Anon @ Sat Feb 23, 2008 6:40 pm wrote:

would that be better style?

No, use sizeof if feel that you must.

Quote:

Oh, and actually the only reason I'm using dynamic mem, is because I have to have a function return the result of the operations to this array, and in order to stop the variable going out of scope when the function ends, I have to return the address of the pointer. If there is a way to return a statically allocated array without having it go out of scope, I'm all ears. (Also, using 'static' wont work in this case, as I need to have a unique array each time the function is called)

Consider having the caller pass you the array. You may be able to avoid using dynamic memory that way. Even if you still have to use dynamic memory, at least the caller should know to clean up after itself.

[Anon]

OneOffDriveByPoster @ Sat Feb 23, 2008 10:35 pm wrote:

Anon @ Sat Feb 23, 2008 6:40 pm wrote:

would that be better style?

No, use sizeof if feel that you must.

Quote:

Oh, and actually the only reason I'm using dynamic mem, is because I have to have a function return the result of the operations to this array, and in order to stop the variable going out of scope when the function ends, I have to return the address of the pointer. If there is a way to return a statically allocated array without having it go out of scope, I'm all ears. (Also, using 'static' wont work in this case, as I need to have a unique array each time the function is called)

Consider having the caller pass you the array. You may be able to avoid using dynamic memory that way. Even if you still have to use dynamic memory, at least the caller should know to clean up after itself.

Hmmm... that would work for this case, and save me a lot of hassle. Oh well, I still got to learn a little about dynamically allocated memory

Thanks md and OneOffDriveByPoster!

EDIT:

I was playing around with my program trying to clean it up and stuff when I thought of another way to return a static array: wrap it inside a struct

code:

struct grid{     char grid[MAX][MAX]; //assume MAX is a preprocessor constant }; typedef struct grid grid; //to return this I would go grid some_function();

I got the idea from OOP class wrappers. Would this be appropriate coding style, or is this something I should save for OOP languages?

[md]

that works too; also you can do

C:

typedef struct _grid { ...} grid;

[OneOffDriveByPoster]

Anon @ Sun Feb 24, 2008 11:37 am wrote:

code:

grid some_function();

The primary disadvantage is that you are really copying the array. Note that what you are doing is likely having an automatic array inside the function, and even if it is a static array, you are getting a temporary created (and associated copying) when you return the aggregate from the function. If you are doing assignment after, you copy yet again. If you expect a compiler to optimize this away then let us hope you have one with good Inter-Procedural Analysis. (It is likely that a compiler could take care of the last copy when you are assigning the result directly).

[md]

There's that too... which can be solved with more pointers!

Just return a pointer to a grid; which you can easliy make with malloc(sizeof(grid))