Endian-ness

[John Ivens <jivens@hindmost.LPL.Arizona.EDU>]

I think that the PDP constant indicates that its ultimately insufficient,
and yet how many machines are neither
LITTLE nor BIG endian?  Very few machines in current use, I would
suspect.  So I think we can declare victory on
that point.

Work is progressing (although slowly) on the pixel representation front.  Dyer and I were talking about needing an
interrogator object but not wanting the user to have to instantiate one.  I think the solution is on page 253 of
Stroustrop where he talks about a first-time switch for local static objects to make sure that they are initialized.

// Warning -- this code is really pseudocode!!  It is untried!!  The driverList is not fully
//                         implemented!!
//                          The actual initialization trick will work, however.

class ICL_Interrogator {
    static bool initialized;
    static bool initialize(dList driverList) {
        /* initialize */ initialized = true;
        // Do other initialization work for this class, like finding all of the mini-drivers
        // locations from a specified file and loading them into an array or some structure
    }
  public:
    // no constructor
 
    void interrogate(string &Buffer) {
        if (initialized == false) {
            initialize(driverList);
        }
        // Now do the real work of interrogating each driver
        // Loop through the driver array asking each one if this file is theirs
        // This driverList is some kind of list-like object, now PSEUDOCODE
        for (i=driverList.begin(); i<driverList.end(); i++) {
            if ( *Buffer.length() < *driverList[i].neededBufferSize() )  {
                // Allocate needed buffer size here
                // This brings up a question -- can we assume that the drivers are smart
                // enough to work with C++ strings?  Will this need to be turned into a c_str()?
            }
            if ( *driverList[i].belongsToMe(Buffer) )  {
                // Implementation question (raised by Dyer):
                // Should the last chosen file type be propagated to the top of the list of
                // queried drivers?  This would mean if the user wanted to open 100 images in a
                // row, and get a pixel out of each one, and each file was the same type
                // (like VICAR), then each file after the first one would be read in as quickly as
                // possible because the VICAR driver would be the first one checked.
                return (&driverList[i].driver());
        }
        // No driver matched -- return unknown
        return (NULL);

    }
}
 

So the user does something like:

ICL_Image iclm = new ICL_Image("this_file");

The constructor for ICL_Image does something like this:

ICL_Image::ICL_Image(string fileName) {
    // blah blah, make buffer of default size, blah blah
    string Buffer[256];
    // Note that we don't have to instantiate the ICL_Interrogator class, it initializes itself
    // This means that the driver file only needs to be read once.
    driver theDriver = ICL_Interrogator.interrogate(Buffer);
    // We don't know what size the Buffer will be when it returns...
    header theHeader = theDriver.readHeader(Buffer);
}

This will then allow interrogation of the header and further reading of the file contents.  More to come...  and this
will probably change into a better object model when you guys review this... :)

-- 
When I use a word it means just what | John Ivens
I choose it to mean - neither more   | Principal Programmer
nor less.                            | Cassini VIMS
-- Humpty Dumpty                     | (520) 621-7301