Function pointers

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Function pointers

      One thing that really throws me for a loop is function pointers. On page 313 regarding the event callbacks, it says "The problem is that the c++ compiler needs to know the type of the function pointer, which defeats our purposes". What does this mean? Is it the return type or the arguments?
      Macoy Madson-http://www.augames.f11.us/
    • RE: Function pointers

      It's actually both; the function type is it's entire signature. For example:

      Source Code

      1. int IntFunc(int left, int right);
      2. float FloatFunc(int left, int right);
      3. int OneParam(int left);


      All three of these functions are considered different types. This gets even trickier in C++:

      Source Code

      1. class A
      2. {
      3. int Func(int val);
      4. };
      5. class B
      6. {
      7. int Func(int val);
      8. };


      These two functions are also effectively different types because they come from different classes. When dealing with class function pointers, you need to know which object it's called on as well as the type of the object.

      If you're interested in learning the nitty-gritty details of C++ function pointers, I highly recommend Don Clugston's article on The Code Project. I used his fastdelegates lib in the GCC's event system. You can find it here:
      codeproject.com/Articles/7150/…-and-the-Fastest-Possible

      -Rez
    • Yep. There's another post going around asking about why you'd want to use a scripting language. This is perfect example of how much easier something is in a scripting language where functions are first-class objects. On the current Sims title I'm working on, we use Python as our gameplay language. Our event system looks something like this:

      Python Source Code

      1. class EventManager:
      2. def __init__(self):
      3. self._event_callbacks = {}
      4. def register_for_event(self, event_type, callback):
      5. event_callback_map = self._event_callbacks.get(event_type)
      6. if not event_callback_map:
      7. event_callback_map = {}
      8. self._event_callbacks[event_type] = event_callback_map
      9. handle_id = generate_handle() # generates a 64-bit GUID
      10. event_callback_map[handle_id] = callback
      11. return handle_id
      12. def unregister_for_event(self, handle):
      13. assert handle.event_type in self._event_callbacks, "Attempt to remove a listener with an invalid handle!"
      14. event_callback_map = self._event_callbacks[handle.event_type]
      15. del event_callback_map[handle.handle_id]
      16. def process_event(self, event_type):
      17. if not event_type in self._event_callbacks:
      18. return
      19. for listener in self._event_callbacks[event_type].values():
      20. callback(event_type)
      Display All


      That's only 25 lines of code and has pretty much all of the functionality of the GCC system except for deferred processing, which would be trivial to add. The callback parameter is just a function that takes in the event type as the single parameter, but this could just as easily take in an additional parameter that serves as a dictionary of key/value pairs. The function could be a member function of an existing object, which is perfectly legal in Python and totally transparent.

      -Rez
    • You're right, thats super nice. The only problem I have with scripting languages is my programmer ego. I try to implement everything I possibly can myself :). I think I will break down and merely implement a very simple scripting language of my own as a beneficial learning experience, then use the well tested popular languages for my primary projects. I don't know, I've never really learned what to do in that situation. This ego was probably what got me into C++ instead of the "everyone can make games in minutes!" tool I was using , but I don't regret it in that case at all.
      Macoy Madson-http://www.augames.f11.us/
    • Yeah, I know that feeling of wanting to implement everything yourself. It's generally a bad habit in the professional world though because you end up reinventing or rewriting things that already work just fine in the game. This leads to bugs and other issues. It's usually easier to rewrite a chunk of code than it is to decipher it, but it's rarely the right thing to do.

      For me, that feeling went away when I started to specialize. I would much rather use an off-the-shelf language like Lua or a 3rd party lib like tinyxml rather than roll my own. Writing that kind of code is tedious and boring for me and I'd rather spend my time actually working on the interesting problems, like character AI.

      I totally support writing a scripting language as a learning experience though. You learn a HUGE amount. I implemented a significant chunk of the STL early on when I was first learning just to force myself to learn about data structures and algorithms. I used it on a couple of personal projects top flush out some bugs, then ditched it and used the STL. Just don't let it be a bottleneck.

      -Rez
    • I'm not saying this is better than using Lua or some comparable scripting language (almost implying it's worse...), but if you really wanted to use C++ for things that would normally be in scripting, you could put all of that logic inside of DLLs somewhere. This would allow you to reload it at run-time, load on demand certain character's DLLs, etc. As a trade off, you'd be repeatedly crossing the DLL boundary, and you'd have to set up all the exports and everything else just like for your scripting language integration.

      Of course since I've been working with Unity lately, I have to say that I love using C#/Mono as the game play language. The Unity implementation of Coroutines (which function like Processes in GCC) is just so wonderful and quick. The equivalent could certainly be done in C++ but you'd spend 4x as long writing and maintaining the code.

      Just my two cents,
      James
    • I am having alot of trouble getting into Unity or UDK, Our first game project will use either flash, SDL, or HTML Canvas so I am alright for now, our final game project will use a 3D engine, likely Unity or UDK.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz