0

Next semester, I'll be making a game in C (C89 specifically). Coming from higher-level languages such as C#, one of the first things I would do is make a List of Entities (game objects), and every frame, loop through each Entity and run their Update and Draw methods. Converting this ideology to C, my idea was to develop a "List" structure that contains a pointer to an array of void pointers, and making functions to add, get, and remove entries from the list. If an object is added to the List but the array is too small, realloc the array to a twice-as-large array. With this system in place, when I, say, spawn an enemy, I can add a pointer to its Entity struct to the List, and then each frame, loop through the List, cast each void pointer element as a pointer to an Entity, and then pass it to entity_update(Entity *) and entity_draw(Entity *) methods accordingly.

In my mind, as long as I'm 100% sure to only put pointers to Entity structs (cast as void pointers) in the List array, there wouldn't be any problem... but when I mentioned this to a classmate, he said that he thought there were performance drawbacks associated with casting void pointers to pointers to other things. Looking around on the Internet, from what I can tell, the real problem is that compilers can't properly optimize your code as they would if the compiler knew in advance what type the pointer pointed to. Would this end up being a problem in my situation, where I want to loop through a potentially large-ish array of void pointers, sixty times a second? It wouldn't be a huge deal to just store pointers to Entities in an array of Entity pointers, with a large, predefined maximum size, and then do bound checking to make sure i.e. an enemy isn't spawned if there's no room left in the array... but I just wanted to make sure before I started working on the basic underlying engine stuff for the game.

Adam Rezich
  • 3,122
  • 6
  • 31
  • 39
  • Is there some reason why this got posted with a -2 initial score? – Adam Rezich Dec 02 '13 at 20:56
  • 2
    You got hit by 2 people. It's not the initial score. You've made the question overly specific to games though. It'd also help to draft some pseudo code rather than describe your program flow. – InfernalRapture Dec 02 '13 at 20:59
  • It was within 35 seconds of posting it, though! And there's no need for pseudocode in this question as far as I'm concerned, right? The question is, basically, "is casting a whole bunch of void pointers to pointers to other stuff sixty times a second going to be a problem for stable performance in a high performance setting, such as that of a video game," but then I added the second paragraph to bring up the possible concerns that I've already come across and one possible solution. I had no idea that either of those things was worthy of an immediate, blind downvote. – Adam Rezich Dec 02 '13 at 21:04
  • 3
    You don't even need any casting: C can convert `void *` to `struct Entity *` implicitly (unlike object-oriented languages) – anatolyg Dec 02 '13 at 21:14
  • Is that C89 or a more recent addition? I've never heard that before. – Adam Rezich Dec 02 '13 at 21:16
  • @takua108 It's definitely not recent. It's one of the reasons why [you should never cast the return value of `malloc()` (a `void *`) in C](http://stackoverflow.com/a/605858/28169). – unwind Dec 02 '13 at 21:37
  • 1
    @takua108 You're talking to an army of programmers, I would say pseudocoding the loop structure you describe would have been a lot easier for me to read than a wall of text. You can even inline comment your question about where your friend thinks the performance hit is. That whole first Paragraph could be eliminated and replaced by a few lines of pseudocode. – InfernalRapture Dec 02 '13 at 22:06

1 Answers1

5

In C casting a pointer doesn't actually do anything except tell the compiler to treat it as a different type. There's no runtime overhead.

So no.

John Ledbetter
  • 13,557
  • 1
  • 61
  • 80