From 3253857001030469473 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fbd36da46c3cc7a0 X-Google-Attributes: gidf78e5,public From: sirwillard@my-deja.com Subject: Re: Discussion: type_info Date: 1999/12/08 Message-ID: <82lv69$atk$1@nnrp1.deja.com>#1/1 X-Deja-AN: 558223522 X-NNTP-Posting-Host: 167.16.119.20 Approved: stephen.clamage@sun.com (comp.std.c++) References: <82gmer$gqm$1@nnrp1.deja.com> <384c8866.77375470@news.internetconnect.net> X-UID: 0000000001 X-Status: $$$T X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) X-Http-Proxy: 1.1 x37.deja.com:80 (Squid/1.1.22) for client 167.16.119.20 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Wed Dec 08 15:58:03 1999 GMT X-MyDeja-Info: XMYDJUIDsirwillard Newsgroups: comp.std.c++ Originator: clamage@taumet In article <384c8866.77375470@news.internetconnect.net>, phalpern@newview.org (Pablo Halpern) wrote: > > scorp@btinternet.com (Dave Harris) wrote: > > > >sirwillard@my-deja.com () wrote: > >Contrariwise, if you have a perfect hash you can make a unique string > >directly from it. A hex representation of a smallish integer could be > >smaller than the integer itself. The two seem to me to be more or less > >equivalent. If you can have one you can have the other. > > Yes, but it seems reasonable that an implementation might provide a > name() function that returns meaningful but non-unique name (e.g. an > abbreviated name without namespaces, cv qualifiers, or even template > parameters). By requiring the hash to be built on the name, you require > that the name either be a meaningless hex number or a potentially very > long meaningful name. This was precisely my point. I must not have made it very clear in the wording. > I wish that the long, complete name were required, because they make it > easier to build persistence and network-object mechanisms. But long > names take a long time to hash, so it would also be nice to have a fast > hashing function. I don't want any such thing. Building persistence and network-object mechanisms without a unique name in type_info is not very difficult. Just to make it a little easier is not a good reason to modify type_info in a way that will cause tremendous code bloat. This is especially true since most programs don't make use of these mechanisms any way. IOW, you've severely bloated programs with functionality never used. > >> Actually, for most implementations I would think it would just be a > >> matter of exposing the state that already exists to provide > >> functionality for "before". The only real change is a limitation as to > >> what this state can be. > > > >Yes... a limitation I dislike. If we're to promote hashing, than I think > >I'd prefer an opaque get_hash() function. It could use counters if > >convenient, or the name, or some internal representation of the type that > >happened to be in use anyway - whatever suited the implementation. > > We're in agreement here. As am I. Again, I guess the way I worded things left some question as to what I meant. It would be folly to expose state directly instead of through an accessor method. Sent via Deja.com http://www.deja.com/ Before you buy. [ 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 ]