Re: Template technicality - What does the standard say?
On Oct 15, 1:33 pm, Stephen Horne <sh006d3...@blueyonder.co.uk> wrote:
On Wed, 15 Oct 2008 01:54:32 -0700 (PDT), James Kanze
<james.ka...@gmail.com> wrote:
On Oct 15, 7:03 am, Stephen Horne <sh006d3...@blueyonder.co.uk> wrote:
On Wed, 15 Oct 2008 16:30:54 +1300, Ian Collins
<ian-n...@hotmail.com> wrote:
Now, create two instances of TEST. Don't care where you
instantiate so long as you aren't using any further
inheritance - global, local, normal member, static member,
anything.
You've suddenly introduced some new, unrealistic constraints.
How so? In my container library, why would some other code be
creating nodes that inherit my private node type? That would
be absurd.
Who cares about what your container library might do? A
container library has no need of offsetof. We're talking about
why offsetof is not defined and not implementable in the general
case. And in the general case, you have to handle base classes
correctly.
These are the exact constraints I described from the start.
You never described any real constraints. The fact remains that
they are artificial constraints.
The standard can't be based on such things. If the standard
says it works, then it has to work.
You won't find one. The layout of the class isn't dynamic.
The layout is dynamic. It depends on the context where the
class is used. You can't get around that by saying you don't
want to consider such contexts.
class M isn't class D - they are different classes,
irrespective of the fact that one inherits the other.
But the existance of a class M doesn't mean that class D ceases
to exist. And either offsetof( D, x ) returns a correct result,
constant and for all instances of D, or it can't be supported.
The layout for either one is fixed.
The layout of M isn't fixed. It varies depending on how M is
used.
As for not considering your irrelevant contexts, what the hell
do you expect. Inheritance has nothing to do with offsetof.
Agreed. The committee didn't want to open up that hornets'
nest, so they restricted offsetof to PODS. And a PODS cannot
inherit, much less virtually.
To offsetof, any struct or class is just itself - not a
representative of a family. Just as it always was.
Why the hell should I consider your invented fantasy issues?
Because they're real issues, and it's necessary to address them
if you want to support offsetof for non-PODS.
Of course if someone is confusing the term "offset" with
"member"...
Let me give you a clue. The word offset refers to the layout
of the struct/class.
And a class which derives from another class virtually doesn't
have a fixed layout.
Can you imagine any vaguely coherent reason why a
compiler-writer would choose to introduce pointless
nondeterminism like this?
It's not nondeterminism, but it does depend on the context in
which the class is used. Given the arguments to offsetof,
the compiler does not have enough information to determine
that context.
No it doesn't, because we are talking about a field within a
known struct, not within an instance of some unknown
dynamically-accessed struct.
Exactly. We're talking about a field in M. Whose position
changes depending on how you use M.
We always were right from the start. Its all we *could* have
been talking about, since offsetof doesn't know *ANYTHING*
about instances at all - it only ever sees types and
field-names.
Which is why it is restricted to PODS, which do have constant
offsets, known to the compiler.
[...]
But even for that, lets face it - most people would call
virtual inheritance a niche tool at best,
It's widely used, and vitally necessary for many things.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34