Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-02-18 17:40:27


"Greg Colvin" <Gregory.Colvin_at_[hidden]> wrote in message
news:5.2.0.9.2.20030218123426.02a0cc20_at_rgmgitmail.oraclecorp.com...
> Any thoughts on this issue?
>
> >From: Steve Clamage <stephen.clamage_at_[hidden]>
> >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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk