Boost logo

Boost :

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.

-- Gaby


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk