Boost & Singletons?
Hi, I was wondering if the boost library had a class that I could derive my classes from to declare a singleton. For example: class MyClass : public boost::singleton<MyClass> {}; Something like that. I noticed there's a singleton.hpp in "boost\pool\detail", however this seems like an odd place for such a common and useful class. I'm actually a bit scared to use anything in a 'detail' folder, as usually (at least to me) that means private code or implementation details (not to be used). Is there a singleton type class in boost to help simplify the process of creating a singleton? Thanks.
On Wed, 05 Dec 2007 15:15:19 -0600, Robert Dailey wrote:
Hi,
I was wondering if the boost library had a class that I could derive my classes from to declare a singleton. For example:
Hi, At the bottom of http://uint32t.blogspot.com/2007/12/you-lazy-bastard-part-1.html there is a simple class that I've used. The usage would look something like: struct Object {...}; // returns Object &, lazily-initialized and threadsafe singleton<Object>::instance(); It requires Boost Threads to be threadsafe. I apologize in advance for the language, but didn't think it could possibly be useful :-) I also recently came to know that there is something in the Boost Vault under the X-files folder. Let me know if you have any questions. -- Sohail Somani http://uint32t.blogspot.com
How do you prevent people from instantiating Object (in your example)?
Also, I was more or less looking for a member-specific way of doing the
singleton access. For example:
Object::instance()
On Dec 5, 2007 3:26 PM, Sohail Somani
On Wed, 05 Dec 2007 15:15:19 -0600, Robert Dailey wrote:
Hi,
I was wondering if the boost library had a class that I could derive my classes from to declare a singleton. For example:
Hi,
At the bottom of
http://uint32t.blogspot.com/2007/12/you-lazy-bastard-part-1.html
there is a simple class that I've used. The usage would look something like:
struct Object {...};
// returns Object &, lazily-initialized and threadsafe singleton<Object>::instance();
It requires Boost Threads to be threadsafe. I apologize in advance for the language, but didn't think it could possibly be useful :-)
I also recently came to know that there is something in the Boost Vault under the X-files folder.
Let me know if you have any questions.
-- Sohail Somani http://uint32t.blogspot.com
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, 05 Dec 2007 15:35:35 -0600, Robert Dailey wrote:
How do you prevent people from instantiating Object (in your example)?
Also, I was more or less looking for a member-specific way of doing the singleton access. For example:
Object::instance()
You can do something like: struct Object { friend class singleton<Object>; Object& instance() { return singleton<Object>::instance(); } private: Object(); ~Object(); }; I'm sure there is a nicer way to wrap that up. -- Sohail Somani http://uint32t.blogspot.com
Your suggestion is good and all, however it doesn't really give me much
benefit. If I'm going to go through the trouble to do that, I might as well
go ahead and just not use the singleton object you have. The reason why I'm
looking for a base class to derive from is so that I don't explicitly have
to re-write the same singleton implementation details for every class,
listed below:
- Generic public static "Instance()" function
- Generic public static "Release()" method (if your singleton instance is on
the heap. Stack instances do not require this)
- Declaration/definition of the actual singleton static variable
- Preventing the singleton class from being instantiated (this means the
base class needs to somehow prevent the derived class from being
instantiated outside of itself).
If I can find a class that automates this for me JUST by deriving from it,
that would be perfect. However this may be too much to ask? Your singleton
idea is great, however it doesn't exactly fulfill what I'm looking for. I
apologize for not having elaborated on this thoroughly to begin with.
On Dec 5, 2007 3:53 PM, Sohail Somani
On Wed, 05 Dec 2007 15:35:35 -0600, Robert Dailey wrote:
How do you prevent people from instantiating Object (in your example)?
Also, I was more or less looking for a member-specific way of doing the singleton access. For example:
Object::instance()
You can do something like:
struct Object { friend class singleton<Object>; Object& instance() { return singleton<Object>::instance(); }
private: Object(); ~Object(); };
I'm sure there is a nicer way to wrap that up.
-- Sohail Somani http://uint32t.blogspot.com
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, 05 Dec 2007 16:02:02 -0600, Robert Dailey wrote:
Your suggestion is good and all, however it doesn't really give me much benefit.
That's fine. The class that was posted earlier was meant to address thread-safety concerns more than anything. If this is not a concern for you, then you are lucky. However, if it is, I would caution you on your use of any Release() function. Ensure that the use of this function is threadsafe. There is a posting here: http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/ thread/e824b5a595066332 That seems to do it in a sensible manner.
If I can find a class that automates this for me JUST by deriving from it, that would be perfect. However this may be too much to ask? Your singleton idea is great, however it doesn't exactly fulfill what I'm looking for. I apologize for not having elaborated on this thoroughly to begin with.
You might look at the singleton library in the Boost Vault under the X- files folder. It seems to be the Swiss Army Knife of singletons and might do what you want. -- Sohail Somani http://uint32t.blogspot.com
[Singletons]
Robert you should investigate whether Tobias Schwinger's Singleton (the Schwingleton, if you will) meets your needs. It is available in the vault at http://www.boost-consulting.com/vault/index.php? <http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo ry=X-Files> &direction=0&order=&directory=X-Files and is, I believe, in the review queue. Pete
On Wed, 05 Dec 2007 22:13:46 +0000, Pete Bartlett wrote:
the Schwingleton
That is going to have to be the official name now. -- Sohail Somani http://uint32t.blogspot.com
Thanks guys, you've been most helpful. I'll check out the X-Files singleton
and let you guys know later on if it is what I'm looking for.
On Dec 5, 2007 4:13 PM, Pete Bartlett
[Singletons]
Robert you should investigate whether Tobias Schwinger's Singleton (the Schwingleton, if you will) meets your needs. It is available in the vault at
http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files
and is, I believe, in the review queue.
Pete
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Performance optimization has come up recently but I had avoided posting anything to the list as it is not exactly a boost specific topic. However, John has suggested that gcc produces slower boost results due to lack of inlining. In a quick test on some of my own code, I couldn't find any evidence of that. Further, most of the discussion here seems to center on things like instruction count. As someone who learned to program on an 8080, I have a lot of sympathy but I was shocked to learn in this century (quite literally true for myself) that there are a lot of additional factors that effect performance on today's architectures. Interested parties may wish to look at things like this: ftp://download.intel.com/design/Pentium4/papers/24943801.pdf In particular, after skimming the memory hierachy, consider also the specific FPU you are using. I know in one case, a functioning audio codec was having noticeable speed problems visible on task manager. Further investigation found perceptibly irrelevant things like near-zero values or NAN/ overlfow problems that didn't effect the final results. My point here is that even a few denormals or exceptional cases can have a big impact on performance- you could have these even if your output looks right. Certainly vectorized code would help but if the memory access patterns are wrong these will limit performance- it can be hard to keep one execution unit busy with slow memory. Just some things to think about if you care. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: Hotmail is blocking my mom's entire ISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'T assume I am ignoring you and try me on marchywka@yahoo.com if no reply here. Thanks. _________________________________________________________________ Put your friends on the big screen with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_...
participants (5)
-
Michael Fawcett -
Mike Marchywka -
Pete Bartlett -
Robert Dailey -
Sohail Somani