Paul A Bristow wrote:
> This scheme may offer more surprises to the many naive users (like me)
> than an explicit (and convenient 'global') choice, for example:
>
> using boost::math::double_constants;
>
> to ensure that the expected size is used.
>
> One can make the compiler warn you about size c
> William E. Kempf wrote...
>> pragmas. As a "best practice suggestion", it's a great idea... as a
>> requirement, I'd have to voice an opinion against.
Paul A. Bristow wrote:
>
> I absolutely agree, but I feel it would be useful encourage authors
> to try.
Playing devil's advocate, but why?
Wi
Gabriel Dos Reis wrote:
>
> There is what that particular implementation does with its extensions
> and there are various mulit-threading models, what the standard
> language is defined to be and ways to extend it to support
> multi-thread and thread
> local storage. In that regard, bugs in either
Alexander Terekhov wrote:
>
> Uhmm. In return, I venture to suggest that MS-TLS can and shall be
> characterized as ``utterly busted.''
Fine, but the OP asked about existing practice and the bugs
don't change the fact that "&k" can be a template parameter
if the compiler is willing to thunk its wa
Gabriel Dos Reis wrote:
>
> This analgoy does not cut it: You don't have a function "fk" by
> thread. You have a -single- function designator. And the return
> value depends on the calling thread.
Whereas with a TLS variable you have a single variable name and
the value of that variable when refe
Alexander Terekhov wrote:
>
> I, for one, believe strongly that "&k" is nothing but
>
> "static_cast(pthread_getspecific(__k_key));"
>
> It *isn't* a compile-time constant (just like &errno isn't a compile
> time constant).
MSVC has no pthread_getspecific(), so I venture to suggest that
your b
David Abrahams wrote:
>
> I think you may be missing the point that in some sense &k doesn't
> have to have a single type. [...]
I think this is what I'm grasping at in my example 3, but I'm just
expressing myself badly. I dragged implementation into it so that I
could show how a given TLS implem
Alexander Terekhov wrote:
> Ken Hagan wrote:
> [...]
>> 3a If we allow C<&k> [...] It is then possible to initialise static
>>variables [...] and the results depend on the thread that ran
>>first. Again, we have the same "problem" passi
Reading various replies, we appear to have a couple of things that
aren't completely pinned down: the type of "&k" and the implementation
of TLS.
1 If "&k" is a regular pointer to integer and TLS is implemented by
tweaking page tables for each thread, then "&k" has the same value
in each th
Peter Dimov wrote:
>
> &k does not exist yet at compile-time (in a pointer to int form), when
> templates are instantiated.
It doesn't have to. We're instantiating a template, not calling a
function, so if "&k" has the type "pointer to thread-local int" then
the compiler knows that and can instant
>> 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
11 matches
Mail list logo
