David Abrahams <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost