473,320 Members | 1,902 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

typeid operator

Hi everyone!

I would like to use the reference returned by typeid as key in a std::map.
Is it safe to assume that typeid(T) (where T is a type name) will always
return the same reference to the same type_info structure for a given T? My
map would look like this:

typedef std::map<const std::type_info &, ......> Type_map;

Cheers,
Marco
Jul 22 '05 #1
19 3589
"Marco Jez" <ne*****@nessuno.com> wrote in message
news:FO**********************@news4.tin.it...
I would like to use the reference returned by typeid as key in a std::map.
Is it safe to assume that typeid(T) (where T is a type name) will always
return the same reference to the same type_info structure for a given T?


I don't see why you should be able to make that assumption.

The type_info::before member is intended to be used for defining a
comparison function that you can use for making map keys out of typeids. If
you use it, two distinct type_info objects that represent the same type
should be treated as equivalent keys.
Jul 22 '05 #2
Marco Jez wrote:
I would like to use the reference returned by typeid as key in a std::map.
Is it safe to assume that typeid(T) (where T is a type name) will always
return the same reference to the same type_info structure for a given T? My
map would look like this:

typedef std::map<const std::type_info &, ......> Type_map;


Yes, that's guaranteed.

V
Jul 22 '05 #3
Andrew Koenig wrote:
"Marco Jez" <ne*****@nessuno.com> wrote in message
news:FO**********************@news4.tin.it...

I would like to use the reference returned by typeid as key in a std::map.
Is it safe to assume that typeid(T) (where T is a type name) will always
return the same reference to the same type_info structure for a given T?

I don't see why you should be able to make that assumption.


I think the Standard in 5.2.8 says that the lvalue is returned and that
the lifetime of the object referred to by the lvalue is entire program.
So, why should we be able to make that assumption? Or did you forget the
'not' as in "I don't see why you should _not_ be able..."?

The only doubt I have is that the OP's map is made to have the reference
as the key type. Is it possible? "Key" is required to be assignable.
Are references assignable? I kind of think they are fine, but are they?
The type_info::before member is intended to be used for defining a
comparison function that you can use for making map keys out of typeids. If
you use it, two distinct type_info objects that represent the same type
should be treated as equivalent keys.


V
Jul 22 '05 #4

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:0L****************@newsread1.dllstx09.us.to.v erio.net...
Andrew Koenig wrote:
"Marco Jez" <ne*****@nessuno.com> wrote in message
news:FO**********************@news4.tin.it...

I would like to use the reference returned by typeid as key in a std::map.
Is it safe to assume that typeid(T) (where T is a type name) will always
return the same reference to the same type_info structure for a given T?

I don't see why you should be able to make that assumption.


I think the Standard in 5.2.8 says that the lvalue is returned and that
the lifetime of the object referred to by the lvalue is entire program.
So, why should we be able to make that assumption? Or did you forget the
'not' as in "I don't see why you should _not_ be able..."?


Wouldn't it be legal -- but insane -- for an implementation to have several
type_info objects for a given type, each of which has lifetime equal to the
entire program, and for typeid to to select one at random each time typeid is
invoked?

Perhaps support for dynamic libraries might sometimes lead to the existence of
two typeid objects for the same type.

Jonathan


Jul 22 '05 #5
"Andrew Koenig" <ar*@acm.org> ha scritto nel messaggio
news:8u*********************@bgtnsc04-news.ops.worldnet.att.net...
I don't see why you should be able to make that assumption.
That's why I've asked... :-)
Since it seemed to be true in my implementation I was wondering whether the
Standard guarantees that or not. Anyway I didn't notice the before() member,
my fault.
The type_info::before member is intended to be used for defining a
comparison function that you can use for making map keys out of typeids.
If you use it, two distinct type_info objects that represent the same type
should be treated as equivalent keys.


So, would this map be guaranteed to work as expected?

struct Type_info_cmp
{
bool operator()(const std::type_info *t1, const std::type_info *t2)
const
{
return t1->before(*t2) != 0;
}
};

typedef std::map<const std::type_info*, My_struct, Type_info_cmp>
Type_map;

Cheers,
Marco

Jul 22 '05 #6
> The only doubt I have is that the OP's map is made to have the reference
as the key type. Is it possible? "Key" is required to be assignable.
Are references assignable? I kind of think they are fine, but are they?


