Jump to content
  • Advertisement
Sign in to follow this  
hellraiser

Naming a class

This topic is 4004 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, I've created a class that encapsulates functionalities that concern text output (in OGL) but, out of lack of creativity, the only name I could come up with was GText, which, as you can see, has nothing to do with "text output." Crappy me... So I thought that maybe I could ask the creative minds on gamedev.net to come up with suggestions to a name for my class? The only rule is it must start with "G". Fire away!

Share this post


Link to post
Share on other sites
Advertisement
My vote goes with TextRenderer. I see no reason why the class should be prefixed with G, the letter doesnt imply OpenGL and if you want to indicate the class belongs to a library then use a proper namespace.

Share this post


Link to post
Share on other sites
//! OpenGL-related utility classes
namespace GLUtil {

//! Display-related utilities
namespace Display {

//! A bit of text shown on the screen
class Text;

//! A cache for data shared between text objects
class TextCache;
}
}

Share this post


Link to post
Share on other sites
Definitely I'm going to go for CTextRenderer and I'm going to follow your recommendations and drop the G. You're absolutely right, the way forward is to encapsulate the classes within namespaces. The only reason I went for the prefix 'G' instead of 'C' was to give the classes a stand outish meaning, one in the lines of 'GSomething', a graphics related class. I suppose I'm better off sticking to the standards... thanks for pointing that out to me.

Now, allow me to expose yet another question, which concerns how to best make my set of text renderer and font classes work in a multi-threaded environment. First off, here's the hierarchy I've come up with:

class CFreeType		// wrapper class for the FreeType library, is accessed by CManagerFonts
class CManagerFonts // creates and removes fonts, holds the currently active font,
// and encapsulates font data
class CTextRenderer // does text rendering only and (constly) accesses CManagerFonts


Font data is contained in CManagerFonts in:

struct FONT_NODE
{
BYTE _height; // height of the font
BYTE* _pWidths; // array containing widths for each char of the font
GLuint *_pTex; // array texture's ids
GLuint _listId; // first display list id
};



An instance of CManagerFonts and CTextRenderer always exists at all times, while CManagerFonts manages when to instantiate/destroy CFreeType to suit its needs.

Also, a handle is returned every time a font is created, which is then passed into a method in CManagerFonts to make it the current one. This handle is nothing but a POSITION type (CAtlList), which is a pointer to a FONT_NODE.

Then, whenever the app needs to output text it invokes one of a set of methods in CTextRenderer, which then makes use of the currently active font.

Seeing there can be only one font active at any given time, you can see problems will potentially occur in a multi-threaded environment where different threads use different fonts to output text concurrently.

Two ways I've thought to counter this was to either pass in a font handle to methods in CTextRenderer (though it isn't very convenient) or to change FONT_NODE and make it a class of the likes of CTextRenderer (the more logical way IMHO.)

What is your opinion on this? In light of your personal experience, do you think I could do this a better way, come up with a better design?

Many thanks to all of the posters for their precious replies!

Share this post


Link to post
Share on other sites
Quote:
Original post by hellraiser
Definitely I'm going to go for CTextRenderer and I'm going to follow your recommendations and drop the G. You're absolutely right, the way forward is to encapsulate the classes within namespaces. The only reason I went for the prefix 'G' instead of 'C' was to give the classes a stand outish meaning, one in the lines of 'GSomething', a graphics related class. I suppose I'm better off sticking to the standards... thanks for pointing that out to me.


The C is not any better. Just TextRenderer, please.

What do you think the C communicates? Why do you think the person using the class *cares about* this? Or didn't s/he already know?

Share this post


Link to post
Share on other sites
The "C" is just an annoying extra character to type. There's no point... what is it meant to indicate? A class and a struct are basically the same thing--especially from the perspective of a developer using it--and you certainly will never confuse a TextRenderer with a primitive type like int, char, float, double, etc.

Share this post


Link to post
Share on other sites
When I started out I thought I would use all that prefix Hungarian notation stuff too. But most people, myself included, just end up using a very small subset of that notation.

For example all I use is:

m_varName - to indicate a member variable
szStringName - to indicate a c-style null terminated string
typename_t - For typedef'd types (*RARELY*)
g_varName - For global variables (*RARELY*)

The rest is just too verbose for my taste. Besides if you have a good IDE, just highlighting over the variable name will reveal its type.

In conclusion: Use visual studio and drop all those annoying prefix C's and G's :)

[Edited by - fpsgamer on August 5, 2007 11:31:06 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer
For example all I use is:
m_varName - to indicate a member variable
szStringName - to indicate a c-style null terminated string


You usually don't even need those. If you have a variable named "name", or "nickname", or "password", or whatever, then it's typically pretty self-evident what the type is. And, to be honest, I've simply NEVER had a situation arise where I was tearing my hair out trying to figure out what the precise type of the "fooName" variable was.

And if I have any large blocks of code where it isn't immediately obvious which variables are locally declared, I fully name the member variables with "this->"... I used to use the m_ prefix, but found that it was simply not helpful to me.

Your mileage may vary, of course.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!