First Approach
At this moment in time it is actually the way I have it working but at the time of writing this I am thinking about trying out a different method.
This approach does work at the moment and the main advantage of it is that all that needs to be done is that after the definition of the new component you just have to create a global version of the proxy templated with the new component and away you go, you can create instances of your new component based on it's name.
There are a lot of reasons I'm sceptical about this:
- Wow does this seem incredibly hacky!!
- From what I've read in forum posts across the internet static initialisation can cause incredibly hard to track bugs.
- Static initialisation can act differently depending on compiler, meaning this code may not work correctly when compiled on linux( something I'm wanting to do in the near future )
- There will be tons of globals all over the place
- A component will always be available if it's being compiled, unless you remember to remove the global proxy declaration.
So like I said I have literally just thought about trying a different way and here it is:
Second Approach
- The Component Store will need to have a huge function adding proxy objects for all the components in the entire game.
- The Component Store will have to #include every component in the entire game.
- This will cause a slow down at program start up whilst this vector is populated.
- Every time a component is added to the game, the user will have to remember to add it to the list.
Okay that seems like quite a lot of potential drawbacks but If I was to go down the route of the first approach and then come to try and get it to build on Linux or OSX to find it doesn't work then that would require a lot more work. I actually understand how the code works in this second approach as well which is much more valuable than it seems.
Conclusion
Setting myself a deadline of next Tuesday to have the new approach implemented for Components and to have done a blog post about it.
Thanks :)