4

I am a newbie to boost.I find that there two ways to use boost::singleton.Code pasted below:

// First 
class Foo {};
#define FooInstane singleton_default<Foo>::instance()

// second 
class Bar : public singleton_default<Bar> {};
#define BarInstance Bar::instance()

I think both are OK.But I cannot find some authoritative conclusion.

Question: Which one is right? Or both right(Then which one is better)?

The doc of boost::singleton can be find here.

prehistoricpenguin
  • 6,130
  • 3
  • 25
  • 42
  • 2
    **DON'T**. Singleton is an antipattern. And never made sense in C++ where you can have non-member functions, file-static variables and anonymous namespaces in the first place. See [Singletons: Solving problems you didn't know you never had since 1995](http://jalf.dk/blog/2010/03/singletons-solving-problems-you-didnt-know-you-never-had-since-1995/). – Jan Hudec Sep 17 '14 at 09:21
  • 3
    @JanHudec Thanks for your comment.I'll try not to use it.But can you please answer my question first. – prehistoricpenguin Sep 17 '14 at 09:25
  • Second one provide you more flexibility, also instead of using singleton use shared instance. – Hemant Gangwar Sep 17 '14 at 09:26
  • 1
    I have no opinion on which is more or less correct, but apparently boost authors do, as the last version it was supported in was 1.47 (we're up to 1.56 as of this writing). It is no longer in the active library that I can find (not that I searched for terribly long). – WhozCraig Sep 17 '14 at 09:30
  • "DON'T. Singleton is an antipattern." Which is probably why it's heavily used in boost, one of the highest quality C++ libraries available. – Peter Sep 17 '14 at 09:33
  • 2
    @JanHudec file static variables are worse than singletons and prone to the static initialization fiasco. – Arne Mertz Sep 17 '14 at 09:36
  • @prehistoricpenguin if you use the second version, why use a #define at all? I can't see any obvious advantage of either, unless you use the second version but without the #define. – Peter Sep 17 '14 at 09:37
  • @Peter Do you have examples where boost libraries use singletons? And it is not one library but several, with differing graes of code quality. – Arne Mertz Sep 17 '14 at 09:37
  • @arne go to boost.org, type "singleton" in the search box, press return. – Peter Sep 17 '14 at 09:39
  • @ArneMertz: There is no static initialization fiasco within a file and if they are really file static, then the relative order of initialization with other units does not matter. Or use function-static data instead. – Jan Hudec Sep 17 '14 at 14:13
  • @WhozCraig: Your comment prompted me to search properly and I found that there are several singleton classes in the latest version, but they are all hidden in various `details` subnamespaces and undocumented. This one was moved to details of the Pool component too. – Jan Hudec Sep 17 '14 at 14:27
  • @ArneMertz If your statement was correct, `std::cout` and other global streams would not work universally. Google "schwarz counter" to learn how to enforce the order of dynamic initialization between translation unit. This is how the standard global streams are initialized, no compiler magic involved here. – Maxim Egorushkin Sep 17 '14 at 14:38

1 Answers1

4

Neither. The class does not exist any more.

The class was never intended for users. It was only for internal purposes of the Boost.Pool library and was apparently removed. There are some other singleton classes, but all are hidden in the private details of various components.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
  • 2
    I'll just put this here so it appears in the sidebar of this question: http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons This explains both why singletons are used by boost and why they are not offered to the user of boost libraries. – Peter Sep 17 '14 at 14:36