From -3009930819156160171 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/06 Message-ID: #1/1 X-Deja-AN: 557079785 Approved: Fergus Henderson References: <81u646$kln$1@nnrp1.deja.com> X-Original-Date: Wed, 01 Dec 1999 14:36 +0000 (GMT Standard Time) X-Complaints-To: news@news.unimelb.edu.au X-Trace: ariel.ucs.unimelb.edu.au 944445089 4170 128.250.37.153 (6 Dec 1999 01:51:29 GMT) Organization: Burry Holms Research X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAOEsWoeEDnX0m9pzZAQHHqAF+KEXO/fc5Cy6jK9ONbZLyjWcCHKgssfhQ kJRa3rg4YiZRozAFlDA4o7wEjIt9+jKa =8995 X-URL: http://www.ameol.com X-News-software: Ameol2 Reply-To: brangdon@cix.co.uk NNTP-Posting-Date: 6 Dec 1999 01:51:29 GMT Newsgroups: comp.std.c++ sirwillard@my-deja.com () wrote: > I hope this was just a guess, and not the true reason. They were all guesses. I wasn't anywhere near the committee. > First of all, to design for something "that might be added by a future > version" is a slippery slope to begin with. Secondly, if anyone is > confused as to what the behavior of operator< should be (it seems > obvious to me) then the standard and all other documentation will > clearly explain things. It's not obvious to me. In fact, it means almost nothing; before() is an arbitrary ordering that might not even be consistent from one run to another. When I first read the description I was somewhat surprised. The point is not so much what might be added in future, but what expectations a programmer might reasonably have. Good design should minimise surprise. Operator overloading should really be used when the meaning is obvious. Documentation can help, of course, but I don't think good documentation is an excuse for bad design. Even as it is, the documentation has to take pains to disabuse our reasonable expectations. > > I would think any implementor who was able to provide a good > > hashing value would also be able to provide unique names. > > This doesn't follow logically. First of all, on MANY platforms, > type_info is defined by the compiler vendor while the container classes > (including the theoretical STL extension, hash_map) are provided by a > third party. In these cases it's not only possible, but likely, that > although string hashing is available in the library, type_info::name > does not provide a unique string. That's true but irrelevant. You asked: Why was there no thought put into providing some state within type_info that could be portably used for hashing functions? The name would be the obvious state to use. 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. They decided not to for some compelling reason. I suggest the same reason would apply to providing any hashable state. Providing any other hashable state would be no easier than providing the name. We both agree that the standard is not very helpful to programmers who want to use hashing. My preferred fix would be to require unique strings (since the name() interface is already in place and names would be useful in other ways). Your preferred fix, apparently, is that names should be left as they are and more state added just for hashing. I don't see what advantage that approach has. > As for the conventions that might be chosen in the future... > those conventions would not be compromised by the inclusion of state > info that could be hashed. I don't believe that type_info was "right > to avoid pre-empting those decisions" because of this. What state info do you have in mind? It seems to me that either you have something equivalent to a string or else you use opaque state accessed through a hash function. "Equivalent to a string" in that we don't know how many bits the implementation will need, so it must be variable length. A variable length array of char would be fine. Perhaps we could have name() and hashable_name(), where the latter is guaranteed unique and the former isn't. But that's silly; let's just place more requirements on name() and use it for both tasks. If instead you intend opaque state accessed through a hash function, you have to decide what this function will be called and what type it returns. This opens up the hashing standards can of worms. Is there some 3rd approach I've missed? What would you have had the committee actually do? 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 ]