What's up debu/g/

What's up debu/g/

Why the fuck is C so difficult? Why am I stupid? Can you tell me what the fuck I'm doing wrong?
.h - pastebin.com/uHkidy7K
.c - pastebin.com/rLvFeJz6

>inb4 "learning C in 2019"

Attached: 1548962105176[1].jpg (795x768, 164K)

Closing as INCOMPLETE. Please respect the standard bug report template.

whats wrong? Compiles and runs fine

funny
[spoiler]also funny

Just trying to help dude. What does your compiler say?

map.c(26): error C2109: subscript requires array or pointer type

basically it's not passing the array properly into makeTiles and I'm also sure it's not making an array of pointers but a giant array of structs.

>void makeTiles(pTiles) {
You forgot the type

see what line it says? (26)
you should change the function parameter to "struct Tile *pTiles[]" instead of just "pTiles"

It compiles and runs but with a few warnings

map.c(22): warning C4047: 'function': 'Tile **' differs in levels of indirection from 'Tile *(*)[1200]'
map.c(22): warning C4024: 'makeTiles': different types for formal and actual parameter 1

but warnings aren't errors! thank you

1. Never cast the result of malloc in plain C like this:
struct Map *pMap = (struct Map*)malloc(sizeof(struct Map));
2. In this code:
for (int p = 0; p < numTiles; p++) {
struct Tile *pTile = malloc(sizeof(struct Tile));
pTiles[p] = pTile;
}
Can you explain why you're doing multiple mallocs inside of a loop? You're leaking memory...

I was under the impression that I needed to malloc for each array space if they weren't declared/holding data.

I also wanted the structs to be accessible from anywhere, but that is messing me up as the scope is eating the pointers

he's wrong about the memory being leaked (you assing the pointer to pTiles[p] the line after).

But you should just do one large malloc instead of many small mallocs

That's what I originally had, but I couldn't access the pointers individually(pTiles[24]->whatever), I had to increment the array pTiles->++ to get to the index I wanted.

pTiles+[desired index]

>learning C in 2019
Actually, this is pretty cool of you, OP. I think it's great when people want to unlearn a lot of the things that higher-level languages make you take for granted, and dive into C.

Good luck, buddy.

Isn't it just "pTiles[asd].whatever" then? I'm a sepplesfag so it might be different in C

yea, that made me have to write some sort of controller to reset the index then increment to the one I wanted.

Now I can just call the index I want, it's nice, are there any downsides to allocating many small instances over one giant one?

Locality in memory. Everytime you want to access something it has to be dereferenced (basically loaded from memory). You want stuff to be close in memory so cache can be utilized by the CPU. Since everything is allocated separately there is no guarantee that they are next to each other in memory.

well shit, guess I'll go back to one giant space and figure it out

But if you're just starting to learn C you should just make stuff work instead of focusing on optimizations.

Also every malloc call has a performance cost AND they will all have to be freed seperately on top of that. In order to free an allocated block, every malloc call creates metadata (size, etc.) that gets stored seperately so it uses more memory as well.

void makeTiles(pTiles) {

missing type, should be
void makeTiles(struct Tile *pTiles) {

also learn to properly state the issue

correction, should be
void makeTiles(struct Tile **pTiles) {

There is no point in learning C.
From microcontrollers thru phones and desktops, to supercomputers, everything can and is being programmed in C++.