From -7560868601655412712 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fbd36da46c3cc7a0 X-Google-Attributes: gidf78e5,public From: "TiTi" Subject: Re: Discussion: type_info Date: 1999/11/26 Message-ID: <81g9vn$hmq$1@trex.antw.online.be>#1/1 X-Deja-AN: 553253491 Approved: Fergus Henderson , moderator of comp.std.c++ References: <81ecdl$pq$1@nnrp1.deja.com> X-Priority: 3 X-Relay-IP: 128.250.1.22 X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701 Organization: Customer of Online Internet X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MSMail-Priority: Normal Newsgroups: comp.std.c++ Hi there, > I needed type_info to implement a class factory, something I'm sure > we've all done before. Nope never wrote one, I'm more of an "object factory"-kinda guy. Although I would love to see a class factory some time (spawning classes that could get compiled @ run time, seems tricky). > The first thought I had was to use type_info::name, making the key > human readable. The problem is that the standard allows an > implementation to return anything for this method, with no gaurantee > that the name will be unique for each type. So the name is out. How typical. > The next thought was to use the type_info itself in the map. The type_info > class does not have copy construct capabilities. So, we try storing a pointer > to one instead. > So you can't rely on the collating order of the pointer within the > map. Instead, we'll have to use the collation order of the type_info > object itself. A logical idea would be to simply specialize > std::less. In fact, most of the people who realized you > couldn't use the pointer collation suggested doing just this. However, > in one thread it was pointed out that according to the standard this > would produce "undefined behavior", specifically because the standard > library impementors are free to provide their own specialization for > any built in types, and if they did you'd violate the "one definition > rule". So this is out. > I could have resorted to defining a new less_type functor, which would > have worked. However, this would require all uses of type_info within > containers with collation ordering to provide an extra parameter to the > template. Instead of a map you'd need a map T, less_type>. Although this isn't that bad, I'd prefer not doing this. With some map that is a hashed map, you could use template unsigned HashKey(key _key) {return static_cast(key);} // just some stupid code template class SomeHashedMap {// ... }; class Value {}; template<> unsigned HashKey(const type_info* ti) { // use "ti->name" property (or other properties) to calc hash key. The name is (I hope) unique. } int main() { SomeHashedMap someMap; // ... return 0; } > So, instead I resort to an adapter. > struct type_info_key > { > type_info_key(const type_info& type) : type(&type) { } > bool operator==(const type_info_key& other) const { > return !!type->operator==(*other.type); > } > bool operator<(const type_info_key& other) const { > return !!type->before(*other.type); > } > const type_info* type; > }; Nice. > Now we can use std::map (note that we no longer need > to use a pointer). Not the most intuitive path to arrive at something > so simple, but that's what we have with the design and possible > implementations of type_info. However, I'm left with several questions > about type_info's design now. Can't really answer any, but I agree. Someone should answer. TiTi --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]