|
Programming C, bash, Python, Perl, PHP, Java, you name it. |
|
Thread Tools | Display Modes |
|
|
|||
Pointer to structs, C
Im getting an error when compiling my little "roguelike" attempt game
Code:
gcc -o rogue -lncurses *.c maps.c: In function 'worldgen': maps.c:131: error: incompatible type for argument 1 of 'regiongen' *** Error code 1 Code:
typedef struct s_region { long width; long height; char *mapname; char **data; } region; typedef struct s_worldmap { long width; long height; char *mapname; char **data; //The characters of the map. //Region structs. region **wregions; //a w*h array of regions } worldmap; Code:
int worldgen(worldmap *wm, int height, int width, int mtype) { .... wm = (worldmap *)malloc( sizeof(worldmap) ); wm->wregions = (region **) malloc(wm->height * sizeof(region *)); //REGIONS for(i = 0; i < height; i++) { wm->wregions[i] = (region *) malloc(wm->width * sizeof(region)); } regiongen(wm->wregions[y][x], wm->height, wm->width, wm->data[y][x]); regiongen's prototype int regiongen(region *rm, int height, int width, char maptype); my question is, is the argument, wm->wregions[y][x] not a pointer to struct? Last edited by ocicat; 12th September 2011 at 06:18 AM. Reason: Using [code] & [/code] tags makes life simpler on your readers... |
|
|||
No, wregions[y] is a region*.
data and wregions are the same (**), but declared differently in regiongen. I would regard wregions as a one-dimensional array of pointers. If you need to look at it as a two-dimensional array you will have to apply some math to the indexing. |
|
|||
Quote:
Last edited by ocicat; 12th September 2011 at 07:28 AM. |
|
|||
Hey everyone thanks for the response. Situation resolved by using address of
regiongen(&wm->wregions[y][x], wm->height, wm->width, wm->data[y][x]); Now, im writing all of my regions to file, the file gets to about 2.7 megabytes and the program crashes(in the middle of writing a region).... some kinda overflow? what is it? Ive tried fputc, and fputs... hmmm. |
|
|||
Quote:
|
|
|||
Thanks ocicat!
Code here http://www.cooperlabs.net/dfroguelike.tar.gz I have managed to work around the save crash by having it create 40 "region files" when saving the world instead of one giant save file. The program now works up to the character generator, and only crashes now in macosx (works fine in bsd) dont laugh at my code, i consider myself and "enthusiastic novice at C" Edit: (gdb on macosx) Code:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00007fff6076d300 0x00007fff80c8ec00 in strlen () Last edited by ocicat; 23rd September 2011 at 02:02 PM. Reason: Screen output is easier to read by using [code] & [/code] tags. |
|
|||
Quote:
I haven't looked at your code yet (maybe this weekend if it is relatively small...), but is there a reason why you are creating such an elaborate structure based on pointers, calls to malloc(), etc.? Why not pre-allocate a fixed size array at compilation time? There can be valid reasons for allocating everything from the heap, but you take on deciphering the structure as a result. |
|
|||
Quote:
|
|
|||
Have you run it against valgrind? What is the output?
|
|
|||
Hey thanks guys. I am trying valgrind now.
I also fixed the broken link on my code. IS it possible to have pointers to structs within pointers to structs within pointers to structs etc??? I am trying to do this which has a compile error. Code:
//gr->mtiles[y][x]->rcTiles.w = gr->tilew; //gr->mtiles[y][x]->rcTiles.h = gr->tileh; inside gr is mtiles, a pointer to struct Tile inside Tile is rcTiles a pointer to struct SDL_Rect (which as members w and h) mtiles is an array created with malloc like so: Code:
gr->mtiles = (Tile **) malloc(sizeof(Tile *)); //malloc new Tile struct for(i = 0; i < MAPSIZE; i++) //malloc new Tile sturct { gr->mtiles[i] = (Tile *) malloc(MAPSIZE * sizeof(Tile)); gr->mtiles[i]->rcTiles = (SDL_Rect *) malloc(sizeof(SDL_Rect)); } Last edited by ocicat; 24th March 2012 at 05:10 AM. Reason: Use [code]/[/code] tags to make code more readable. |
|
|||
Quote:
The answer is still "yes". Quote:
The solution is to break the problem down into smaller portions, & debug them one at a time. This is the secret of writing large applications -- break it down into more managable subsystems, & test, test, test. Decomposition is cool. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
OpenBSD OpenBSD Reliability Fix: kernel NULL pointer dereference in getsockopt() | J65nko | News | 0 | 28th October 2009 11:56 PM |
c++: writing to the *this pointer? | robbak | Programming | 2 | 23rd October 2009 06:12 PM |