overloading operator -

No.

the topic should be overloading operator-> *seems to skip the > character*


ok ill go the way with a instance of the singleton then, this still makes the code a little bit more readable thx

Can you give some more details about your singleton template and what your are actually trying to achieve (i.e. is this just for readability or is there some code that runs when you instantiate a singleton that you would like not to run)?

Enigma

Not the most inspiring way to spend my 2000th post, but never mind

Sounds like you're headed dead center down the middle of this road. Scroll down to the section titled "A Nagging Doubt". See if anything there resonates.

You could do something like this: singleton::instance()->dosomething().

I did it this way now

singleton< someclass >()->someclass_function();

Usually the default constructor of singletons shall be protected, so I just made it public so I am able to use the -> operator

This spares the repeated calls to singleton.instance() and makes my code easier to read

Its just a optical improvment of my code


thx

Quote:

Original post by Basiror I did it this way now singleton< someclass >()->someclass_function(); Usually the default constructor of singletons shall be protected, so I just made it public so I am able to use the -> operator This spares the repeated calls to singleton.instance() and makes my code easier to read Its just a optical improvment of my code thx

It's also creating a new copy of Singleton on the stack every time you call it. Which is shouldn't, which is why the constructor should be private. No cookie for you, yet.

yes but this instance is only a few bytes large, the object is encapsulates is stored on a static pointer
and its not a performance critical thing in my current app
maybe some compilers even optimize it away since all i am doing inside the overloaded operator is calling a static member function to return the objects address

Then why do you really even need to create an instance if the object encapsulated is stored on a static pointer? You may want to re-think your design, because this pretty much defeats the purpose of using a singleton (in actuality, it's not a singleton). Just my .02 :-)

Quote:

Original post by eleusive Then why do you really even need to create an instance if the object encapsulated is stored on a static pointer? You may want to re-think your design, because this pretty much defeats the purpose of using a singleton (in actuality, it's not a singleton). Just my .02 :-)

What do you see as the purpose of using a singleton?

Then why do you really even need to create an instance if the object encapsulated is stored on a static pointer? You may want to re-think your design, because this pretty much defeats the purpose of using a singleton (in actuality, it's not a singleton). Just my .02 :-)


actually the size of the singleton instance should be zero since no virtual functions or internal variables are stored

static member variables are stored somewhere else in the data segment


so the instance should be optimized away into a direct access to the static member

[Edited by - Basiror on February 2, 2006 2:55:05 AM]

Quote:

Original post by Sneftel Quote: Original post by eleusive Then why do you really even need to create an instance if the object encapsulated is stored on a static pointer? You may want to re-think your design, because this pretty much defeats the purpose of using a singleton (in actuality, it's not a singleton). Just my .02 :-) What do you see as the purpose of using a singleton?

IMO there are very few situations where a singleton is really appropriate (one example is in use with a factory pattern). But any time that you would need to access a public constructor (as suggested above), suggests to me that a singleton is probrably not appropriate for this situation (you should really only need to "get" an instance of a singleton using singleton::getInstance() or something similar).

Do you have another opinion on this? I'm always interested to see how different people view appropriate singleton usage :-)

Quote:

Original post by Basiror You may want to re-think your design, because this pretty much defeats the purpose of using a singleton (in actuality, it's not a singleton). Just my .02 :-) actually the side of the singleton instance should be zero since no virtual functions or internal variables are stored

You're using a different version of the definition of "singleton" than I am. Where I come, "Singleton" means "Single Instance". Hence the name. You seem to be describing the use of globals, namespaced using the class keyword. Kind of odd, given that we have a keyword for that, called "namespace".

-Mike

I'm assuming that Basiror's singleton implementation looks a little like:

template < typename Type >class Singleton{	public:		Singleton()		{			if (!instance_)			{				instance_ = new Type();			}		}		Type * const operator->()		{			return instance_;		}	private:		static Type * instance_;};template < typename Type >Type * Singleton< Type >::instance_ = null;

which to my eyes is a perfectly valid, if somewhat unusual, singleton implementation.

Σnigma

Quote:

Original post by Enigma which to my eyes is a perfectly valid, if somewhat unusual, singleton implementation.

Unless you just mean "valid" as in "It fits the definition of a singleton" rather than code one might want to use, I disagree. The lack of a deletion will cause false positives with a leak detector, and the singleton's destructor is never called. An implementation using std::auto_ptr or boost::scoped_ptr would be valid in my eyes.

I did indeed mean "valid" as in "It fits the definition of a singleton". I did consider using an auto_ptr in my example, but that has the potential to throw you right back into the initialisation order of non-local static objects problem so, not wanting to sidetrack the thread into a discussion of singleton destruction techniques, I opted to ignore destruction issues. I intended the phrasing "a little like" to indicate that it was not a complete solution, but perhaps I should have been clearer.

Σnigma

I know many people will disagree with my way, but when using singletons I simply create one instance of it then avoid creating others. It gives cleaner code and removes the overhead from constantly calling the getInstance() method.

Class.h:


Class.cpp:

Quote:

Original post by eleusive IMO there are very few situations where a singleton is really appropriate (one example is in use with a factory pattern). But any time that you would need to access a public constructor (as suggested above), suggests to me that a singleton is probrably not appropriate for this situation (you should really only need to "get" an instance of a singleton using singleton::getInstance() or something similar). Do you have another opinion on this? I'm always interested to see how different people view appropriate singleton usage :-)

TBH, I haven't seen a useful use of a singleton in a while. As far as I can tell, people use singletons to do procedural programming while pretending they're doing OOP. They use it as an accessional pattern rather than a creational pattern. (Not that it's a bad thing to do procedural programming; but there's no reason to do it with singletons rather than global variables.)

[Edited by - Sneftel on February 1, 2006 12:27:00 PM]

Quote:

Original posts by Sneftel Sounds like you're headed dead center down the middle of this road. Scroll down to the section titled "A Nagging Doubt". See if anything there resonates. // ... They use it as an accessional pattern rather than a creational pattern. (Not that it's a bad thing to do procedural programming; but there's no reason to do it with singletons rather than global variables.)

Thanks for the link, and I agree entirely. (Although I hate the word (?) "accessional".) I don't really see "purity" as a useful thing for OO, or for any other programming paradigm either. Using the best tool for the job applies at a lower level than just language choice.

FWIW, I tend to do things as follows:

1) Create the static interface (i.e. C++ namespace, or Java 'static class').
2) When necessary, create a single object instance, and refactor the code so that the static interface delegates to the object for implementation.
3) Now it is possible to expose the constructor of the object, and/or subclass it (for subclassing without exposing, you would have a static not-exactly-'factory' method to swap out the default implementation object).