> On Aug 20, 2014, at 2:36 PM, Zachary Turner <ztur...@google.com> wrote:
>
> As part of my moving code from Host to HostInfo, I moved some function-local
> statics to global class-member statics. The reason for this is that MSVC
> doesn't support thread-safe function local statics until VS2014, which is
> still only in technology preview, whereas LLVM, clang, and by extension LLDB
> support building as far back as VS2012.
>
> Greg submitted r216080 to convert these global statics back to function-local
> statics, but this had a bug in it which broke things for all platforms, so I
> reverted it in r216123. A simple fix would have just been to address the
> bug, but my original transition from function-local statics to global statics
> was intentional due to the fact that any use of them on a non-primitive type
> is undefined behavior on MSVC.
>
> So, I want to see if people have a strong preference one way or the other.
> If the issue is just silencing the compiler warning that clang gives about
> global constructors, then we can do that in CMake and/or the Xcode project.
> On the other hand, I understand that global static constructors increase
> application startup times. Is this a concern for anyone? If so, I can try
> to come up with a solution. I think if we try to keep the use of statics to
> a minimum, and make sure that they are generally simple types (e.g
> std::string, which simply does a malloc), then there should be no noticeable
> performance impact on startup.
>
> Thoughts?
For our build submissions here at Apple we need to keep the number of global
constructors to a minimum. We need to apply for exceptions for each global
constructor that is added to a shared library or framework. This is the main
reason for the change I made. global constructors are fine for apps and they
get to make that decision, but for shared libraries, they should be avoided if
possible.
I would suggest using std::once for any issues you run into:
static std::once_flag g_once_flag;
std::call_once(g_once_flag, [](){
// Insert code here to run once in a thread safe way
});
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
