Bugzilla – Bug 1652
Storage of the log name in LogComponent
Last modified: 2014-09-12 22:02:20 EDT
Created attachment 1573 [details] Patch LogComponent stores the log name as const char* pointer, which is perfectly fine in most of the cases, where LogComponent is statically initialized using macros. In more complex scenarios (I have a template-based hierarchical log initialization procedure), this breaks miserably. The attached patch simply changes storage to std::string, which solves all the problems.
(In reply to comment #0) > Created attachment 1573 [details] > Patch > > LogComponent stores the log name as const char* pointer, which is perfectly > fine in most of the cases, where LogComponent is statically initialized using > macros. In more complex scenarios (I have a template-based hierarchical log > initialization procedure), this breaks miserably. > > The attached patch simply changes storage to std::string, which solves all the > problems. the patch looks ok, but, really, I am curious: how come changing the type of a _private_ member changes the outcome for you ?
I have a non-static initialization of the logger, so when LogComponent internally stored only a const pointer, there were no guarantees that this pointer will be pointing to anything useful for such types of initialization. With std::string, there is additional memory allocated, which is kind of "wasteful" with static initialization, but gives guarantee in a general case.
This was already fixed in: changeset: 10228:8244f0b3ff1b user: Peter D. Barnes, Jr. <barnes26@llnl.gov> date: Mon Oct 28 14:50:08 2013 -0700 summary: [bug 1552] Storing log name inside LogComponent class (NS_LOG) as std::string (wrong bug number in the commit string)
actually, not a wrong bug number, it was a duplicate of 1552