From -6113251272753535698 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fbd36da46c3cc7a0 X-Google-Attributes: gidf78e5,public From: scorp@btinternet.com (Dave Harris) Subject: Re: Discussion: type_info Date: 1999/12/07 Message-ID: #1/1 X-Deja-AN: 557485154 X-NNTP-Posting-Host: host212-140-28-70.btinternet.com Approved: stephen.clamage@sun.com (comp.std.c++) References: <82gmer$gqm$1@nnrp1.deja.com> X-UID: 0000000001 X-Status: $$$T Organization: Burry Holms Research X-URL: http://www.ameol.com X-News-Software: Ameol2 Reply-To: brangdon@cix.co.uk Newsgroups: comp.std.c++ Originator: clamage@taumet sirwillard@my-deja.com () wrote: > The behaviour of "before" most certainly seems obvious to me [...] What is "obvious" will of course be subjective and it's not too surprising if we differ. We really need someone from the committee to comment on whether this was a factor at all. > 3. The "collation" ordering required by "before" neatly aligns itself > with a method for providing a true hash with little expense. In other > words, a simple integer type can be used, which is incremented with > each type added to the system. This integer is a "perfect hash", as > well as well suited for implementing the collation ordering. It seems to me that this requires some kind of uniqueness to work. If the same type is introduced independently by several different DLLs, you need to somehow avoid incrementing the counter for the second and subsequent DLLs. So I think something like the long unique bit-patterns must be involved somewhere along the line to make hashing work. Given that, it seems the simplest step is to make them available. Adding an integer field is an optimisation. I'd be quite glad if it was there but it's not fundamental. 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. > > Although it's true that we > > cannot use the name today because they are not guaranteed unique, it's > > surely obvious that the committee thought about making them unique. > > Again, I don't think this is obvious. I'd also be quite surprised if > they did consider this. Then I have more faith in the committee than you :-) > 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. > I'm not familiar with the "hashing standards can of worms" you are > referring to. Maybe we differ in opinion because of this. I've yet to > see an algorithm yet that didn't reduce a hash down to an integral > type, which is the obvious thing to me. It just involves a number of decisions. Which integral type? int, unsigned int, long, unsigned long, size_t, a new hash_t are all reasonable choices. What name should the function have? hash(), get_hash(), hash_value()... Should it be a member function? Whatever choices we make should be compatible with std::hash_map<>, which is a template which hasn't been designed yet. It's all work for the committee to thrash out and reach a consensus on. Dave Harris, Nottingham, UK | "Weave a circle round him thrice, brangdon@cix.co.uk | And close your eyes with holy dread, | For he on honey dew hath fed http://www.bhresearch.co.uk/ | And drunk the milk of Paradise." [ 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 ]