I was actually thinking of storing a pointer to the type_info structure, not
a reference (I've corrected it in my reply to Andrew). Sorry for the
confusion.

Marco
Jul 22 '05 #7

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:0L****************@newsread1.dllstx09.us.to.v erio.net...
Andrew Koenig wrote:
I would like to use the reference returned by typeid as key in a
std::map. Is it safe to assume that typeid(T) (where T is a type name)
will always return the same reference to the same type_info structure for
a given T?
I don't see why you should be able to make that assumption.

I think the Standard in 5.2.8 says that the lvalue is returned and that
the lifetime of the object referred to by the lvalue is entire program.
So, why should we be able to make that assumption? Or did you forget the
'not' as in "I don't see why you should _not_ be able..."?


Because I don't see any place in 5.2.8 that prohibits an implementation from
having several distinct objects that represent a given type and returning a
reference to one or another of those objects at whim.

As a more realistic example, consider a class defined in a header file that
is included in several translation units. Where does it say that the
implementation can't create a separate type_info object in each translation
unit?
Jul 22 '05 #8
"Marco Jez" <gu***@none.it> wrote in message
news:Ds**********************@news4.tin.it...
"Andrew Koenig" <ar*@acm.org> ha scritto nel messaggio
The type_info::before member is intended to be used for defining a
comparison function that you can use for making map keys out of typeids.
If you use it, two distinct type_info objects that represent the same
type should be treated as equivalent keys.

So, would this map be guaranteed to work as expected?

struct Type_info_cmp
{
bool operator()(const std::type_info *t1, const std::type_info *t2)
const
{
return t1->before(*t2) != 0;
}
};

typedef std::map<const std::type_info*, My_struct, Type_info_cmp>
Type_map;


That's the idea.

[The type_info::before member is in the standard because I proposed it, so I
am confident in knowing its purpose :-) ]
Jul 22 '05 #9
Marco Jez wrote:
...
I would like to use the reference returned by typeid as key in a std::map.
Is it safe to assume that typeid(T) (where T is a type name) will always
return the same reference to the same type_info structure for a given T? My
map would look like this:

typedef std::map<const std::type_info &, ......> Type_map;
...


You cannot use any reference type as a key in an 'std::map' because
reference types are not Assignable, which happens to be a requirement
for 'std::map's key type. Use pointer to 'std::type_info' instead.

Since the C++ standard doesn't explicitly guarantee that 'typeid' always
return a reference to the same 'type_info' object for the same argument
type, you'll have to supply the map with your own comparison predicate,
which will perform "intellegent" comparison of 'type_info' pointers by
comparing the pointed objects using 'std::type_info::before' method.

--
Best regards,
Andrey Tarasevich
Jul 22 '05 #10
Victor Bazarov wrote:
...
The only doubt I have is that the OP's map is made to have the reference
as the key type. Is it possible? "Key" is required to be assignable.
Are references assignable? I kind of think they are fine, but are they?
...


They are not Assignable of course, by which I mean that any attempt to
syntactically "assign" them will actually be applied to referenced objects.

Firstly, that's definitely not what the OP wants. Secondly, it won't
work because the referenced objects are const-qualified anyway. Thirdly,
it won't work because 'std::type_info' objects are not Assignable
themselves.

--
Best regards,
Andrey Tarasevich
Jul 22 '05 #11
Hi Marco,

this is covered as well in the Loki Library. There is a class storing the
pointer to a type_info and comparing via the before function.

A short version looks like this:
class CTypeInfo
{
public:
CTypeInfo(const std::type_info& ti) : pInfo_(&ti) // non-explicit
{
assert(pInfo_);
}
// Access for the wrapped std::type_info
const std::type_info& Get() const
{
assert(pInfo_);
return *pInfo_;
}
// Compatibility functions
bool before(const CTypeInfo & rhs) const
{
assert(pInfo_);
return pInfo_->before(*rhs.pInfo_) != 0;
}
private:
const std::type_info* pInfo_;
};

// Implementation
inline bool operator<(const CTypeInfo& lhs, const CTypeInfo& rhs)
{
return lhs.before(rhs);
}
You can use this class directly in a map then.

Regards,
Patrick
Jul 22 '05 #12
Patrick Kowalzick wrote:
class CTypeInfo
{
...
// Compatibility functions
bool before(const CTypeInfo & rhs) const
{
assert(pInfo_);
assert(pInfo_ && rhs.pInfo_)

would better fit the general style of using assertions in this code.
return pInfo_->before(*rhs.pInfo_) != 0;
}
...


--
Best regards,
Andrey Tarasevich
Jul 22 '05 #13
> would better fit the general style of using assertions in this code.
return pInfo_->before(*rhs.pInfo_) != 0;
}


true :)

Thx,
Patrick
Jul 22 '05 #14
On Wed, 27 Oct 2004 13:55:18 -0600, "Jonathan Turkanis"
<te******@kangaroologic.com> wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:0L****************@newsread1.dllstx09.us.to. verio.net...
Andrew Koenig wrote:
> "Marco Jez" <ne*****@nessuno.com> wrote in message
> news:FO**********************@news4.tin.it...
>
>
>>I would like to use the reference returned by typeid as key in a std::map.
>>Is it safe to assume that typeid(T) (where T is a type name) will always
>>return the same reference to the same type_info structure for a given T?
>
>
> I don't see why you should be able to make that assumption.


I think the Standard in 5.2.8 says that the lvalue is returned and that
the lifetime of the object referred to by the lvalue is entire program.
So, why should we be able to make that assumption? Or did you forget the
'not' as in "I don't see why you should _not_ be able..."?


Wouldn't it be legal -- but insane -- for an implementation to have several
type_info objects for a given type, each of which has lifetime equal to the
entire program, and for typeid to to select one at random each time typeid is
invoked?

Perhaps support for dynamic libraries might sometimes lead to the existence of
two typeid objects for the same type.


