How do you choose a singleton and an unnamed class?

Question

I would use a singleton:

Singleton* single = Singleton::instance(); single->do_it(); 

I would use an unnamed class:

 single.do_it(); 

It seems to me that the Singleton pattern has no advantage over an unnamed class, except for reading error messages. Using singletons is more inconvenient than using an unnamed class object. First, clients must first obtain an instance handle; secondly, the Singleton::instance() developer may need to consider concurrency.

So why and how did you choose a singleton over an unnamed class?

In addition, although the obvious definition of an unnamed class may be

 class { // ... }single; 

I could also define it like this:

 #ifndef NDEBUG class Singleton__ { // readable error messages, #else class { // unnamed, clients can't instantiate #endif // ... }single; 

the latter approach has the advantage of reading compiler error messages, but is not single in debug mode.

Answer 1

I think the most important reason is that you cannot put an unnamed class in the namespace scope. Thus, the following is not valid (gcc accepts but warns: goau does not accept strict mode):

 class { } single; int main() { } 

The single type has no connection, because there is no way to declare its name in another area that refers to it (precisely because it has no name). But using it to declare a single that has a link (external here) is not valid (3.5 / 8). single should be defined locally basically where it will not have a connection. You also cannot pass single function templates and you cannot have static data members (because they cannot be defined). All these limitations make it more or less inapplicable as a substitute for a single tone.

Answer 2

Surely the main reason for using singleton objects in C ++ is to give you some control over the order of initialization using the "lazy construct" in your instance method?

As an example, most of my code uses a single logger, in which log messages are written. It started many years ago as a good old "global" one, but after being bitten, trying to use it before building, now it is singleton:

before...

 logger.write("Something bad happened..."); // crash if logger not constructed 

... after

  Logger &getLogger() { static Logger logger_; return logger_; } getLogger().write("Something bad happened..."); 

I read that the usual “singletones are bad” messages, but I have not seen anyone suggesting a better alternative for C ++.

Answer 3

A single class that you can declare in the header and implement in cxx, and therefore exchange cxx files. You cannot do this with an unnamed class, as each cxx will try to have its own instance of the object.

Answer 4

modifying such code, even if it probably should not affect code generation, is a terrible idea. sooner or later, someone is going to make a little tweak that generates different code in a debug or release, and then you have crash releases that cannot be replicated in debug builds.

Answer 5

Although convenient, singletones are usually a bad idea . See this page for a replacement design.

Answer 6

From your question, I see that you really do not understand the nature and purpose of the Singleton template.

You use singleton if you want to have a global object accessible by many "clients", and you want to make sure that only one instance of this object is created. Take, for example, the logger object. You want to be able to register from any part of your code, but your project should have only one registrar. This is the perfect place for a singleton.

Your example looks like you are creating a local object with a small area. For this, a singleton is not needed. This makes the code more understandable and understandable.

Answer 7

if (in addition to the verbosity of errors) there is no difference in behavior, 1 additional LOC is required for a global instance, a single-element set will require a bunch of nontrivial template. KISS

Answer 8

use singletones. use const. initialize them all in one class of gods. Know and avoid the static initialization fiasco: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12