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!

How about:

TextRenderer
TextRenderingFactory

Yes, drop the G. We aren't barbarians here.

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 CManagerFontsclass CManagerFonts	// creates and removes fonts, holds the currently active font, 			// and encapsulates font dataclass CTextRenderer	// does text rendering only and (constly) accesses CManagerFontsFont 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!

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?

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.

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]

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.