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

Discussion in 'C++' started by bob the builder, Jan 17, 2008.

  1. 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?
     
    bob the builder, Jan 17, 2008
    #1
    1. Advertising

  2. bob the builder

    anon Guest

    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.
     
    anon, Jan 17, 2008
    #2
    1. Advertising

  3. Re: Can i get the class of an object of which i only have theaddress?

    On 17 jan, 12:53, anon <> wrote:
    > 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?
     
    bob the builder, Jan 17, 2008
    #3
  4. bob the builder

    Ondra Holub Guest

    Re: Can i get the class of an object of which i only have theaddress?

    On 17 Led, 12:44, 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?


    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.
     
    Ondra Holub, Jan 17, 2008
    #4
  5. Re: Can i get the class of an object of which i only have theaddress?

    On 17 jan, 14:33, Ondra Holub <> wrote:
    > On 17 Led, 12:44, 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?

    >
    > 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.
     
    bob the builder, Jan 17, 2008
    #5
  6. 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
     
    Tomás Ó hÉilidhe, Jan 17, 2008
    #6
  7. Re: Can i get the class of an object of which i only have the address?

    bob the builder wrote:
    > On 17 jan, 14:33, Ondra Holub <> wrote:
    >> 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.
     
    Phil Endecott, Jan 17, 2008
    #7
  8. bob the builder

    Salt_Peter Guest

    Re: Can i get the class of an object of which i only have theaddress?

    On Jan 17, 8:48 am, bob the builder <> wrote:
    > On 17 jan, 14:33, Ondra Holub <> wrote:
    >
    >
    >
    > > On 17 Led, 12:44, 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?

    >
    > > 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.
     
    Salt_Peter, Jan 17, 2008
    #8
  9. bob the builder

    red floyd Guest

    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.
     
    red floyd, Jan 17, 2008
    #9
  10. bob the builder

    Guest

    red floyd wrote:

    > 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.


    Hm, you make it sound as though the paragraph is a justification of the
    initial "Wrong". However, upon closer examination, it turns out that it
    isn't: Tomás Ó hÉilidhe makes it very clear that the standard does not
    necessitate a v-table implementation; he just claims that this
    implementation happens to be chosen by all C++ implementations. In order to
    argue that he is wrong you need to name an implementation that does not use
    a v-table implementation.

    Also, the standard does not define "portable". In particular, should Tomás Ó
    hÉilidhe be correct in the assesment that _all_ implementations use a
    v-table, then code assuming that might be portable (in the obvious sense
    that it works as documented/expected without change on all platforms). An
    example of such code could be this:

    template < typename T >
    class is_polymorphic {

    struct D : public T {
    virtual ~D (void ) {}
    };

    public:

    static bool const value = ( sizeof(T) == sizeof(D) );

    };

    It is based upon the idea that making the destructor virtual would increase
    the size of a non-polymorphic class. Your claim that such code is not
    portable could be empirically false (at least with regard to this instance
    and according to my understanding of "portable" which might be different
    from yours). All we can say a priory is that such code relies upon behavior
    not determined by the standard.


    Best

    Kai-Uwe Bux
     
    , Jan 17, 2008
    #10
  11. 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
     
    Tomás Ó hÉilidhe, Jan 17, 2008
    #11
  12. 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
     
    Tomás Ó hÉilidhe, Jan 17, 2008
    #12
  13. bob the builder

    red floyd Guest

    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.
     
    red floyd, Jan 17, 2008
    #13
  14. bob the builder

    Jack Klein Guest

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

    On Thu, 17 Jan 2008 14:10:47 GMT, Phil Endecott
    <> wrote in comp.lang.c++:

    > bob the builder wrote:
    > > On 17 jan, 14:33, Ondra Holub <> wrote:
    > >> 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.h> and/or <cstdint> is 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
     
    Jack Klein, Jan 18, 2008
    #14
  15. 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
     
    Tomás Ó hÉilidhe, Jan 18, 2008
    #15
  16. In message <17Ojj.89756$>, red floyd
    <> writes
    >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.


    Your objection was morally, if not literally, valid -- just change a
    couple of words:

    "Wrong. Virtual functions *may be* achieved by a unique vtable. Nothing
    in the Standard mandates it. Any code that accesses a vtable is by
    definition non-portable."
    >
    >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.


    I can do better than that. There exists at least one implementation
    using vtables, in which objects of the same class may contain vtable
    pointers that depend on where the object was constructed (the compiler
    may generate one vtable per translation unit, rather than a single one
    for the entire program.)

    Thus, even when a vtable is used, one cannot assume that type equality
    implies equality of the vtable pointers.

    And, of course, regardless of whether it exists or is unique, any code
    which attempts to _access_ an object's vtable pointer is going to be
    non-portable from the start.

    --
    Richard Herring
     
    Richard Herring, Jan 24, 2008
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?cmdyYW5kaWRpZXI=?=

    Can I have base class derived from System.Web.UI.Page have design

    =?Utf-8?B?cmdyYW5kaWRpZXI=?=, Jul 22, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    516
    Patrice
    Jul 22, 2005
  2. okaminer
    Replies:
    3
    Views:
    314
    okaminer
    Aug 1, 2005
  3. somez72
    Replies:
    4
    Views:
    4,404
    Roedy Green
    May 3, 2004
  4. Replies:
    33
    Views:
    906
  5. junyangzou
    Replies:
    8
    Views:
    196
    junyangzou
    Aug 30, 2013
Loading...

Share This Page