Re: Is the vptr at the beginning of an object?
* DaveB:
Bo Persson wrote:
DaveB wrote:
James Kanze wrote:
On Apr 3, 1:40 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* red floyd:
On 4/2/2010 2:12 PM, DaveB wrote:
[insult to a member of the Committee redacted]
*PLONK*
Well, there was a bit of insult, true.
On the other hand, I fail to see what James' state as a member
of the standardization committee has to do with anything.
I don't think it does (especially since I haven't been
particularly active lately). On the other hand, calling an
accurate and precise description of the issues "technical
gibberish" gives a very good idea of the competence (technical
and otherwise) of the poster. One gets the feeling that he
prefers to ignore real issues.
The question remains open. Maybe someone NOT in the priesthood of
technobabblery can answer it.
I think we have already seen the answer:
In some cases it might be that a vptr is the first member of an
object. The only exception is when it is not, or when there isn't
exactly one vptr in the object.
I didn't see that one, and it points the direction to the answer I was
looking for. I was looking for someone who knows about a number of
"mainstream" compilers and can expound on the implementations of vptrs in
those. The assumption, or hope, being that "all" compilers use vptrs
rather than some other way. I asked more generally than I needed to know,
but the added information from someone who had it was easy enough to ask
for. Particularly, though, I wanted to know about gcc because between
that and VC, I my target platform is covered by those 2, and I am using
PLATFORM loosely here. I don't use multiple inheritance and am not
worried about anything strange happening in some remote corner case, and
if I was, I would have given more information than just "where is that
dang vptr!?". What I am doing that makes me need that information is not
relevant, and none of anyone's business unless I volunteer it. For
someone (not you in this post) to say that the question has been finely
answered, while I still have not the information I solicited, is pompous,
or at least seems so with a high degree of certainty, not to let a
sleeping dog alone, of course.
What the real problem is, is relevant, believe or not.
For example, if you're trying to reinvent COM or XCOM, then you can leverage the
guarantees that the compilers that support COM provide. It's slightly off topic
in this group but hey. No problem, except that going into details about that
would be ungood if that's not what you're trying to do.
For another example, if you're trying to somehow dynamically change an object's
type, then we can suggest less braindead alternatives. Yes, it's braindead. I've
actually worked with people who tried that, although it was in Visual Basic.
They also did other very braindead things, such as one DLL per class, with lots
and lots of classes. Of course they only asked me for help *after* they'd done
these silly things, when the consequences had really started to bite them.
Cheers & hth.,
- Alf