Can i get the class of an object of which i only have the address?

[bob the builder]

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

[anon]

bob the builder wrote:

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

No, having only the address, you can not know type of the object at that
address.

[bob the builder]

On 17 jan, 12:53, anon <[e-mail]:

bob the builder wrote:

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

No, having only the address, you can not know type of the object at that
address.

what a pitty... There isnt some kind of dirty hack to do it?

[Ondra Holub]

On 17 Led, 12:44, bob the builder <[e-mail]:

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

With some modification you can achieved what you need.

If all candidate classes have 1 common parent class, you can try to
dynamic_cast it to derived class type.

class Base { };
class AClass: public Base { };
class BClass: public Base { };

// ...

Base* ptr = ...; // Get the pointer from somewhere
AClass* aptr = dynamic_cast<AClass*>(ptr);
if (aptr != 0)
{
// ptr points to AClass or class derived from AClass
}

Note: If you have hierarchy of classes, you have to check child
classes and then their parents.

Note 2: Storing pointers in integer variables is bad idea. Many
programs are not portable to other platforms, because their author
supposed, that pointer has the same size as integer.

Note 3: In well designed project you will not need any stuff mentioned
above.

[bob the builder]

On 17 jan, 14:33, Ondra Holub <[e-mail]:

On 17 Led, 12:44, bob the builder <[e-mail]:

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

With some modification you can achieved what you need.

If all candidate classes have 1 common parent class, you can try to
dynamic_cast it to derived class type.

class Base { };
class AClass: public Base { };
class BClass: public Base { };

// ...

Base* ptr = ...; // Get the pointer from somewhere
AClass* aptr = dynamic_cast<AClass*>(ptr);
if (aptr != 0)
{
* * // ptr points to AClass or class derived from AClass

}

Note: If you have hierarchy of classes, you have to check child
classes and then their parents.

Note 2: Storing pointers in integer variables is bad idea. Many
programs are not portable to other platforms, because their author
supposed, that pointer has the same size as integer.

Note 3: In well designed project you will not need any stuff mentioned
above.

Thank you, i didnt realize Note 2.

About Note 3, it isnt really a project. i only need a dirty hack.

[=?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?=]

bob the builder:

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

Well I've been more of a C programmer for the last few years but here's my
thinking on it:

