From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2003-02-21 09:48:57
David Abrahams <dave_at_[hidden]> writes:
| Gabriel Dos Reis <gdr_at_[hidden]> writes:
| > David Abrahams <dave_at_[hidden]> writes:
| > | Gabriel Dos Reis <gdr_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk