Re: Singletons
On 12/14/2012 1:21 AM, ?? Tiib wrote:
What is your original "CMySingleton"/singleton? The unmaintainable
classes that I have seen were always the classes of singular objects
with "godly" names ... Application, FolderTree, Document, Form1, View,
DataBase, MainFrame and Manager. One of those?
I used two from that list. In MFC-based projects you start with theApp
that is instance of something derived from CApplication. I normally
tried to access all other app-tied singletons from here (settings, user
preferences, command line, etc). Then I used the same practice for
other apps. Still fail to see any problem with it.
The other one is Database -- In a period I wrote many programs that
started with creating one ODBC connection with a database, and the job
was to read/write data in that. Again see no problem -- even for cases
where secondary connections were opened for some technical reasons.
Free function fits best for (at least observably) immutable global
state. With inlines and constexpr most overhead and inconvenience is
reduced.
Some languages demand a "doer" for every function even if there are
none. That can be called "nonexistent global state". No such
(stateless singletons) needed in C++.
IMO the Singleton patterns imply mutable state. Otherwise we face the
Monostate pattern, and it's counterproductive to mess them. (monostate
covers both the stateless and immutable stuff).
Two silly examples to illustrate
what I mean:
threadId = std::this_thread::get_id();
threadId = ThreadingGenie::getInstance()->tellMeCurrentTheadId();
std::sort(names.begin(), names.end());
AlgorithmGenie::getInstance()->sort(names.begin(), names.end());
Some languages do not have namespaces. Well ... C++ has. So if the
singleton is actually whole module or package then use namespace.
When having global state is still needed for some reason, especially
when the reason was "convenience", then I am in difficulty to see real
benefit of the global object accessed with static accessor function
getInstance() versus simply accessing it directly by its name (like
std::cout). The former feels both global state (bad) plus code bloat
(not that convenient) to me.
I agree with all that.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]