Re: struct variable definition (in var.h)

[John Darrington]

On Mon, Nov 08, 2004 at 11:00:23PM -0800, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     
     > 1.  Forget the whole thing.  Just let each command allocate the data
     >     it needs on the heap, and keep track of what variable it belongs
     >     to.
     >
     > 2.  Have a generic (void *) pointer instead of the union.  Commands
     >     will still be required to allocate and deallocate the memory, but
     >     the pointer keeps track of the variable to which they refer.
     >
     > 3.  As above, but have each command register a function to allocate
     >     and de-allocate the memory.  Some lower level of PSPP (which I'll
     >     call the `allocator') will call these functions as appropriate. 
     >     The allocator will need to provide an interface which commands
     >     will use to declare which variables are of interest.
     
     I took another look at this tonight, and now I remember why I
     didn't follow through on #1 earlier: it's seriously not a simple
     thing to do.  Take the `get' member for example.  This gets
     initialized by sfm_read_dictionary() when we read a system file
     dictionary from disk, and then it's used later when we actually
     read cases from disk.  Between those times, variables in the
     dictionary may be added, deleted, renamed, or reordered at will,
     so that without some kind of identifier that travels along with
     the variables themselves there's no way to connect the data on
     disk to where it's supposed to go in the dictionary.
     
     That's kind of a "worst case".  The other cases are not so bad,
     but at least the first few that I looked at also demonstrate that
     it's not as simple as I'd hoped.
     
     Maybe #2 or #3 is a better option.
     
     Ideas?

Well #2 is the simpler.

And I notice that get.c actually does this with the void *aux member.
Just for an experiment I deleted aux from the definition of struct
variable, and it seems that get.c is the only module which uses it.

If I understand it correctly however, get.c is different from the
other situations in so far that it needs this pointer to persist after
the GET command has returned?  This must be true since the other
commands use members of a union, so each command will stomp on the
others' memory.

So would it be too ugly if we retain the void *aux pointer for use
only by the GET command?  Let's change its name and type to something
more specific.

So as for the union, we have:

        struct crosstab_proc crs;
        struct frequencies_proc frq;
        struct list_proc lst;
        struct means_proc mns;
        struct group_proc grp_data;

I don't think any of these will suffer if they're forced to use the
heap. And:

        struct matrix_data_proc mxd;
        struct match_files_proc mtf;

I'm not sure about these two.  If necessary they could have their 
own dedicated pointer  too.

So  we would have replaced one union of  7 structs with 2 (or less)
pointers.  Perhaps not ideal, but at least an improvement.

J'





-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://wwwkeys.pgp.net or any PGP keyserver for public key.

pgpTUmQT7Q2TK.pgp
Description: PGP signature