Re: [lmi] Don't initialize constexpr variable with std::ldexp()

[Vadim Zeitlin]

On Mon, 24 Apr 2017 16:37:55 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-04-24 16:16, Vadim Zeitlin wrote:
GC> > On Mon, 24 Apr 2017 15:25:48 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> With this patch, does the 'bourn_cast_test.cpp' unit test compile and
GC> > GC> report zero errors with these other two compilers?
GC> > 
GC> >  Yes, the test passes with both gcc and clang (and sorry, I meant to say
GC> > this in my previous message but after rereading it I see that I forgot to
GC> > include it).
GC> 
GC> I think you meant
GC> - the test passes with both gcc and clang
GC> + the test passes with both msvc and clang

 No, for once I did write what I meant: the test (still) passes with gcc
and (now also) passes with clang. I didn't test with MSVC because I didn't
think you'd be interested in neither the result of the test nor,
especially, in fixing any possible problems with it, but I could do if
you'd like to.

GC> [...effect of const (not constexpr) with or without static...]
GC> 
GC> >  This is true, but I expect the call to ldexp() to be very fast even if
GC> > it's not evaluated at compile-time -- which should be the case with gcc.
GC> > OTOH static variables must be MT-safe in C++11 and so using it here must
GC> > involve at least an atomic variable access (or maybe even a mutex
GC> > lock/unlock?), which could well be more expensive.
GC> 
GC> Interesting.

 FWIW I had a look at __cxa_guard_acquire() for clang (from
https://llvm.org/svn/llvm-project/libcxxabi/trunk/src/cxa_guard.cpp) and it
does seem to acquire a mutex, which seems likely to be more expensive than
calling ldexp(). libstdc++ implementation at
https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/libsupc++/guard.cc
seems to just use atomic operations on the platforms with futex support
(which includes Linux, but not MSW, I think), which should be more
efficient.

 Also notice that if a mutex is used, it's a global one, i.e. shared by all
static variables in the module, which means that it could seriously
negatively affect any code using static variables from other threads as
there would be real contention between accesses to it from multiple
threads.

 Regards,
VZ