void LogInternal(const wxString& msg, int i, Logger::level lv) { if ((i>=0) && (i<=(int)max_logs) && (slot[i].log!=&g_null_log)) slot[i].log->Append(msg, lv); };Remember, the trace macro was actually only for debug purposes. I know, we mis-use it. :lol:Agree!!!
However, please don't mess with LogManager. That's not something to change. instead, we should always use events to report CC infos from threads to the plugin "main loop" itself. So instead of calling Log(...) directly, fire a custom event (implemented inside the CC plugin) and handle the call outside the thread.Yes, correctly way we should use.
we should always use events to report CC infos from threads to the plugin "main loop" itself.Yes, this is what I called the CC's Logger.
Loaden: do you know that the singleton pattern is considered a bad pathern? Why are you doing CCLogger::Get(), instead of having m_logger or g_logger?Singleton pattern in here, nothing bad.
Some random links:
http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
http://stackoverflow.com/questions/86654/whats-wrong-with-singleton
http://aabs.wordpress.com/2007/03/08/singleton-%E2%80%93-the-most-overused-pattern/
p.s. I don't like the Manager::Get() thing, too :P
Singleton is a global variable!!! They call it glorified global variable.In this case, we not need thread-safe for CCLogger::Get.
What do you gain by using singleton in this case? Instead of global variable or global variable hidden behind two functions cc::DebugLog and cc::Log (and of course one init function)?
BTW: Your Get() method is not thread safe:)
Also don't use double locking if you try to make it thread safe:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://bartoszmilewski.wordpress.com/2008/08/04/multicores-and-publication-safety/
CodeCompletion::CodeCompletion() :
...
{
CCLogger::Get()->Init(this, idCCLogger, idCCDebugLogger);Also don't use double locking if you try to make it thread safe:Which code use double locking? Can you give a direction in the CC's code(trunk HEAD)?
if you try to make it thread safe:Also don't use double locking if you try to make it thread safe:Which code use double locking? Can you give a direction in the CC's code(trunk HEAD)?
In this case, we not need thread-safe for CCLogger::Get.So you're admitting that you're using this singleton as glorified global variable? :)
CCLogger::Get should call first in CodeCompletion::CodeCompletion():
That's exactly how the entire project is organized, every "...Manager" class, whether it's configuration, project, buildtargets or whatever.In this case, we not need thread-safe for CCLogger::Get.So you're admitting that you're using this singleton as glorified global variable? :)
CCLogger::Get should call first in CodeCompletion::CodeCompletion():
They are not, all GUI libs I've seen (MFC/Win32api, QT, wxWidgets) are intended for single threaded usage.
- There is no other reason (i.e. crash) which is obvious to me why you could not log concurrently. Unless wxWidgets GUI functions are not re-entrant, which I would seriously hope they are.
In at least one case (config) there is an urgent reason behind it too, in most other cases I guess one cold probably do otherwise, if one cares to spend many hours rewriting a lot of code.I've not said to rewrite all existing code. I know it is impossible.