Topic: Is name __vptr standard?
Author: clamage@Eng (Steve Clamage)
Date: 1998/07/25 Raw View
claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=) writes:
>Hans Aberg <haberg@REMOVE.matematik.su.se> schrieb:
>> The question is: Is this name "__vptr" of the pointer to the vtbl in the
>> C++ standard, or can it vary between the compilers?
>The standard explicitly reserves variables starting with two underscores
>for implementation-defined extentions. So no, it can't be standard.
Nothing prevents the standard from specifying standard names
that start with two underscores. In fact the standard does
specify such names and what they mean: __cplusplus, __FILE__, and
__LINE__, to pick just three.
As it happens, the standard has nothing to say about vtables,
and does not specify the name "__vptr". That just a datum,
not a rule.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/07/23 Raw View
In article <6p4i6g$6bd$1@nnrp1.dejanews.com>, daasb@rwg.de wrote:
>I must admit that I still haven't understood what You want to
>accomplish.
See the thread "Re: Dynamic cast of virtual function pointers".
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/07/23 Raw View
In article <6p4i6g$6bd$1@nnrp1.dejanews.com>, daasb@rwg.de wrote:
>- Put each method You want to evaluate in a different interface
> class and use multiple inheritance. Here is some sample code
> to get the idea (just a sketch):
>
> //---------------------------------------------------------
> #include <map>
Your idea of putting the function pointers in an associative container
that supports unique keys on strings is correct though, in the sense that
fully carried out, it will eventually lead to a class Class, just as in
Java.
The difference though is that the Java Virtual Machine knows how to
convert those string lookups to offsets if needed often.
So if one should do something that is not very slow, it is more
reasonable to work directly with virtual function pointers that are
evaluated.
But it is the idea of replacing the failings of C++ with ones owns vtbl
you are into there. It would be great if that could be avoided unless
absolutely necessary.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)
Date: 1998/07/25 Raw View
Hans Aberg <haberg@REMOVE.matematik.su.se> schrieb:
> The question is: Is this name "__vptr" of the pointer to the vtbl in the
> C++ standard, or can it vary between the compilers?
The standard explicitly reserves variables starting with two underscores
for implementation-defined extentions. So no, it can't be standard.
--
Claus Andre Faerber <http://www.muc.de/~cfaerber/> fax: +49-8061-3361
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: daasb@rwg.de
Date: 1998/07/22 Raw View
In article <haberg-2107981007180001@sl41.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
>
> In article <6p0j98$259$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
>
[snip]
>
> >Please give an example where this technique has been used.
>
> Say you have
> class B {
> public:
> virtual D b(D&);
> };
>
> class C : public B {
> public:
> D b(D&)
> virtual c(D&);
> };
> Then, when two dynamic objects f, x are evaluating f(x), x may return c of
> class C to f. If then f points at an object of class C (or a derived
> class), then there is no problem, but if f points at an object of class B,
> then it jumps off the vtbl. However, if that happens, the action of the
> program is known, say b should be used instead.
>
> One way around this problem is to always add c to the class B whenever a
> new class C with a new virtual function is added, but then it is not
> possible to build libraries, and an enormous compile time is wasted: Every
> dynamic object needs one or two classes, so the number of classes in the
> program becomes very large.
>
I must admit that I still haven't understood what You want to
accomplish.
Maybe it becomes clearer if You show how You would like to code
the evaluation function in C++.
But anyway I try some suggestions:
- Put each method You want to evaluate in a different interface
class and use multiple inheritance. Here is some sample code
to get the idea (just a sketch):
//---------------------------------------------------------
#include <map>
// Define an interface class for each method You
// want to evaluate
// this one for method b
class Intf_b
{
public:
// calls the method
static void call( Intf_b* obj )
{
obj->b();
};
// method name as string
static const char* methodName;
// the method itself
virtual void b() = 0;
};
const char* Intf_b::methodName = "b";
// the same for method c
class Intf_c
{
public:
static void call( Intf_c* obj )
{
obj->c();
};
static const char* methodName;
virtual void c() = 0;
};
const char* Intf_c::methodName = "c";
// this is the base class of all "dynamic" classes
class D
{
public:
virtual ~D(){};
};
// each class has to inherit from the
// interface classes it supports
class B : public virtual D, public virtual Intf_b {
public:
virtual void b()
{
cout << "B::b" << endl;
}
};
class C : public virtual B, public virtual Intf_c {
public:
virtual void b()
{
cout << "C::b" << endl;
}
virtual void c()
{
cout << "C::c" << endl;
}
};
// now we need helper objects for our
// methods
class MethodCallBase
{
public:
// gets the method name
virtual const char* name() = 0;
// tests if You can call this method on obj
virtual bool hasMethod( D* obj ) = 0;
// calls this method on obj
virtual void callMethod( D* obj ) = 0;
};
template < class Interface >
class MethodCall : public MethodCallBase
{
virtual const char* name()
{
return Interface::methodName;
}
virtual bool hasMethod( D* obj )
{
return ( dynamic_cast<Interface>( obj ) != 0 );
}
virtual void callMethod( D* obj )
{
Interface::call( dynamic_cast<Interface>( obj ) );
}
};
// the Evaluator holds a map of MethodCall objects.
// new methods have to be added before they can
// be evaluated.
class Evaluator
{
public:
void addMethod( MethodCallBase* newMethod )
{
methodMap[newMethod->name()] = newMethod;
}
void evaluate( D* obj, const char* methodName )
{
MethodCallBase* mc = methodMap[methodName];
if ( mc-hasMethod( obj ) )
mc->callMethod( obj );
else
/* default handling */;
}
private:
map< const char*, MethodCallBase* > methodMap;
};
int main()
{
// we need an evaluator
Evaluator myEvaluator;
// we can call b or c
MethodCall<Intf_b> call_b;
MethodCall<Intf_c> call_c;
myEvaluator.addMethod( &call_b );
myEvaluator.addMethod( &call_c );
C sample1;
B sample2;
// call b on object sample1
myEvaluator.evaluate( &c, Intf_b::methodName );
// call c on object sample2
myEvaluator.evaluate( &c, Intf_c::methodName );
return 0;
}
//-----------------------------------------------------
If You make the evaluator a singleton, then new libraries
can add their MethodCall objects to it (that way You
could add new methods to the system even at runtime with DLLs).
- If this is not enough You may have to invent Your own
(small scale) typesystem. See the "Type Object" pattern in
"Pattern Languages of Program Design 3".
- It may well be that C++ ist not the suitable language for
Your goal. Try another one! ;-)
Hope it helps!
Wolf
p.s.: the tone of some of Your answers seemed not appropriate
to me. You may not like every advice You get if You ask
for help, but that's no reason to get personal.
Often the advices You dislike most are the most valuable ones.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/07/21 Raw View
In article <6p0j98$259$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
>In article <haberg-2007981318080001@sl51.modempool.kth.se>,
>> It is not a temptation really :-), but the need for implememting dynamic
>> features.
..
>It's not tempting because you're already doing it?
If I could avoid it, I would do so of course, but I know what my program
should do, and that is how encountered the feature.
>..But what are you going for, here? What are
>these "dynamic features" you're trying to implement?
See "Re: Dynamic cast of virtual function pointers".
> I suspect
>that some of the regular posters to this newsgroup would be able to
>demonstrate an alternative method of solving the same problem, without
>playing any non-portable tricks on the vtable.
I think these problems are well know to those rying to implement dynamic
feature using C++.
>Please give an example where this technique has been used.
Say you have
class B {
public:
virtual D b(D&);
};
class C : public B {
public:
D b(D&)
virtual c(D&);
};
Then, when two dynamic objects f, x are evaluating f(x), x may return c of
class C to f. If then f points at an object of class C (or a derived
class), then there is no problem, but if f points at an object of class B,
then it jumps off the vtbl. However, if that happens, the action of the
program is known, say b should be used instead.
One way around this problem is to always add c to the class B whenever a
new class C with a new virtual function is added, but then it is not
possible to build libraries, and an enormous compile time is wasted: Every
dynamic object needs one or two classes, so the number of classes in the
program becomes very large.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/07/21 Raw View
In article <7xNs1.28$DF4.706687@cam-news-reader1.bbnplanet.com>, Barry
Margolin <barmar@bbnplanet.com> wrote:
>Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
>> It is not a temptation really :-), but the need for implememting dynamic
>>features. Clearly, the ability to implement dynamic features is one of the
>>weak points of C++. One might hope the language is improved in that
>>respect in the future.
>
>It doesn't seem like the kind of thing you're trying to do is in the spirit
>of C++. C++ includes some dynamic features, but it strives for static type
>safety. If you want more dynamic features, you're expected to implement
>themselves using the existing RTTI.
I think you have misunderstood the language C++: The purpose of C++ is
allowing the programmer doing the job. Static constructs give faster
runtime as the structure describing them can be thrown away, and static
typing help the runtime becoming correct. Dynamic implementing also uses
static constructs because it is fast, but C++ is somewhat limited in
helping you doing the job.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/21 Raw View
In article <6p0j98$259$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote:
> In article <haberg-2007981318080001@sl51.modempool.kth.se>,
> haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> > In article <6otakk$ql1@engnews1.Eng.Sun.COM>, stephen.clamage@sun.com
> > (Steve Clamage) wrote:
> > >You were using a name to reference the (or a) vtable pointer.
> > >If you didn't have a name, you would also have the problem
> > >of locating the pointer. Even if a class has only one pointer,
> > >it might be at a negative offset from the object pointer, at
> > >a zero offset, or following the class allocated at the zero
> > >offset.
> >
> > It is not a temptation really :-), but the need for implememting dynamic
> > features. Clearly, the ability to implement dynamic features is one of the
> > weak points of C++. One might hope the language is improved in that
> > respect in the future.
>
> It's not tempting because you're already doing it?
>
> Please give an example where this technique has been used. I suspect
> that some of the regular posters to this newsgroup would be able to
> demonstrate an alternative method of solving the same problem, without
> playing any non-portable tricks on the vtable.
Not that I approve, but Coplien has some examples of this.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/07/21 Raw View
Hans Aberg wrote:
[...]
> The question is: Is this name "__vptr" of the pointer to the vtbl in the
> C++ standard, or can it vary between the compilers?
Not only the name is not standard; even the vtbl isn't. While I don't
know a compiler which doesn't use a vtbl, any compiler would be allowed
to use any mechanism it likes as long as the result was the one the
standard demands for every conforming program.
Of course, an implementation that stored all function pointers
themselves
inside the object would not sell well, but it would be allowed.
As well as would some advanced techniques which are so ingenious that
no one even got close to think of them yet.
[...]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/07/19 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>I have found that on my compiler the call
> (bp->*g)();
>can also be done by
> (*(bp->__vptr[1]))();
>(Also see ARM 1994, 10.7c, p 228.)
> The question is: Is this name "__vptr" of the pointer to the vtbl in the
>C++ standard, or can it vary between the compilers?
The implementation of virtual functions and how they are called
is unpsecified by the standard. Compilers vary widely in how
they implement virtual function calls. On the compilers I am
familiar with, there is no user-accessible name by which you
could locate a pointer to (any of) the vtable(s) for a class.
On some implemenations, a class with N direct base classes (N>=1)
has N-1 extra vtable pointers. On some, there is only one
vtable pointer, and the vtable contains the extra pointers.
(Multiple vtables are needed, but how you find them varies.)
In some vtable implementations there is an extra field to provide
any adjustment to "this" needed in the virtual call. Some do not
have the extra field, and the address in the vtable goes to an
extra piece of code that adjusts "this" before jumping to the
virtual function.
You were using a name to reference the (or a) vtable pointer.
If you didn't have a name, you would also have the problem
of locating the pointer. Even if a class has only one pointer,
it might be at a negative offset from the object pointer, at
a zero offset, or following the class allocated at the zero
offset.
The virtual function mechanism is intentionally hidden from
the programmer precisely to remove the temptation to use it
directly. If you manage to write such code, it is unlikely
to work on more than one implementation.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1998/07/20 Raw View
In article <haberg-1907980208130001@sl100.modempool.kth.se>,
Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
> The question is: Is this name "__vptr" of the pointer to the vtbl in the
>C++ standard, or can it vary between the compilers?
Nothing about the virtual function table implementation is specified in the
standard.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/20 Raw View
Hans Aberg wrote:
>
> A follow-up question to "Dynamic cast of virtual function pointers":
>
> I have found that on my compiler the call
> (bp->*g)();
> can also be done by
> (*(bp->__vptr[1]))();
> (Also see ARM 1994, 10.7c, p 228.)
>
> The question is: Is this name "__vptr" of the pointer to the vtbl in the
> C++ standard, or can it vary between the compilers?
>
No. The standard does not require the use of vtables, much less
standardize any convention for accessing them. Some compilers let you do
this, but it's purely an extension.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@fermi.ceg.uiuc.edu (Siemel Naran)
Date: 1998/07/20 Raw View
>No. The standard does not require the use of vtables, much less
>standardize any convention for accessing them. Some compilers let you do
>this, but it's purely an extension.
An evil extension!!
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/07/20 Raw View
In article <6otakk$ql1@engnews1.Eng.Sun.COM>, stephen.clamage@sun.com
(Steve Clamage) wrote:
>You were using a name to reference the (or a) vtable pointer.
>If you didn't have a name, you would also have the problem
>of locating the pointer. Even if a class has only one pointer,
>it might be at a negative offset from the object pointer, at
>a zero offset, or following the class allocated at the zero
>offset.
It is not a temptation really :-), but the need for implememting dynamic
features. Clearly, the ability to implement dynamic features is one of the
weak points of C++. One might hope the language is improved in that
respect in the future.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/21 Raw View
In article <haberg-2007981318080001@sl51.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> In article <6otakk$ql1@engnews1.Eng.Sun.COM>, stephen.clamage@sun.com
> (Steve Clamage) wrote:
> >You were using a name to reference the (or a) vtable pointer.
> >If you didn't have a name, you would also have the problem
> >of locating the pointer. Even if a class has only one pointer,
> >it might be at a negative offset from the object pointer, at
> >a zero offset, or following the class allocated at the zero
> >offset.
>
> It is not a temptation really :-), but the need for implememting dynamic
> features. Clearly, the ability to implement dynamic features is one of the
> weak points of C++. One might hope the language is improved in that
> respect in the future.
It's not tempting because you're already doing it?
Please give an example where this technique has been used. I suspect
that some of the regular posters to this newsgroup would be able to
demonstrate an alternative method of solving the same problem, without
playing any non-portable tricks on the vtable.
In particular, you seem to be trying to do something like this:
struct B { /* ... */ };
struct C : public B { virtual int func_c(); };
struct D : public B { virtual int func_d(); };
void global(C*);
// ...
void another_func() {
D d;
global((C*)&d); // Call with D* disguised as C*
}
// ...
void global(C*cptr) {
if (/* something */) {
// cptr is really a D*, treat it as such
cptr->*__vtbl[1](); // Calls D::func_d();
}
}
If I am right about this, then you should change global() to accept
a B* instead of a C*:
struct B { virtual int func_c(); virtual int func_d(); };
struct C : public B { virtual int func_c(); };
struct D : public B { virtual int func_d(); };
void global(B*);
// ...
void another_func() {
D d;
global(&d);
}
// ...
void global(B*bptr) {
if ( /* something */ ) {
bptr->func_d();
}
}
If func_d cannot or should not be declared in B, there are ways of
handling this as well. But what are you going for, here? What are
these "dynamic features" you're trying to implement?
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1998/07/21 Raw View
In article <haberg-2007981318080001@sl51.modempool.kth.se>,
Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
> It is not a temptation really :-), but the need for implememting dynamic
>features. Clearly, the ability to implement dynamic features is one of the
>weak points of C++. One might hope the language is improved in that
>respect in the future.
It doesn't seem like the kind of thing you're trying to do is in the spirit
of C++. C++ includes some dynamic features, but it strives for static type
safety. If you want more dynamic features, you're expected to implement
themselves using the existing RTTI.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/07/19 Raw View
A follow-up question to "Dynamic cast of virtual function pointers":
In the code
class B;
typedef int (B::*Bf)();
class B {
public:
virtual int f();
};
class C : public B {
public:
int f();
virtual int g();
};
and in the code
Bf g = C::g;
B* bp = new C();
I have found that on my compiler the call
(bp->*g)();
can also be done by
(*(bp->__vptr[1]))();
(Also see ARM 1994, 10.7c, p 228.)
The question is: Is this name "__vptr" of the pointer to the vtbl in the
C++ standard, or can it vary between the compilers?
(My original question could be answered affirmatively by implementing a
variable so that say bp->__vpbl_size or something would give the size of
the vtbl that this object uses.)
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]