home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!noc.near.net!nic.umass.edu!dime!roo.cs.umass.edu!pop
- From: pop@cs.umass.edu ( Robin Popplestone )
- Newsgroups: comp.lang.pop
- Subject: When the (Gibson) cat's away across the atlantic....
- Keywords: vision, butchering-of-vectors danger
- Message-ID: <57967@dime.cs.umass.edu>
- Date: 23 Dec 92 14:10:39 GMT
- Sender: news@dime.cs.umass.edu
- Organization: University of Massachusetts, Amherst
- Lines: 25
- Originator: pop@roo.cs.umass.edu
-
- Needing to crunch a quarter of a million pixels in a hurry I have been
- reduced to writing 600 lines of C. How, I wondered to let C report its
- answers back to POP - these had to be line-segment records as well as
- an 512*512 array (something like the Ramsay and Barrett line-finder
- souped up) Now the array was no problem - POP knows how big it will
- be, and just gives C the array vector. Line segments, the number of
- which cannot be predicted, presented a harder problem. I didn't want
- to use a call-back to the POPLOG allocator, for various reasons. So I
- made POP hand C a large vector, which C then carves into segment
- records (using a segment-key handed in as an argument) and a left-over
- vector. This is safe (once I got the bugs out), provided the C program
- can't be interrupted by a signal (since C is left with no compromising
- pointers), but is clearly in danger of being upstaged by any change in
- POPLOG. It is also mostly satisfactory, in the sense that store
- doesn't get fragmented, and the implementation is efficient.
-
- I suppose my question is - might some conventions and .h files etc. be
- provided to allow one to do this kind of thing in a way that would be
- proof against version change. [One of the main pains in this exercise
- is that C doesn't let offset pointers into structures the way POP
- does, so that there is no neat solution to being able to access all
- the fields (including the key) while maintaining the C size = the
- actual size of the POP record.].
-
- Robin
-