You can make them local functions statics, I think...
Yes, except function local statics effectively result in a sort of
if(initialized) foo = initializer; code sequence, and in C++11 these are required to be initialized thread-safe, and GCC since about version 4.6 or 4.7 does that regardless of C++11 anyway (unless you compile with
-fno-threadsafe-statics), using a mutex. Now of course,
locking a mutex makes the point of trying to avoid initilizing a string somewhat... redundant.
Not sure if the compiler is smart enough to elide the copy anyway.
Compiler writers, tells us that they are smart enough... http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
Do you agree that the return type should be changed?
I'm know this article, but I'm not convinced that it applies to us. For example, we don't follow the guideline of not copying arguments (obviously) and your return value is not anonymous, so at best NRVO can be used, not RVO. Also, var-args are a kind of ugly hack, and I'm not sure inhowfar it influences optimizations such as NRVO.
But I'm OK if you think that returning by value is a better choice, even if it
does create a copy. A verbatim copy on a
wxString is only incrementing a reference counter.
Feel free to choose whatever makes you feel most comfortable.
What worries me more than those micro-optimizations is code like this:
void TextCtrlLogger::Append(const wxString& msg, Logger::level lv)
{
if (!control)
return;
::temp_string.assign(msg);
::temp_string.append(_T("\n"));
if (lv == caption)
{
control->SetDefaultStyle(style[info]);
control->AppendText(::newline_string);
control->SetDefaultStyle(style[lv]);
control->AppendText(::temp_string);
control->SetDefaultStyle(style[spacer]);
control->AppendText(::newline_string);
}
else
{
control->SetDefaultStyle(style[lv]);
control->AppendText(::temp_string);
}
}
The
F function as it was is kind of "semi threadsafe" insofar as all modules that were supposed to use it (mostly compiler, and maybe project mgr) run at most one thread per module. Now the
TextCtrlLogger such as being used for the debug log on the other hand is definitely thread-unsafe, but I don't even understand why it uses the global here at all. Appending a newline would make much more sense on a plain normal local variable, no?
