[Kstars-devel] Great minds think alike: AuxInfo Hash

[James Bowlin]

It seems like we are converging on a solution to the auxiliary QString 
and QStringList fields in SkyObject.

I agree that would should probably hold off implementing the AuxInfo 
hash until a later phase of the project, but I think it would be good 
to think through the logic so we don't needlessly paint ourselves into 
a corner.

My suggestion of using essentially the location of a star in the 
stardata file as a unique key to the AuxInfo hash won't work because we 
are planning to duplicate a few stars to deal with proper motion.  If 
the current HD index is non-negative then we can covert it to a unique 
ID by using negative numbers to uniquely identify stars that are not in 
the index.  The brightest star not in the index would get an index 
of -1, the next brightest would get an index of -2 and so on.  This 
gets us a unique ID without needlessly increasing the size of the 
StarData struct.

Even if we want to disable the AuxInfo fields for unnamed stars for now,
I think we may need to do something in order to prevent segfaults and 
memory leaks when we dynamically load stars.  I think either unnamed 
stars will have to no longer subclass from SkyObject or we are going to 
have to change the SkyObject data structure.

I think the best thing to do is to create a new AuxInfo struct/class 
that contains these fields that are currently in SkyObject:

    QStringList ImageList, ImageTitle;
    QStringList InfoList, InfoTitle;
    QString userLog;

In the SkyObject class, these fields would be replaced by a single 
pointer to an AuxInfo object.   By default the pointer will be NULL
indicating that no AuxInfo object yet exists.  For most things, the
AuxInfo object could be created at construction time, although we could 
save a little RAM by only creating AuxInfo objects when they are 
needed.

For unnamed stars, for now, the AuxInfo pointer would always be NULL.
All the routines that make use of the AuxInfo fields would have to
check for a NULL pointer and return gracefully if the pointer is NULL.
This is perfect because we can use that hook to dynamically create 
AuxInfo objects for everything except unnnamed stars.

There may be a better way of handling this problem but that is the best 
that I've come up with so far.  I think what I've outlined above could 
be done in less than a day.

This also creates the hooks needed for implementing a hash of AuxInfo
objects for unnamed stars.  When an AuxInfo object is required for an 
unnamed star, instead of simply creating a new AuxInfo object, we first 
check the hash to see if an AuxInfo object for this star already 
exists.  If so, we set the AuxInfo pointer to the location of the 
existing AuxInfo object.  If not, we create a new AuxInfo object, add 
it to the hash and set the pointer.

Any thoughts?

I think we may have to implement the AuxInfo class and pointer now in 
order to prevent problems with dynamically loading stars even if we 
decide to hold off on implementing the AuxInfo hash.


-- 
Peace, James