type_info

Discussion in 'C++' started by Rahul, Dec 8, 2007.

  1. Rahul

    Rahul Guest

    Hi Everyone,

    I was working with Run Time Type Information and with typeid
    operator, and so on i tried to create an object of type_info class and
    i'm not able to do so, because of the class design,


    class type_info {
    public:
    _CRTIMP virtual ~type_info();
    _CRTIMP int operator==(const type_info& rhs) const;
    _CRTIMP int operator!=(const type_info& rhs) const;
    _CRTIMP int before(const type_info& rhs) const;
    _CRTIMP const char* name() const;
    _CRTIMP const char* raw_name() const;
    private:
    void *_m_data;
    char _m_d_name[1];
    type_info(const type_info& rhs);
    type_info& operator=(const type_info& rhs);
    };


    the constructor and assignment operator is private, why is it so?

    Thanks in advance!!!
     
    Rahul, Dec 8, 2007
    #1
    1. Advertising

  2. On Dec 8, 10:38 am, Rahul <> wrote:
    > Hi Everyone,
    >
    > I was working with Run Time Type Information and with typeid
    > operator, and so on i tried to create an object of type_info class and
    > i'm not able to do so, because of the class design,
    >
    > class type_info {
    > public:
    > _CRTIMP virtual ~type_info();
    > _CRTIMP int operator==(const type_info& rhs) const;
    > _CRTIMP int operator!=(const type_info& rhs) const;
    > _CRTIMP int before(const type_info& rhs) const;
    > _CRTIMP const char* name() const;
    > _CRTIMP const char* raw_name() const;
    > private:
    > void *_m_data;
    > char _m_d_name[1];
    > type_info(const type_info& rhs);
    > type_info& operator=(const type_info& rhs);
    >
    > };
    >
    > the constructor and assignment operator is private, why is it so?
    >
    > Thanks in advance!!!


    I believe it so closely coupled with usage of typeid operator and the
    specific implementation (by the compiler) that you would not normally
    be able to do anything meaninful with it, even if you could create an
    object of type_info. The only way to get a type_info object is by
    usage of typeid().

    It would be interesting to know, why you want to create an object of
    it?
     
    Abhishek Padmanabh, Dec 8, 2007
    #2
    1. Advertising

  3. Rahul

    Rahul Guest

    On Dec 8, 11:08 am, Abhishek Padmanabh <>
    wrote:
    > On Dec 8, 10:38 am, Rahul <> wrote:
    >
    >
    >
    > > Hi Everyone,

    >
    > > I was working with Run Time Type Information and with typeid
    > > operator, and so on i tried to create an object of type_info class and
    > > i'm not able to do so, because of the class design,

    >
    > > class type_info {
    > > public:
    > > _CRTIMP virtual ~type_info();
    > > _CRTIMP int operator==(const type_info& rhs) const;
    > > _CRTIMP int operator!=(const type_info& rhs) const;
    > > _CRTIMP int before(const type_info& rhs) const;
    > > _CRTIMP const char* name() const;
    > > _CRTIMP const char* raw_name() const;
    > > private:
    > > void *_m_data;
    > > char _m_d_name[1];
    > > type_info(const type_info& rhs);
    > > type_info& operator=(const type_info& rhs);

    >
    > > };

    >
    > > the constructor and assignment operator is private, why is it so?

    >
    > > Thanks in advance!!!

    >
    > I believe it so closely coupled with usage of typeid operator and the
    > specific implementation (by the compiler) that you would not normally
    > be able to do anything meaninful with it, even if you could create an
    > object of type_info. The only way to get a type_info object is by
    > usage of typeid().
    >
    > It would be interesting to know, why you want to create an object of
    > it?


    Nothing really specific, Was just playing around it and i wonder why
    the copy constructor isn't private...
     
    Rahul, Dec 8, 2007
    #3
  4. On Dec 8, 11:55 am, Rahul <> wrote:
    > On Dec 8, 11:08 am, Abhishek Padmanabh <>
    > wrote:
    >
    >
    >
    >
    >
    > > On Dec 8, 10:38 am, Rahul <> wrote:

    >
    > > > Hi Everyone,

    >
    > > > I was working with Run Time Type Information and with typeid
    > > > operator, and so on i tried to create an object of type_info class and
    > > > i'm not able to do so, because of the class design,

    >
    > > > class type_info {
    > > > public:
    > > > _CRTIMP virtual ~type_info();
    > > > _CRTIMP int operator==(const type_info& rhs) const;
    > > > _CRTIMP int operator!=(const type_info& rhs) const;
    > > > _CRTIMP int before(const type_info& rhs) const;
    > > > _CRTIMP const char* name() const;
    > > > _CRTIMP const char* raw_name() const;
    > > > private:
    > > > void *_m_data;
    > > > char _m_d_name[1];
    > > > type_info(const type_info& rhs);
    > > > type_info& operator=(const type_info& rhs);

    >
    > > > };

    >
    > > > the constructor and assignment operator is private, why is it so?

    >
    > > > Thanks in advance!!!

    >
    > > I believe it so closely coupled with usage of typeid operator and the
    > > specific implementation (by the compiler) that you would not normally
    > > be able to do anything meaninful with it, even if you could create an
    > > object of type_info. The only way to get a type_info object is by
    > > usage of typeid().

    >
    > > It would be interesting to know, why you want to create an object of
    > > it?

    >
    > Nothing really specific, Was just playing around it and i wonder why
    > the copy constructor isn't private...- Hide quoted text -
    >


    So that you can return a local object from a function by-value?
     
    Abhishek Padmanabh, Dec 8, 2007
    #4
  5. Rahul wrote:
    >>> ...
    >>> class type_info {
    >>> public:
    >>> _CRTIMP virtual ~type_info();
    >>> _CRTIMP int operator==(const type_info& rhs) const;
    >>> _CRTIMP int operator!=(const type_info& rhs) const;
    >>> _CRTIMP int before(const type_info& rhs) const;
    >>> _CRTIMP const char* name() const;
    >>> _CRTIMP const char* raw_name() const;
    >>> private:
    >>> void *_m_data;
    >>> char _m_d_name[1];
    >>> type_info(const type_info& rhs);
    >>> type_info& operator=(const type_info& rhs);
    >>> };

    >> ...
    >> It would be interesting to know, why you want to create an object of
    >> it?

    >
    > Nothing really specific, Was just playing around it and i wonder why
    > the copy constructor isn't private...


    Huh? What are you taking about? In the definition you provided the copy
    constructor obviously _is_ private.

    --
    Best regards,
    Andrey Tarasevich
     
    Andrey Tarasevich, Dec 8, 2007
    #5
  6. Rahul

    Pete Becker Guest

    On 2007-12-08 00:38:10 -0500, Rahul <> said:

    >
    > I was working with Run Time Type Information and with typeid
    > operator, and so on i tried to create an object of type_info class and
    > i'm not able to do so, because of the class design,
    >


    It's designed that way because you don't need to copy them (use
    references or pointers), and having a single instance for each type
    makes equality comparisons much simpler.

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
     
    Pete Becker, Dec 8, 2007
    #6
  7. On Dec 8, 4:37 pm, Pete Becker <> wrote:
    > On 2007-12-08 00:38:10 -0500, Rahul <> said:
    >
    >
    >
    > > I was working with Run Time Type Information and with typeid
    > > operator, and so on i tried to create an object of type_info class and
    > > i'm not able to do so, because of the class design,

    >
    > It's designed that way because you don't need to copy them (use
    > references or pointers), and having a single instance for each type
    > makes equality comparisons much simpler.


    I noticed this now that the copy constructor is private. And since it
    has been declared, one doesn't get the default c-tor. This is strange.
    Creating the object of type_info on your own might seem useless/
    redundant, but why is the copy construction not allowed? Isn't that
    like forcing people to create dynamic objects of type_info and then
    returning a pointer to them where the deallocation responsibility lies
    with the caller (you can't even pass an object as an argument that the
    function could make change to by assigning to it)? Is that good
    design? The copy c-tor should have been allowed so that one could
    return a local type_info object by value to the caller. Same goes for
    assignment.
     
    Abhishek Padmanabh, Dec 8, 2007
    #7
  8. Rahul

    Pete Becker Guest

    On 2007-12-08 09:23:05 -0500, Abhishek Padmanabh
    <> said:

    > On Dec 8, 4:37 pm, Pete Becker <> wrote:
    >> On 2007-12-08 00:38:10 -0500, Rahul <> said:
    >>
    >>
    >>
    >>> I was working with Run Time Type Information and with typeid
    >>> operator, and so on i tried to create an object of type_info class and
    >>> i'm not able to do so, because of the class design,

    >>
    >> It's designed that way because you don't need to copy them (use
    >> references or pointers), and having a single instance for each type
    >> makes equality comparisons much simpler.

    >
    > I noticed this now that the copy constructor is private. And since it
    > has been declared, one doesn't get the default c-tor. This is strange.
    > Creating the object of type_info on your own might seem useless/
    > redundant, but why is the copy construction not allowed?


    As I said, it makes equality comparisons much simpler.

    > Isn't that
    > like forcing people to create dynamic objects of type_info and then
    > returning a pointer to them where the deallocation responsibility lies
    > with the caller (you can't even pass an object as an argument that the
    > function could make change to by assigning to it)?


    No. Just use the reference that type_id returns. Memory management for
    type_id objects is not your responsibility. (In fact, there's typically
    one static object for each type, so there's no dynamic memory involved.
    But that's up to the implementation)

    > Is that good
    > design?


    Sure. Why wouldn't it be?

    > The copy c-tor should have been allowed so that one could
    > return a local type_info object by value to the caller. Same goes for
    > assignment.


    Why do you want a copy of a type_info object? Just use the reference
    that type_id returns, or take its address and use that pointer.

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
     
    Pete Becker, Dec 8, 2007
    #8
  9. On Dec 8, 8:37 pm, Pete Becker <> wrote:
    > On 2007-12-08 09:23:05 -0500, Abhishek Padmanabh
    > <> said:
    > > On Dec 8, 4:37 pm, Pete Becker <> wrote:
    > >> On 2007-12-08 00:38:10 -0500, Rahul <> said:

    >
    > >>> I was working with Run Time Type Information and with typeid
    > >>> operator, and so on i tried to create an object of type_info class and
    > >>> i'm not able to do so, because of the class design,

    >
    > >> It's designed that way because you don't need to copy them (use
    > >> references or pointers), and having a single instance for each type
    > >> makes equality comparisons much simpler.

    >
    > > I noticed this now that the copy constructor is private. And since it
    > > has been declared, one doesn't get the default c-tor. This is strange.
    > > Creating the object of type_info on your own might seem useless/
    > > redundant, but why is the copy construction not allowed?

    >
    > As I said, it makes equality comparisons much simpler.
    >
    > > Isn't that
    > > like forcing people to create dynamic objects of type_info and then
    > > returning a pointer to them where the deallocation responsibility lies
    > > with the caller (you can't even pass an object as an argument that the
    > > function could make change to by assigning to it)?

    >
    > No. Just use the reference that type_id returns. Memory management for
    > type_id objects is not your responsibility. (In fact, there's typically
    > one static object for each type, so there's no dynamic memory involved.
    > But that's up to the implementation)
    >


    Ok, got it now. Thanks! I was missing the point about typeid returning
    a static object. I thought memory management was upto the user but as
    you said - it's not. Dynamic memory might be involved as well but
    since it would be one per type. I guess that's fine as per the below
    quote from the standards - [expr.typeid]/1: "The result of a typeid
    expression is an lvalue of static type const std::type_info (18.6.1)
    and dynamic type const std::type_info or const name where name is an
    implementation-defined class derived from std :: type_info which
    preserves the behavior described in 18.6.1.62) The lifetime of the
    object referred to by the lvalue extends to the end of the program.
    Whether or not the destructor is called for the std::type_info object
    at the end of the program is unspecified."
     
    Abhishek Padmanabh, Dec 8, 2007
    #9
  10. Rahul

    James Kanze Guest

    On Dec 8, 4:37 pm, Pete Becker <> wrote:
    > On 2007-12-08 09:23:05 -0500, Abhishek Padmanabh
    > <> said:
    > > On Dec 8, 4:37 pm, Pete Becker <> wrote:
    > >> On 2007-12-08 00:38:10 -0500, Rahul <> said:


    [...]
    > > Isn't that like forcing people to create dynamic objects of
    > > type_info and then returning a pointer to them where the
    > > deallocation responsibility lies with the caller (you can't
    > > even pass an object as an argument that the function could
    > > make change to by assigning to it)?


    > No. Just use the reference that type_id returns. Memory
    > management for type_id objects is not your responsibility. (In
    > fact, there's typically one static object for each type, so
    > there's no dynamic memory involved. But that's up to the
    > implementation)


    One of the most frequence uses of type_info (about the only one
    I can think of off hand, in fact) is as an index into a map.
    And because the key type must in fact be std::type_info const*,
    that you have to write your own comparison function for map.
    The standard could have provided one. And now that hash tables
    are being added to the standard, I hope the standard provides
    for some means of getting a hash code of a type_info---there's
    practically no way of doing it yourself.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 9, 2007
    #10
    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. sks_cpp

    type_info, vtable

    sks_cpp, Aug 19, 2003, in forum: C++
    Replies:
    54
    Views:
    2,247
    Ron Natalie
    Aug 27, 2003
  2. skscpp
    Replies:
    5
    Views:
    565
    EventHelix.com
    Nov 14, 2003
  3. Bobo

    virtual ~type_info();

    Bobo, Jan 20, 2004, in forum: C++
    Replies:
    3
    Views:
    378
  4. =?ISO-8859-1?Q?Erik_Wikstr=F6m?=

    Storing std::type_info

    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Aug 11, 2007, in forum: C++
    Replies:
    2
    Views:
    1,622
    Daniel Kraft
    Aug 11, 2007
  5. sumsin

    What is type_info object?

    sumsin, Jun 11, 2008, in forum: C++
    Replies:
    1
    Views:
    411
    James Kanze
    Jun 12, 2008
Loading...

Share This Page