Virtual functions are achieved via a V-Table. That is, each object has a
hidden pointer in it that points to a static structure that contains
function pointers. (The Standard doesn't necessitate that this is how it's
done, but this *is* how it's done).

Anyway, if you had an object and if you knew it had virtual functions (or
that its parents had virtual functions) then you could just compare the V-
Table address to the addresses of all other V-Table structures.

Of course, standard C++ provides no means of extracting the V-Table
pointer, but I'm not sure it might have something like "typeid" or
"typeof" for doing this. It's been a few years since I did C++, I'm rusty
on stuff like this.

--
Tomás Ó hÉilidhe

[Phil Endecott]

bob the builder wrote:

On 17 jan, 14:33, Ondra Holub <[e-mail]:

>Note 2: Storing pointers in integer variables is bad idea. Many
programs are not portable to other platforms, because their author
supposed, that pointer has the same size as integer.

Thank you, i didnt realize Note 2.

There's a type called intptr_t in stdint.h (and presumably cstdint) that
is an integer type guaranteed to be the same size as a pointer.

[Salt_Peter]

On Jan 17, 8:48 am, bob the builder <[e-mail]:

On 17 jan, 14:33, Ondra Holub <[e-mail]:

On 17 Led, 12:44, bob the builder <[e-mail]:

Can i get the class of an object of which i only have the address?

Lets say i have 3 classes: AClass,BClass,CClass.
i also have an object of each class: aObject, bObject, cObject
And finally i have an integer: integerX.

Now i let let intergerX be the address of one of the objects (aObject,
bObject or cObject) but i dont know which.
Can get the class of the object at the address contained in integerX?
and how?

With some modification you can achieved what you need.

If all candidate classes have 1 common parent class, you can try to
dynamic_cast it to derived class type.

class Base { };
class AClass: public Base { };
class BClass: public Base { };

// ...

Base* ptr = ...; // Get the pointer from somewhere
AClass* aptr = dynamic_cast<AClass*>(ptr);
if (aptr != 0)
{
// ptr points to AClass or class derived from AClass

}

Note: If you have hierarchy of classes, you have to check child
classes and then their parents.

Note 2: Storing pointers in integer variables is bad idea. Many
programs are not portable to other platforms, because their author
supposed, that pointer has the same size as integer.

Note 3: In well designed project you will not need any stuff mentioned
above.

Thank you, i didnt realize Note 2.

About Note 3, it isnt really a project. i only need a dirty hack.

Why hack when you can keep it simple?
An integer can't store the adress of an object. Thats true even if on
your particular platform: a pointer happens to occupy the same size as
a pointer. On mine its not (64 bit) - not that it matters. An integer
is not an address. A pointer is not just some value/number - it also
implies a type. Would be funny if a program was to delete/deallocate
an integer instead of the complex object (can you say memory leak?).

You could employ a RTTI where typeid( *p ).name() returns the type
stored at a given pointer p. That, however assumes you've got
polymorphism (at least one virtual function). Here is an example using
boost::shared_ptr:

#include <iostream>
#include <vector>
#include <typeinfo>
#include <algorithm>
#include "boost/shared_ptr.hpp"

class A { virtual void foo() { } };
class B : public A { };
class C : public A { };

template< typename T = A >
struct TypeName
{
void operator()(boost::shared_ptr< T >& bsp)
{
std::cout << typeid(*(bsp)).name() << std::endl;
}
};

int main()
{
typedef boost::shared_ptr< A SharedPtrA;
std::vector< SharedPtrA va;
va.push_back(SharedPtrA(new A));
va.push_back(SharedPtrA(new B));
va.push_back(SharedPtrA(new C));

std::for_each(va.begin(), va.end(), TypeName< >());
}
/* your output will vary
1A
1B
1C
*/

As already noted elsewhere, such a design is usually unneccessary and
often indicative of a design issue.
Hacking sucks.
The objects already know what their dynamic type is.
You might as well have each type do_the_foo() in whatever way they
do_the_foo (overide foo() where and if needed).

class A { virtual void foo() { } };
class B : public A { void foo() { } };
class C : public A { void foo() { } };
int main()
{
...
// i don't care which one of the above you might be, just
do_the_foo()
p_a->foo();
...
}

It doesn't get any simpler.

[red floyd]

Tomás Ó hÉilidhe wrote:

Virtual functions are achieved via a V-Table. That is, each object has a
hidden pointer in it that points to a static structure that contains
function pointers. (The Standard doesn't necessitate that this is how it's
done, but this *is* how it's done).

Wrong. Virtual functions *may be* achieved by a vtable. Nothing in the
Standard mandates it. Anything code that assumes a vtable is by
definition non-portable.

[=?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?=]

red floyd:

>Virtual functions are achieved via a V-Table. That is, each object
has a hidden pointer in it that points to a static structure that
contains function pointers. (The Standard doesn't necessitate that
this is how it's done, but this *is* how it's done).

Wrong. Virtual functions *may be* achieved by a vtable. Nothing in
the Standard mandates it. Anything code that assumes a vtable is by
definition non-portable.

List of things I didn't claim:

* The sky is yellow
* Dogs can breathe under water
* The Standard mandates that virtual functions must be achieved via a V-
Table
* Eating mints will make you pass a breath test
* Dublin is the capital of Italy

Hopefully one of these non-claims will clarify the issue you take.

--
Tomás Ó hÉilidhe

[=?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?=]

jkh:

Tomás Ó hÉilidhe makes it very clear that the standard
does not necessitate a v-table implementation.

Thanks, at least someone was listening.

--
Tomás Ó hÉilidhe

[red floyd]

Tomás Ó hÉilidhe wrote:

red floyd:

>>Virtual functions are achieved via a V-Table. That is, each object
has a hidden pointer in it that points to a static structure that
contains function pointers. (The Standard doesn't necessitate that
this is how it's done, but this *is* how it's done).

Wrong. Virtual functions *may be* achieved by a vtable. Nothing in
the Standard mandates it. Anything code that assumes a vtable is by
definition non-portable.

List of things I didn't claim:

* The sky is yellow
* Dogs can breathe under water
* The Standard mandates that virtual functions must be achieved via a V-
Table
* Eating mints will make you pass a breath test
* Dublin is the capital of Italy

Hopefully one of these non-claims will clarify the issue you take.

Yeah, I missed the bit. My mistake.

I can, however, imagine a (not very efficient) vtable-less
implementation, where each object carries an internal pointer for *each*
virtual function, thus obviating the need for a vtable. In such a
hypothetical implementation, any vtable based assumptions go out the window.

[Jack Klein]

On Thu, 17 Jan 2008 14:10:47 GMT, Phil Endecott
<sp*******************@chezphil.orgwrote in comp.lang.c++:

bob the builder wrote:

On 17 jan, 14:33, Ondra Holub <[e-mail]:

Note 2: Storing pointers in integer variables is bad idea. Many
programs are not portable to other platforms, because their author
supposed, that pointer has the same size as integer.

Thank you, i didnt realize Note 2.

There's a type called intptr_t in stdint.h (and presumably cstdint) that
is an integer type guaranteed to be the same size as a pointer.

There are two problems with your suggestion.

The first is that <stding.hand/or <cstdintis not yet actually a
part of standard C++.

The second comes into play when this header does become part of
standard C++, namely that these types are optional. An implementation
is not required to provide either the signed or unsigned version of
this type.

Not exactly a problem, but your description is not accurate. intptr_t
and uintptr_t, on implementations where they exist, are not
"guaranteed to be the same size as a pointer".

Rather, in the words of ISO 9899:1999, each has "the property that any
valid pointer to void can be converted to this type, then converted
back to pointer to void, and the result will compare equal to the
original pointer".

That presumably means that these types must have at least as many
value bits as pointer to void, but it does not mean that they cannot
have more bits and be larger.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[=?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?=]

red floyd:

Yeah, I missed the bit. My mistake.

No probs :-)

I can, however, imagine a (not very efficient) vtable-less
implementation, where each object carries an internal pointer for
*each* virtual function, thus obviating the need for a vtable. In such a
hypothetical implementation, any vtable based assumptions go out the
window.

When I started learning about polymorphism in C++, and when I was told
that it was achieved via function pointers, my first assumption was indeed
that, i.e. that a pointer to every function was held inside the object.
This actually dissuaded me from putting in too many virtual functions!

Then I heard about V-Tables and I was like, yeah, that's actually a
pretty good idea coz then we've only got one pointer in each object.

--
Tomás Ó hÉilidhe