On Tue June 3 2008, Akarsh Simha wrote: > > > + Storing a pointer to the spectral type string in > > > SkyObject::SpType, instead of the string itself. > > > > This is a very minor point but I don't understand why you did this. > > Wouldn't it be better (faster, smaller) to store the string itself > > instead of a pointer? > > That was required so that we don't segfault when we do a memcpy(). I > only have a vague idea of how this saved us from segfaulting. I > notice that QString stores the data as a pointer to the data, so we > might be overwriting the same thing, but I don't know why it > segfaulted. Yes, A QString could be a problem. When you said "string" I though you meant char[size]. Those QStrings are a big PITA. Ideally, we could store the SpType as a char[size] in the StarObject and then do any internationalization or translation when we are actually outputting the data to the screen (assuming this is a very infrequent event). If the dms'es are stored in the SkyPoint as *values* then there should be no problem. It is only when there are pointers (or references) in the data structure that we run into a problem. If they are stored by value then we might need a SkyPoint::init() routine to makes sure they get properly re-initialized when we load in new RA and Dec values. As you said, these fields in SkyObject, could all be problematic: QStringList ImageList, ImageTitle; QStringList InfoList, InfoTitle; QString userLog; I agree with you that SkyObject::name, ::name2 and ::longName would be better (for our purposes) as pointers. Then all the unnamed stars would have pointers to the same set of names and named stars would have their own pointers. The other QString and QStringList members of SkyObject are more of a problem. If all of these fields will be required for unnamed stars then we will have to take evasive action. IMO, the best solution (for the long term) would be to create an AuxInfo structure that contains those fields and in the star (or SkyObject) just have a pointer to AuxInfo that is normally NULL. Then when any of those fields are needed a new AuxInfo object is created and the pointer is filled in appropriately. Unfortunately, even this will break when we swap out a star and then later swap it back in. This means we need to find out which of these fields are required for the unnamed stars that will be loaded dynamically. If any of these fields will be needed then we need to know what is supposed to happen to them when we swap stars in and out. If the information in these fields needs to be retained, we need to have a unique ID for every star and store the AuxInfo in a hash keyed off of this unique ID. This is assuming that relative few stars will need to have any of those fields filled in. If this is our own ID, we don't have to store it in the StarData structure. We can use a combination of the trixel number and the position of a star in the list to make a unique ID. For example, the highest 10 bits could be the trixel and the remaining 22 bits could be based on the order within each trixel. This would allow over 1 million stars per trixel which should be ample for now. We will need input from Jason before moving forward here. > > I don't think adding the HD number will help solve this problem, > > but I think it is a good idea to have the HD number in the starname > > file anyway for other reasons (error detection). > > Will a HD number not help, because it cannot be searched easily in > the starnames.dat file? I think having a unique ID for every named star would solve the initialization problems but there are other problems that will only get solved by keeping the named stars in a separate data structure. > One solution is to put a UID in the name data file, as I mentioned > earlier, and quickly look that up. The HD number, as I infer from > this source, > http://www.willbell.com/software/hypersky/hd.htm > goes upto a maximum of about 360000. We could use the remaining bits > to hold a UID for named stars. The lower 19 ~ 20 bits could be > provided for the HD numbers and the upper 11 ~ 12 bits for the UID > for named stars. How does this work? > > That way, we can duplicate star entries and still be able to look up > star names randomly, by fseeking to a position that we can compute > based on the sequentially assigned UIDs. I agree with you in theory that we could have named stars amongst the stars that get dynamically loaded if we keyed off of a unique ID. But if we were to do that then don't want to do an fseek for each named star. Instead we should store the (very small) list of non-global names in a simple QHash keyed off of the ID number. But the problem is that this doesn't necessarily solve all of our problems with named stars. I think there might be other lingering problems that keeping the named stars in a separate list will avoid. IMO keeping the named stars in a separate list will be simpler, easier to implement (all the code already exists, you just have to write the StarBlock code which you will have to write anyway) and less likely to interact badly with the rest of KStars. But I'm not going to insist that you do it my way. There is probably more work you can do for now, but we really need to find out ASAP from Jason what he wants to do with the QString and QStringList SkyObject fields in the dynamically loaded unnamed stars. There might be other possibilities but three options I see now are: 1) Just ignore them because will we never use them. 2) Use them temporarily but let them be erased if stars are swapped out. 3) Use them and remember the stored values even if stars get swapped out. Even if we can't immediately implement what Jason wants, we want to know what it is that he wants so we can incorporate the hooks into our design. I wonder if we might want to create an UnnamedStar class that subclasses directly from SkyPoint and bypasses SkyObject. -- Peace, James _______________________________________________ Kstars-devel mailing list Kstars-devel@kde.org https://mail.kde.org/mailman/listinfo/kstars-devel