Archived

This topic is now archived and is closed to further replies.

tobymurray

Naming convention for singleton child with all static members?

Recommended Posts

Howdy all, after just finishing writing my resource management code in which I''ve developed a template system which allows multiple managers for each resource type. Each manager derives from a templated singleton and a templated generic resource manager (using the same type for the templates, that is the resource type) still with me? anyways these suckers have static member functions only and of course need to be used like:
CTextureManager::Initialise();
HTEXTURE h = CTextureManager::GetTexture("filename.bmp");
CTextureManager::ReleaseTexture(h);
CTextureManager::Destroy();
 
anyway the point is I''m after a better naming convention. doing CTextureManager:: seems a little counter intuitive to me. I want the name to denote the fact that the class should only be used in this way. Is there any standard conventions for doing this. (I''m already using T prefix for template classes, eg TSingleton) thanks Toby Gobsmacked - by Toby Murray

Share this post


Link to post
Share on other sites
As far as using a singleton class...
not sure everyone uses them. When I was figuring them out, I asked the teachers at my college, but they didn''t know what I was talking about (now that I think about it, this scares me a little).
Anyway, I''ve never seen a standard way of naming these.
I do this:
CBitmap is a singleton
typedef CBitmap* SBitmap;

I use the SBitmap bitmap = CBitmap::Instance();

I have also seen somthing like this:

typedef CBitmap* G_BITMAP;
#define g_bitmap CBitmap::Instance();

that looks like this

G_BITMAP bmp = g_bitmap;

Let me know if this helps

I think, therfore I am.
I think?

Share this post


Link to post
Share on other sites
The general usefulness of naming conventions is debatable. While it''s a good idea to employ consistent capitalization methods and common names for identical entities across your code (eg iterators in STL, etc), naming conventions that convey type information are suspect and difficult to maintain as the code evolves.

Famous example? Win32''s WPARAM and LPARAM are now the same size (they weren''t always so); what happened? (Hint: Hungarian Notation).

Focus instead on code clarity, commenting liberally, and finally accepting that most developers today have IDEs that convey such information via tooltips (if they don''t - like Emacs users - it''s their own fault/choice).

Share this post


Link to post
Share on other sites