c programming is hard

so for my game i figured i would need a function to put an thing in a certain position, i wanted to allow for multiple things at the same position so my get would need to return a list of things wait what there's no lists in C i'm stuck

programming is hard let's smoke a joint

Return a struct or a pointer to an array.

Don't return anything, mutate the globally-accessible world state.

>>2

Return a linked list of structs.

You wouldn't be able to use a simple get. You would just look through all the objects and find all objects that match that coordinate. You should probably find an efficient algorithm and data structure for this could it sounds like it could be costly.

Otherwise you could describe your world as a matrix and in each position you can have a link list, but this sounds incredibly space inefficient. First idea is probably better.

Implement a list you stupid piece of shit.


typedef enum _ObjectType {
  Ship,
  Asteroid,
  Alien,
  Sun
} ObjectType;

typedef struct _Object {
  int x, y;
  ObjectType type;
} Object;

typedef struct _node node;

struct _node {
  node *next;
  Object *obj
};

node* prepend(node *oldhead, Object *obj){
  node *n;

  /* how does i linked list lol xdd */

  return n;
}

node *ObjectsAtPoint(node *GlobalObjectList, int x, int y){
  node *head;
  node *globcurr;

  for(globcurr=GlobalObjectList; globcurr; globcurr=globcurr->next){
    if(globcurr->obj->x == x && globcurr->obj->y == y){
      head = prepend(head, globcurr->obj);
    }
  }

  return head;
}

>>3
Define a struct for every function in the program and declare exactly one global instance of those. Then you can add members for input arguments and return values. Add mutexes to each and the whole application is thread-safe!

>>1
Arrays are lists. If you think that C doesn't have arrays then you haven't searched well enough.

just use a modern language like C# you mental midget

it's like you're trying to cross the Atlantic by swimming just because you think boats are for pussies

<--- dubs check 'em

>>10
im trying to become an expert programmer bro :(

could i solve the problem ny having a function such as:

int get( coords, &result) {}

so, you'd return the number of results and make result point to the first result... then i can just use ptr arithmetic to loop over all the results?

perhaps i sjould go and read some more code.

>>12

Seriously, use a linked list rather than a dynamic array.

Then you can just do result = get(coörds); instead of maintaining a count or using an explicit null entry at the end of an array.

>>10
back to /g/ faggot

Okay, you seem knowledgeable... I'll take your advice and go with linked lists[1]. For now, that would mean I would use two linked lists: the first one would maintain a mapping between coord -> entitylist and the second would be a list of entities. I could replace the first one later on with more time-efficient structure (octrees spring to mind though I've never used them). This would mean I expose the following API:


struct entity_list {
  struct entity_list * next;
  entity * ent;
};

void put(coords, *entity);
struct entity_list* get(coords);
int move(coords, new_coords, *entity);

Now for the real question, we do we use a "coord" type (is it a struct?) instead of two (u)ints?

[1] http://cslibrary.stanford.edu/103/

The one and only benefit to using C++ over C is the STL.  My style has evolved to basically writing C code using a C++ compiler just so I can say std::list<entity> at times like these.  The rest of C++ is a pile of unnecessary, useless, cumbersome shit.

>>8
Thread-safe components don't make a thread safe program. The number of pitfalls is actually staggering.

Also OP the good practices say a function should never free memory that was not reserved by it, so consider having the callees allocate and after free it, and later on optimize it with switchable heap buffers and never use malloc/calloc.

>>15
you access the fields of a structure using the character '.':
coord_symbol.a_field = expr_of_a_field_type;
if you, instead have a pointer to a structure type then you can use them with the characters '->':
coord_ptr_symbol->a_field = expr_of_a_field_type;
so:
coord_ptr_symbol->a_field = (*coord_symbol).a_field

>>16
I agree, I also only use C++ when I need lots of concurrency mechanisms and collections.

Okay so I created some (working) code last night.

For the sake of simplicity, I dropped the "multiple entities in a single location" requirement. We will just store a pointer to the entity and can implement multiple entities in the same position later on using a simple linked list.

My code right now looks a bit like this:

#define COMPASS_NW 1
#define COMPASS_NE 2
#define COMPASS_SE 3
#define COMPASS_SW 4

struct map {
    struct grid_node * root;
}

struct grid_node {
  void * entity;
  int posy;
  int posx;
  struct grid_node * children[4];
};

So basically a pointed quad tree [1], I guess. But now there's no way to guarantee that the tree will be balanced. The degenerate case looks quite bad. So I started looking for a different scheme and came up with the following:

struct map {
    struct grid_node * root;
}

struct grid_node {
    void * children[4];
}

Then, we'd create a tree in which every entity is stored at the same depth (log(size of map), or the number of bits in a coordinate). To find the grid_node where we need to store the pointer, we keep popping up bits of posy and posx and use those bits to determine which of the children we need to follow (= a few shift and ANDs). The only drawback I can spot is that we'll need to dereference at least 8 pointers to get to the entities, but if we can make that fast I think it should be OK.

So, /prog/, what you think? I go with pointed quad trees or the other structure I just described?

[1] http://en.wikipedia.org/wiki/Quad_tree#Point_quadtree

bampu pantsu