type_info

[Rahul]

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

[Abhishek Padmanabh]

On Dec 8, 10:38 am, Rahul <[e-mail]:

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?

[Rahul]

On Dec 8, 11:08 am, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 8, 10:38 am, Rahul <[e-mail]:

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

[Abhishek Padmanabh]

On Dec 8, 11:55 am, Rahul <[e-mail]:

On Dec 8, 11:08 am, Abhishek Padmanabh <[e-mail]>
wrote:

On Dec 8, 10:38 am, Rahul <[e-mail]:

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?

[Andrey Tarasevich]

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

[Pete Becker]

On 2007-12-08 00:38:10 -0500, Rahul <sa*****@yahoo.co.insaid:

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

[Abhishek Padmanabh]

On Dec 8, 4:37 pm, Pete Becker <[e-mail]:

On 2007-12-08 00:38:10 -0500, Rahul <[e-mail]:

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.

[Pete Becker]

On 2007-12-08 09:23:05 -0500, Abhishek Padmanabh
<ab****************@gmail.comsaid:

On Dec 8, 4:37 pm, Pete Becker <[e-mail]:

>On 2007-12-08 00:38:10 -0500, Rahul <[e-mail]:

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

[Abhishek Padmanabh]

On Dec 8, 8:37 pm, Pete Becker <[e-mail]:

On 2007-12-08 09:23:05 -0500, Abhishek Padmanabh
<[e-mail]:

On Dec 8, 4:37 pm, Pete Becker <[e-mail]:

On 2007-12-08 00:38:10 -0500, Rahul <[e-mail]:

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

[James Kanze]

On Dec 8, 4:37 pm, Pete Becker <[e-mail]:

On 2007-12-08 09:23:05 -0500, Abhishek Padmanabh
<[e-mail]:

On Dec 8, 4:37 pm, Pete Becker <[e-mail]:

On 2007-12-08 00:38:10 -0500, Rahul <[e-mail]:

[...]

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]