Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!mhuxv!mhuxh!mhuxi!mhuxm!mhuxj!houxm!vax135!cornell!uw-beaver!tektronix!robertd From: robertd@tektronix.UUCP (Bob Dietrich) Newsgroups: net.lang.pascal Subject: Re: Comparing pointers in Pascal Message-ID: <5086@tektronix.UUCP> Date: Thu, 7-Feb-85 16:44:03 EST Article-I.D.: tektroni.5086 Posted: Thu Feb 7 16:44:03 1985 Date-Received: Sat, 9-Feb-85 08:10:19 EST References: <3161@ucla-cs.UUCP> <9300010@uiucdcsb.UUCP> Organization: Tektronix, Beaverton OR Lines: 46 > ... Pascal does not object to the use of > an assumption that every unique pointer has a corresponding unique scalar > value, which may be sorted, compared, etc. just like any integer. Why not > use "ord (your_pointer)" for the problem above? Pascal permits the conversion > of (unique?)* pointers into (unique?)* integers, but tries to prevent direct > arithmetic on pointers because this is clearly implementation-dependent. > BTW, ord (pointer) is a freebie (i.e. NOP) in most Pascal compilers. Application of 'ord' to pointers (or any type other than enumerations, integers, chars, Boolean, or subranges thereof) is an extension available in various Pascal implementations, but it is not a standard feature of Pascal. Berkley Pascal has this extension, although it is not documented. > * I am not sure, and rather doubt, that Pascal guarantees that pointers and > integers will always be the same size. In an implementation with pointers > larger than integers, the uniqueness assumption of the "ord" solution might > not hold. Still, this kind of implementation-dependency seems both less > likely and less serious. Good point. The Pascal standards explicitly avoid specifying implementation details to give an implementor freedom to do a good job. An implementation may have 3 different sizes of pointers (such as for the Intel 286) if it wants, or define type 'char' to be 16-bits to accomodate extended character sets (such as for Japanese or the other character sets being standardized). > I guess that to be completely safe, one would have to use some other > mechanism to obtain a unique key for each pointer. These keys could be kept > with the pointers in the sorted vector (now a vector of records), or could > be stored in the "pointee" records. Either way, it would be dead easy to > keep your sorted vector - with only a small space (one integer) and perhaps > time penalty (need extra indirection on compares if key stored with pointee). > Either approach is still O(ln(N)), but is now implementation-independent. Good! Whenever you run into a roadblock in a language, there's a better than even chance that you're trying the wrong approach, instead of the language being deficient. All idioms in German do not translate literally into English, and vice versa. Each language has its model of the world, which does not make either wrong. By modifying your design, you may get faster run time, shorter code, less storage, easier maintenance, better portability, etc. Bob Dietrich Tektronix, Inc. (503) 629-1727 {ucb or dec}vax!tektronix!robertd uucp address robertd@tektronix csnet address robertd.tektronix@rand-relay arpa address