I do not know how to implement a Singleton Class
Why would you need a global maths object for a maths library? How and what is the benefit of an object of class "Maths"?
Use a namespace Math instead of an object.
You can put static const float/double/int in the namespace and functions as well. I've seen a few libraries with a static xxMath object, but they are out-moded by the addition of namespaces.
There's about a dozen different flavors of singletons. As-always, which one you want depends on what you are trying to accomplish.
Edited by - Magmai Kai Holmlor on March 3, 2002 11:01:10 PM
You can put static const float/double/int in the namespace and functions as well. I've seen a few libraries with a static xxMath object, but they are out-moded by the addition of namespaces.
There's about a dozen different flavors of singletons. As-always, which one you want depends on what you are trying to accomplish.
Edited by - Magmai Kai Holmlor on March 3, 2002 11:01:10 PM
Also it''s useful to implement a singleton destroyer companion class. This makes sure you''re singleton object is deleted.
it''s basically a static object with a pointer to the singleton class, that''s deleted in the destructor.
I had some example code but I can''t find it and I don''t really have time to type it out again.
"That''s not a bug, it''s a feature!"
--me
it''s basically a static object with a pointer to the singleton class, that''s deleted in the destructor.
I had some example code but I can''t find it and I don''t really have time to type it out again.
"That''s not a bug, it''s a feature!"
--me
or you can just make your singleton instance static, so it cleans itself up... which is what I generally do because I can''t be arsed having another class which exists for the sole purpose of cleaning up another.
ie
i hope i remembered that correctly
... the advantage here is that it is only instantiated on the first call to GetInstance, and it cleans itself up, so no mucking about with determining who deletes it... its all good
ie
class Singleton{private: Singleton();public: static Singleton& GetInstance() { static Singleton m_instance; return m_instance; }...}; i hope i remembered that correctly
... the advantage here is that it is only instantiated on the first call to GetInstance, and it cleans itself up, so no mucking about with determining who deletes it... its all good
The disadvantage is that the order of static object construction is undefined (technically it''s spurious). So a static implementation of a singleton will work so long as no other static singelton depends on it being constructed during it''s construction.
As convoluted as that sounds, it''s not a terribly uncommon snafu.
As convoluted as that sounds, it''s not a terribly uncommon snafu.
quote:Original post by Magmai Kai Holmlor
The disadvantage is that the order of static object construction is undefined (technically it''s spurious). So a static implementation of a singleton will work so long as no other static singelton depends on it being constructed during it''s construction.
As convoluted as that sounds, it''s not a terribly uncommon snafu.
Ahh, but you are missing the point here.
Global static variable instansiation order is undefined, but static variables inside functions are instantiated the first time the function is called, hence there is no problem with BadMonkeys code.
quote:Original post by Void
Why would you need a global maths object for a maths library? How and what is the benefit of an object of class "Maths"?
Original post by Magmai Kai Holmlor
Use a namespace Math instead of an object.
You can put static const float/double/int in the namespace and functions as well. I''ve seen a few libraries with a static xxMath object, but they are out-moded by the addition of namespaces.
Its useful when you have several optimized math libraries (MMX, SSE, SSE2, 3DNow, etc) and you want to instantiate the most appropriate one for the processor you are running on. Namespaces cant do this for you. You could do it using function pointers, but you can say the same thing about anything OO. Using a Math class with an accessor method that ensures the correct type is constructed is just more elegant.
Personally, I prefer to leave the constructor public and reference count the object. This makes using the object a little easier to use (at least I think so):
Make sure in the cpp file you initialize refcount to zero:
int singleton::refcount = 0;
And use it like any other class. The first "instance" you create will initialize the object and the last to go will un-initialize it.
I''d create this as a stack based object but I can''t think of a reason why such an object couldn''t be created dynamically (just make sure you match your new''s with delete''s).
class singleton{public:// I don''t make my member functions static since none are virtual. singleton() { if (refcount < 1) { // Aquire resources here } refcount++; }//members here... ~singleton() { refcount--; if (refcount > 0) { // Release resources here } }private: static int refcount; // All other member variables declared static}; Make sure in the cpp file you initialize refcount to zero:
int singleton::refcount = 0;
And use it like any other class. The first "instance" you create will initialize the object and the last to go will un-initialize it.
I''d create this as a stack based object but I can''t think of a reason why such an object couldn''t be created dynamically (just make sure you match your new''s with delete''s).
um... Solo... i may be missing something, but this is not a singleton (as I understand it). The singleton pattern is based on the idea that only one instance of the object is ever instantiated . In a singelton pattern, the constructor is private for the very reason that you must not explicitly call it.
Using your approach, it seems you can instantiate as many of these objects as you like... and only the objects created when the static refcount == 0 ever aquire resources (and are not guaranteed to release them if your instantiate more than one)... the rest will be dangling out there with no handles to anything as far as I can see. It also seems that if your objects are to share the resources, all state must be static, in which case you may as well access them directly, rather than through an object... they are effectively a set of global variables!
Using your approach, it seems you can instantiate as many of these objects as you like... and only the objects created when the static refcount == 0 ever aquire resources (and are not guaranteed to release them if your instantiate more than one)... the rest will be dangling out there with no handles to anything as far as I can see. It also seems that if your objects are to share the resources, all state must be static, in which case you may as well access them directly, rather than through an object... they are effectively a set of global variables!
quote:Original post by Magmai Kai Holmlor
The disadvantage is that the order of static object construction is undefined (technically it''s spurious
The creation order is well defined (when the function gets called).
It''s the destruction order that is undefined using this "Meyer''s singleton".
Yes, there are situations where singletons depend on singletons. For eg. I have a logger singleton utility used for tracing which may be called by singleton''s ctor/dtor .
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
