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
