David Abrahams <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > David Abrahams <[EMAIL PROTECTED]> writes: | > | > | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | > | | > | > However, my point is that | > | > | > | > * a class is closed: that is, by the time you put the closing brace, | > | > the "offset" of the data member is a compile-time constant. | > | > | > | > * the number of thread local variables is potentially unbounded, | > | > meaning that, using your analogy, the offset of the corresponding | > | > data-member is not known by the time the compiler finishes | > | > processing a given translation unit. | > | | > | OK... is that a problem? | > | > As I'm understanding the issue, yes. I would love to be proved wrong. | > | > | The address of a static global is not known | > | when the compiler finishes processing a given translation unit either. | > | > Sure the logical address is known. | > | > As opposed to the address of a variable with a TLS. | | It has just one "logical address", which will turn out to correspond | to different physical addresses depending on the thread executing at | the time. When the implementation handles it at compile-time, it uses | only the logical address. At the compile-time/runtime boundary the | logical address is converted to a physical address by dereferencing | off the base TLS pointer. This is just like a data member pointer. I | still don't see a problem.
The problem has to do with the "dependency on the address depending on the thread executing at the time". Either you're assuming you've an unspoken extended definition of the C++ types as currently defined or the analogy you're attempting with address of data members ought to be better technically supported. -- Gaby _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
