[
https://issues.apache.org/jira/browse/LOGCXX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903882#comment-13903882
]
Thorsten Schöning commented on LOGCXX-394:
------------------------------------------
> First, I don't understand the comparison overrides for LevelPtr in r1568810.
> Neither does GCC:
It worked without "template<>" in VS, but I added such a statement now and
hopefulyl this works in GCC as well.
> Second, I'm not sure how to just add in magic behavior for
> LevelPtr::operator== since LevelPtr is an ObjectPtrT and
> ObjectPtrT::operator== is non-virtual.
I must admit I just read the following from SO and thought one doesn't need
virtual operators to override them because of a special case for oeprators.
Again, this seems to work in VS, the former failing tests pass successfully
now. Coudl you test with the fixed compile time error if this works for GCC as
wlel? Else I would simply make the two operators in ObjectPtr virtual for now.
http://stackoverflow.com/questions/4421706/operator-overloading/4421715#4421715
> Is there some better virtual function pattern that could be used so that
> LevelPtr automatically adopts the semantics of Level? Or should it at all
> adopt the semantics of Level equality
> and instead simply behave like an ObjectPtr?
Really good questions and I didn't have answers on my own when I changed the
behavior of LevelPtr. :-) If we change LevelPtr to behave exactly like Level,
there will be somebody out there who wants to have a LevelPtr behave as an
ObjectPtr for some reason. If we decide to remove the overriden operators and
let LevelPtr be an ObjectPtr only, we are either stuck forever to let the same
Level objects be exactly the same objects because of the failing comparisons in
our own tests and need to find another solution for our current singleton
problem of this bug or every user needs to change comparisons like our failing
ones to really compare Levels by casting or derefrencing the LevelPtr instances.
>From my point of view there will always be somebody complaining and I find
>LevelPtr behaving more like a Level in common situations the "right thing" to
>do. Therefore I would even suggest implementing a Level::operator< and
>overriding ObjectPtr::operator< as well. In any other aspect LevelPtr already
>behaves like a Level because of operator* and operator-> and if one really
>wants to compare Level pointers one can simpy do so by using
>ObjectPtr::operator...(const T* p1).
> Levels are not thread safe
> --------------------------
>
> Key: LOGCXX-394
> URL: https://issues.apache.org/jira/browse/LOGCXX-394
> Project: Log4cxx
> Issue Type: Bug
> Components: Appender
> Environment: Windows 7, Visual Studio 2010 SP1
> Reporter: Petro Protsyk
> Assignee: Thorsten Schöning
> Priority: Minor
> Labels: thread-safety
>
> Level.cpp. All default level variables are function static. This is not
> thread safe, especially in Visual C++ compiler.
> Here is code to reproduce the issue in VC++ 2010:
> Concurrency::parallel_for (int(0), int(10), [&](int i)
> {
> if (::log4cxx::Level::getWarn() == NULL)
> {
> throw std::exception();
> }
> });
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
