Printable View
... and destructor.
If I have a class like this:
I don't want to create an instance of it to make use of it. When do the constructor and destructor get called? Does it involve a temporary?Code:class ErrorLog
{
public:
ErrorLog();
~ErrorLog();
static bool OpenLogs( const char* szFileName );
static void Log( const char* szMessage );
static void CloseLogs();
private:
static std::ofstream m_LogFile;
};
I don't get your question.Quote:
Originally Posted by ahluka
No instance -> no constructor -> no destructor.
Kurt
He probably wants to know if a call to one of the static functions will result in the call of the constructor and destructor. And the answer is no. But if you are going to make all functions of a class static why not use a namespace instead?
I thought it'd be something like that. The namespace solution sounds best.
Thankies guys :)
A namespace can't exactly have private variables, so a class with only static methods isn't too bad. (Personally I'd go for a global instance and thus not prevent having multiple logs.) With namespaces, you'd have to use things like subnamespaces in order to hide implementation - and even then it's very little hiding.
You could make this class a singleton and gain the advantages of C++ data hiding, yet still be able to control instances.
Is it conceptually right to make a logger a singleton, though? I.e. will there only be one logger, ever?
Well, yes, I would've thought so (at least in my design). I guess if the need arises I'll do "something else".
Depends on your design. I, for one, appreciate having only one logger so that each object can use it instead of instantiating it's own local error log object.
It depends on your design, however, and is definitely a matter of personal preference.
I normally create the logger object and then add debug functions to the base classes to use the logger. I pass around the pointer to the object and clean it up later.
For instance, CMainFrame would instantiate the logger, and CDocument and CView would then get the pointer to the logger and pass it on to their members if need be.
I've done it both ways and I like having just one instance of a logger.
Of course you could create an exception class and do error logging that way as well.
Which brings us to the following question:
What exactly is the advantage of having a class a singleton (the GoF definition), compared to a class with all members static and a protected constructor?
Examples:
Code:class SingletonLogger{
private:
static SingletonLogger *pS_instance;
std::ofstream OS_err;
protected:
SingletonLogger(void);
public:
static SingletonLogger *pS_Instance(void){
if (pS_instance == NULL){
pS_instance = new SingletonLogger;
}
return(pS_instance);
}
void v_Open(char *psb_file);
void v_Write(char *psb_error);
void v_Close(void);
};
// Versus:
class StaticLogger{
private:
static std::ofstream OS_err;
protected:
StaticLogger(void);
public:
static void v_Open(char *psb_file);
static void v_Write(char *psb_error);
static void v_Close(void);
};
Some differences between the two cases (I hesitate to call them advantages, as the choice is a tradeoff) include;
1) The stream in the static version must (according to the standard) be initialised at or before the first call of the static member function. In practice, with many compilers, this will happen before main() is called, and means that the logger is initialised even if it is never used. The stream in the singleton version will never be initialised before first usage of the logging functions, meaning that the stream will never be initialised if the program does no logging.
2) The initialisation for the static version must generally be at compile time. The singleton version, with only minor tweaks, can be initialised using runtime data. For example, a name of the log file could be specified on the command line, and used to initialise the stream.
I agree that having a single logger will be the most common use case, but is it worth enforcing that there is only a single logger, as the Singleton pattern does?Quote:
Originally Posted by Bubba