Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422587

Of Policies and Design Problems...

Sign in to follow this  

78 views

This is kinda related to the resouce manager work I've been doing, in that templates and policies are very much on my mind right now, however this is inspired by this thread in the OpenGL forum right now.

A while back now JavaCoolDude wrote a GUI for use with OpenGL, and the world rejoiced. It wasn't perfect but as OGL lacks D3DX like GUIs it was something. Since then JavaCoolDude has landed and job and hasn't done any work on it, however he gave away the code so that others can work on it and they have done so.

Which brings us to the above thread;
I've mostly skimmed it, but one thing jumpped out at me; a 'CUSTOM' flag, which apprently lets you change the image loader.

Now, this is a good thing, in an off its self, but having done my work with templates and having started re-reading Modern C++ Design I can't help but think policies would have been a better way to go, for most of the library and probably many other C++ libraries as well.

The problem I've found with alot of libs is they force you to do things their way;
Take JCD's GUI for example, its a fine GUI however it mandates that you use its custom texture class for texture objects and a custom tuple class for passing things around, which in a small example app is fine, but what if I want to drop this lib into my code? I've probably already got a texture class and maybe even a tuple class (or I'm using Boost's), what do I do?

Well, I could rip the code to bits and rebuild it for my class, but this is messy and takes time.
I could replace my classes with the GUI's ones, but again same problem.
I could use the Bridge Pattern and write a class to interface between the two, which does the classic 'solve the problem with another layer of abstraction' thing but does add extra complexity to the system.
It might even be possible to hack something together with inhertiance, but this could be needlessly complex and coupling.

And its not just JCD's GUI which does this, any C++ library where there are interfaces often defines its own set of classes to do its own thing, making intergration a pain and customisation a nightmare.

This is why I'm giving such thought to how this resource manager is designed, because I don't want to have the same "use my classes!!" thing going on, I want it to be pretty quick for the end user to drop into their app with their classes, the only enforcement being that it contains a certain interface so that it is usable from the manager.

Of course, example classes will be provided, because I work in OGL you can pretty much count on the final code using OGL texture with a GTL backend, but the point is you wont HAVE to use that, you'll just be able to adjust the class at compile time to use your own things.

In closing, if you are a C++ programmer I suggest you check out Modern C++ Design if you haven't already, it'll really open your eyes some (however, if you've not touched templates before now I suggest you read a good book on the first, I recommed C++ Templates - The Complete Guide, its more than you'll ever need to know [wink]).
Sign in to follow this  


2 Comments


Recommended Comments

I'm interested in implementing a more robust GUI than the shit pile that I've hacked together, though I'm not interested in having to rewrap my textures.

Maybe I'll have to write a more robust GUI myself for my OpenGL/SDL standard games library; it's starting to get pretty bulky already what with all the game code I'm starting to roll into it (filesystem management, string tokenizing).

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now