I’ve got a quasi-singleton class (quasi-singleton in that most use refers to a single object that is a function static, but users can also construct their own local copy for short-term use) that I would like to have write to cout from its destructor, and wanted to know if cout was guaranteed to be available during the static deinitialization phase following program termination. From this question it seems that the answer is yes (function static initialized objects should have their destructors called in reverse order from when they were constructed, which should be after cout was set up), but I wanted to check.
// Count calls to a logging function from some point in our code, to determine
// how many times it gets executed during a run, then report calls at the end
// of the program. A quick-and-dirty way of determining how often we execute
// code.
class callCounter;
class callCounter {
public:
callCounter() : has_calls_(false), counts_() {}
~callCounter () {report(std::cout);}
void logCall(const std::string callSite);
void report(std::ostream &os);
void reset();
static callCounter *theCounter();
private:
typedef std::map<std::string, callCount> COUNTMAP;
bool has_calls_;
COUNTMAP counts_;
};
callCounter *callCounter::theCounter()
{
static callCounter theCounts;
return &theCounts;
}
Typical usage would be:
callCounter::theCounter()->logCall("foo");
So is this usage of cout in the destructor guaranteed safe (at least as far as using cout itself is concerned – arguably to be perfectly safe, I should wrap the report in a try block in case the write throws an exception.)?
Short Answer: Yes
Long Answer: Yes
There are a couple of tricks that the standard library uses to make sure that std::cout (and std::cin/std:cerr) are available before any other objects (But you must #include <iostream> in the translation unit). Because they are created first (the reverse order of destruction rule guarantees) they are destroyed after your objects.
See: n3242 (Practically the C++0x standard Pub: 2011-02-28)
27.4 Standard iostream objects
Paragraph 2
Added highlighting.
From n1804 (which is basically the 2003 standard: Pub: 2005-04-27)
27.3 Standard iostream objects
Paragraph 2
Unfortunately the bit that would make it a guarantee is in the footnotes (which are non-normative (ie its not guaranteed just what the implementer should try and achieve).
With the footnotes: