Archived

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

style:access singleton

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

Recommended Posts

hi Consider the singleton class below. Is it a good habit/style to use the #define to make the access to the class easier? Are there other possibilities?


#define GET (MySingleton::get())

class MySingleton
{
static MySingleton* m;

public:
staticMySingleton* get()
{
return m;
}

void test() {}

};

int main()
{
GET->test();         //easy access

}



Share on other sites
hmm... it''s just a question about style. However my leading star is that whatever you write it should be clear of what you are doing, and that GET isnt.

Share on other sites
The problem is, when you have a singleton that is often used, you always have to write "ClassName::getMethod()" to get the pointer.

bye
chris

P.S. Maybe you think it''s not clear because I use GET as the #define name instead of a descriptive name!?

Share on other sites
You should probably avoid using compiler macros altogether (just use inline functions which can provide the same speed, but with the bonus of type-safety). I would definitely steer clear of the usage you show there... is it really that much of an effort to type the class name?

If you need to make a number of calls to the object within a function, just declare a nice short-named pointer to the singleton class and use that instead of the fully-qualified name each time...

i.e.

MySingleton* handle;

handle = MySingleton::Get();

...

Much better at conveying the meaning of the code... I mean come on man , that macro if just frikkin'' laziness in the extreme

Share on other sites
quote:
Original post by Zoomby
The problem is, when you have a singleton that is often used, you always have to write "ClassName::getMethod()" to get the pointer.
...it''s not much of a problem to store the pointer for several consecutive uses:

MySingleton* t = MySingleton::get();
Pie p = t->aquire("pie");
t->eat(p);
t->worship(p);

Share on other sites
quote:
You should probably avoid using compiler macros altogether (just use inline functions which can provide the same speed, but with the bonus of type-safety).

Just to be clear, there''s no issue of type safety in this instance. It''s mostly about clarity here. That being said...

quote:

I would definitely steer clear of the usage you show there... is it really that much of an effort to type the class name?

I completely agree. If you made the macro (or inline function name) clear enough, you''d basically be typing the much feared "MySingleton::get()".

quote:

If you need to make a number of calls to the object within a function, just declare a nice short-named pointer to the singleton class and use that instead of the fully-qualified name each time...

i.e.

MySingleton* handle;

handle = MySingleton::Get();

...

Much better at conveying the meaning of the code... I mean come on man , that macro if just frikkin'' laziness in the extreme

I agree, though I''m not sure I''d even make the variable (that is, assuming Get() is fast). Of course, I like long, descriptive names. I''d rather spend 3 more seconds typing now than spend an hour down the road trying to figure out what the heck is going on. (comments would also work, but naming the variables properly can lessen the need for comments and force you to "maintain" your "comments")

Share on other sites
I use a macro for singletons like so:

  class Application : public Singleton< Application >{public:  // stuff};#define gApplication Application::GetInstance()

which allows me to use it like so:
gApplication.SomeMethod();

Share on other sites
Think of a design that doesn''t require singletons and you''ll be better off.

Share on other sites
quote:
Original post by Anonymous Poster
Think of a design that doesn't require singletons and you'll be better off.

How so? Sometimes a Singleton can be the appropriate tool for the job.

I don't want to have to store a reference to the Engine object in every freakin other class I make that needs to access it. And then write appropriate constructors to handle the Engine object, and then make sure I pass the Engine object to every other class that I make an instance of that needs access to the Engine. That's just nuts.

Also, the singleton pattern enforces the design intent on the programmer. When a class is declared singleton, and another programmer comes in and tries to instantiate that class, the compiler ( or run-time, in the example I gave above, but better if it's the compiler ) will tell the programmer that the class is intended to be used as a singleton, and as such only one instance is allowed.

[edited by - daerid on May 26, 2003 10:17:14 PM]

Share on other sites
quote:
Original post by daerid
I don''t want to have to store a reference to the Engine object in every freakin other class I make that needs to access it. And then write appropriate constructors to handle the Engine object, and then make sure I pass the Engine object to every other class that I make an instance of that needs access to the Engine. That''s just nuts.
I haven''t found it a burden at all. You just need to think the design in such a way that Engine won''t be needed in many places. But say, you realize it''d be useful to run several Engines within a single program when you extend the game to have multiplayer capabilities and need several Engines to run several game arenas. What''re you going to do then?
quote:
When a class is declared singleton, and another programmer comes in and tries to instantiate that class, the compiler ( or run-time, in the example I gave above, but better if it''s the compiler ) will tell the programmer that the class is intended to be used as a singleton, and as such only one instance is allowed.
Oh, please. Why would someone try to make a new Engine abruptly? If someone wants to make a new Engine-object, she probably has a good reason to do so, like the multiplayer system mentioned above. I can''t think of a single thing that should be singular; You can always have a parallel world.

1. 1
2. 2
3. 3
4. 4
Rutin
18
5. 5

• 14
• 12
• 9
• 12
• 37
• Forum Statistics

• Total Topics
631423
• Total Posts
3000005
×

Important Information

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!