Re: [boost] Re: Thread-Local Storage (TLS) and templates

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2003-02-24 08:55:37

David Abrahams <dave_at_[hidden]> writes:

| Gabriel Dos Reis <gdr_at_[hidden]> writes:
| 
| > | OK, whatever.  I guess I should've said that you can instantiate a
| > | template on &k with sensible results.  Whether or not you want to call
| > | it a constant is another semantic matter.  I'd call it a constant
| > | which evaluates differently in different threads.  
| >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| >
| > And that isn't just a word-game as your message might imply it.
| 
| I never meant to imply that it's a word game, just that I'm only
| willing to concede "not a constant-ness" for some very narrow
| definition of the word "constant."  If you think of threads as being
| truly concurrent, the value actually _is_ constant (just different in
| different threads).

There are different levels of "being constant".  That is the main
issue here.  An object can be constant only after a runtime
initialisation.  Such level of "constant-ness" is not considered for
template arguments.  To make address of TLS objects acceptable, one
has first to give a preceise and workable extension for the definition
of "constant" expressions as currently defined.

| > | Within a single thread the value never changes.
| >
| > Like in
| >
| >    template<typename T>
| >      struct X { };
| >
| >    int main()
| >    {
| >       const int i = 2003;
| >       X<&i> x;
| >    }
| >
| > ?
| 
| Not sure what you're getting at, since the code is invalid.  I'll
| assume you meant X to take an int* parameter.

yes, sorry, I meant that.

| 
| > In a given program run, &i won't change.  That is just in single
| > thread mode.  Let's solve that first.
| 
| What is there to solve?  I'm not interested in making the above legal
| (is calling main explicitly really disallowed?), but even if I were,
| it doesn't seem closely related to the TLS problem.  I don't see how
| solving your case would help (not that I understand what solving it
| might mean).
| 
| > Extrapolating to a multi-thread mode isn't just changing a word.
| 
| BTW, aren't we wildly OT discussing this here?  Shouldn't it go to a
| committee reflector or comp.std.c++?

Just as OT as the original request for comment.  But, in effect, I
do -not- think that the original request for comment is OT on this list.
To some extent, Boost has components for multi-threading (which is an
extension to the language) and I do not believe that each time we
need to discuss interaction of that extension with the standard
language we ought to leave Boost lists.  

I do not have strong feeling about moving the discussion to the
committee reflector (where the original question was asked).

-- Gaby