"Greg Colvin" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Any thoughts on this issue? > > >From: Steve Clamage <[EMAIL PROTECTED]> > >To: C++ core language mailing list > >Message c++std-core-9820 > > > >Some compilers implement thread-local storage (TLS) for what would > >otherwise be global variables. The compiler and runtime system > >arrange for each thread to see its own copy of a global variable. > > > >Should the address of such a variable be allowed as a non-type > >template parameter? For example, this code is OK: > > extern int k; > > template< int* V > class C { ... }; > > C<&k> ck; > > > >But what if k is designated thread-local? The actual variable > >referred to by the address of k will differ among threads. > >(I'm assuming an implementation where &k results in a link-time > >constant whether k is an ordinary or thread-local variable.)
Two thoughts: 1) I don't know of any compiler which automatically makes 'k' thread-local. You either have to: a) tell the compiler that it is thread-local, ie. __declspec(thread) int k;, or you must: b) implement TLS yourself using an API which does pass a valid pointer to an "int" in this case, but one that is certainly not a compile-time constant. 2) In case a) we are dealing with an implementation-defined language extension ( __declspec(thread) ) so whether the address of such a variable is to be allowed as a non-type template parameter appears like it may also be implementation defined. In case b) we are not dealing with a compile-time constant so that it must certainly fail. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