It does under Windows. Call typeid on the same (non-exported) type in
a DLL and a exe, and the object returned will be different. This is
also why MS's dynamic_cast implementation is so slow - it performs
string comparisons to work out whether two types are the same, whereas
under Unix I think address comparisons are usually sufficient.

Tom
Jul 22 '05 #15
Dear all,
Perhaps support for dynamic libraries might sometimes lead to the existence oftwo typeid objects for the same type.


It does under Windows. Call typeid on the same (non-exported) type in
a DLL and a exe, and the object returned will be different. This is
also why MS's dynamic_cast implementation is so slow - it performs
string comparisons to work out whether two types are the same, whereas
under Unix I think address comparisons are usually sufficient.


Is it guaranteed that a type_info object stays "in place" in one compilation
unit? Means, if I have a pointer to type_info object, is this pointer valid
until the end of the program ?

Patrick
Jul 22 '05 #16
On Thu, 28 Oct 2004 15:16:44 +0200, "Patrick Kowalzick"
<Pa***************@cern.ch> wrote:
Dear all,
>Perhaps support for dynamic libraries might sometimes lead to theexistence of >two typeid objects for the same type.


It does under Windows. Call typeid on the same (non-exported) type in
a DLL and a exe, and the object returned will be different. This is
also why MS's dynamic_cast implementation is so slow - it performs
string comparisons to work out whether two types are the same, whereas
under Unix I think address comparisons are usually sufficient.


Is it guaranteed that a type_info object stays "in place" in one compilation
unit? Means, if I have a pointer to type_info object, is this pointer valid
until the end of the program ?


I think the only exception to the would be if you loaded a DLL, got a
typeid object out of it, and then unloaded the DLL. The standard
guarantees that type_info objects have static storage duration, so
except where a compiler is deviating from the standard (as with DLLs),
type_info object references and pointers are valid for the duration of
the program.

Tom
Jul 22 '05 #17
Hi Tom,
I think the only exception to the would be if you loaded a DLL, got a
typeid object out of it, and then unloaded the DLL. The standard
guarantees that type_info objects have static storage duration, so
except where a compiler is deviating from the standard (as with DLLs),
type_info object references and pointers are valid for the duration of
the program.


Do you have a reference in the standard? I do not doubt your words, but I
searched this before posting and I was not able too find the relevant
paragraphs (like so often).

Thanks,
Patrick
Jul 22 '05 #18
Patrick Kowalzick wrote:
I think the only exception to the would be if you loaded a DLL, got a
typeid object out of it, and then unloaded the DLL. The standard
guarantees that type_info objects have static storage duration, so
except where a compiler is deviating from the standard (as with DLLs),
type_info object references and pointers are valid for the duration of
the program.


Do you have a reference in the standard? I do not doubt your words, but I
searched this before posting and I was not able too find the relevant
paragraphs (like so often).


Victor already mentioned 5.2.8 a couple of messages higher in this
thread. 5.2.8/1 explicitly states that the lifetime of the object
referred by the result of 'typeid' extends to the end of the program.

--
Best regards,
Andrey Tarasevich
Jul 22 '05 #19
Jonathan Turkanis wrote:

Perhaps support for dynamic libraries might sometimes lead to the existence of
two typeid objects for the same type.


Exactly. Both legal and sane.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: Jamie Burns | last post by:
Hello, I just did a simple benchmark: for (xx=0;xx<100000;xx++) { rDerived* derived = dynamic_cast<rDerived*>(object); if (derived) derived->setValue(message.data.messageSetInt.value); } ...
3
by: Mike | last post by:
I want to use typeid() in a base class function to determine the name of the derived class. typeid(this) returns the name of the base class (which is an abstract class) rather than the derived...
3
by: Ganesh | last post by:
Hi, typeinfo class has a private constructor and only typeid can return object to typeinfo class. So here I am wondering how these two are related. Are these two related through 'friend' so that...
17
by: Michael Olea | last post by:
Sometimes, in an introspective mood, my code reflecting on itself, I like to write test code that prints the results of introspection, some of which consist of the names of Types. The problem is:...
18
by: Adam Zimny | last post by:
This is fragment of code from Bruce Eckel's Thinking in c++ ( last 3 couts are mine to show what happened ). The question is: is Bruce Eckel wrong or g++ ( my version is 3.2.3 ) is buggy ? //:...
5
by: nobody | last post by:
With Visual C++ 2005 beta 2, I get the below compling error for the following code. I think this error is not acceptable to me because int::typeid is a constant and is known to compiler when...
4
by: ezelasky | last post by:
I am programming in microsoft VC++ 7.1 and get an unhandled exception when I use typeid on a deferenced pointer. So I tried the example below, from the msdn site and I am seeing the same...
2
by: Sarath | last post by:
Hello All Is it possible to overload typeid operator? In my understanding it's not possible Could you please provide more information on same? Regards, Sarath
7
by: Deepak Jharodia | last post by:
I'm using a templatized class in GCC based environ template<class A, class B> class foo {... ....} F; Now I want to know that particular instance of this class was instantiated with what...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.