From 6413520114453010038 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/11 Message-ID: <82r9aa$3po$1@nnrp1.deja.com> X-Deja-AN: 559394577 Approved: Fergus Henderson References: <81u646$kln$1@nnrp1.deja.com> <82gmer$gqm$1@nnrp1.deja.com> <82nk8i$hh6$1@nnrp1.deja.com> X-Original-Date: Fri, 10 Dec 1999 16:21:37 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) X-Complaints-To: news@news.unimelb.edu.au X-Http-Proxy: 1.1 x23.deja.com:80 (Squid/1.1.22) for client 167.16.119.20 X-Trace: ariel.ucs.unimelb.edu.au 944929389 9738 128.250.37.153 (11 Dec 1999 16:23:09 GMT) Organization: Deja.com - Before you buy. X-Article-Creation-Date: Fri Dec 10 16:21:37 1999 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAOFJ6YeEDnX0m9pzZAQHGNgF/YBeT2vdqn6U6RPuWfO2n6bHQc/PTwZdC HqOFexUFQGUhv/gh4L6SeN8WGulGx3Et =SP+C X-Mydeja-Info: XMYDJUIDsirwillard NNTP-Posting-Date: 11 Dec 1999 16:23:09 GMT Newsgroups: comp.std.c++ In article <82nk8i$hh6$1@nnrp1.deja.com>, Gene Bushuyev wrote: > In article <82gmer$gqm$1@nnrp1.deja.com>, > sirwillard@my-deja.com wrote: > [snip] > > > They > > > decided not to for some compelling reason. I suggest the same > reason would > > > apply to providing any hashable state. > > > > I already gave the most reasonable reason and it most definately can't > > be applied as a reason to not provide any hashing state. > > > > > Providing any other hashable state > > > would be no easier than providing the name. > > > > Not at all true. > > In fact it is true. Moreover, this another key for hashing still > doesn't have anything to build upon but the class name. See below. I looked below, and you don't address this. Providing an integral hash value is straight forward and simple to implement given the requirements already required for type_info. I addressed how in this very thread. > [snip] > > > > No, let's not use strings for hashing at all if we can, thank you very > > much. I've given two compelling reasons for this: memory > requirements > > and the speed problems with string hashing functions. > > There are no big memory requirements. Even if my project contains 1000 > classes and all their names are 1000 chars long, it's just 1MB of > virtual memory. For such a project it's absolutely unsignificant amount. > Speed also doesn't matter that much, because storing/loading persistent > objects is not frequent operation. Usually, it is done as a response to > user's input. *sighs* 1 MB of virtual memory is a HUGE amount. For many applications this would be unforgivable, especially if the functionality is never used. Also don't forget this memory will also be included in the static size of the executable. As for saying speed doesn't matter... that's just plain silly. Hashing is used because it provides faster lookups than tree based approaches like we already have with the standard map and set classes. Speed is the ONLY reason to provide hashing. Large string hash values would reduce the speed advantage of a hash to none, or possibly even make it worse. Further, you mention persistent objects, but I never did. Hashing is not a function of persistance (though it can be employed by persistant mechanisms). > [snip] > > > 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. > > I don't see what obvious algorithm you have in mind. And reading other > threads with similar proposals I see that people do not understand how > persistent objects are used. This thread is NOT about peristant objects. It's about the design of type_info, and the subthread about the lack of compatibility with hashing. This is NOT persistant objects. I fully understand how persistant objects are used, but I don't feel that type_info needs to provide functionality for persistant mechanisms. > What is needed to create persistent objects is some invariant that > doesn't depend on compiler, the number of libraries and the order of > their loading. Persistent object must have the same key every time the > program is executed, even if it was edited and recompiled in between > the runs. You can't assume any pointers will have the same absolute or > relative values. You can't assume templates will be instantiating at > the same order or that you will have the same number of them. > The only invariant is the class name, but type_info blew this only > chance of making persistent objects. The only state that appears to be available is the name, but the name is not unique, as you point out. However, a good persistance mechanism is probably going to use something other than a class name as the object id. Unique names are problematic at best, and a burden on the system at worst. In any event, type_info is not an appropriate place to look for persistance mechanisms, IMHO. I'm NOT suggesting we modify type_info to provide automatic persistance. It provides enough functionality as it stands today to build robust persistance mechanisms that won't burden classes and/or projects with code bloat when persistance is not required. > At present the ONLY portable way > of building persistent objects is to add a unique static string or > other type key to every class that is intended to be persistent. This > is error prone and boring. The task that compiler could easily perform > if the standard provided strict requirements on the uniqueness of > type_info::name(). Which it won't do (at least I certainly hope they won't). The VAST majority of applications do not make use of persistance, and the cost of unique names within RTTI mechanisms for them is too high. I'd even consider it too high for those that need it. Something along the lines of a GUID would be more palatable. As for having such a thing in type_info... I don't think so. The compiler really can't be expected to produce such keys (i.e. keys that are unique but identical across runs and even across platforms). I can think of no algorithm which could be employed which will gaurantee this sort of thing. Besides, this is the most minor of issues one will have to address within a persistance mechanisms. > As to your proposed integral value as a key. It won't work unless you > somehow derive this value from class name. Possible, but doesn't make > much sense. Why won't it work? You don't explain or back up this assertion at all. In fact, I don't buy the assertion at all. I've already given a proposal that would create the integral value as a key that doesn't rely on the class name at all. I could easily roll an implementation tomorrow to support this idea (and the implementation would be portable by todays standards). The only problem is mine would have to be built on top of the current type_info, and so would suffer in performance. If we modified type_info directly, there'd be no such performance problems. The only hair in the soup here is one you've made up. Persistance facilities directly in type_info was not a goal, nor should it be, IMHO. 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 ]