[Kstars-devel] Making all sky components static

James Bowlin bowlin at mindspring.com
Sat Jun 21 00:50:06 CEST 2008


On Fri June 20 2008, Akarsh Simha wrote:
> Yes. I wanted to make StarComponent singleton. I don't know whether
> it would make sense. We can avoid doing this with some
> pointer-passing, but I don't think that will be clean. I like the
> idea of doing a StarComponent::Instance()->m_StarBlockFactory rather
> than
> StarComponent::m_StarBlockFactory that I presently do. The present
> code will cause serious problems if there were two StarComponents
> using this data structure - I doubt there will ever be such a
> situation, but I'm looking at it from the code quality
> perspective. Should I make StarComponent a singleton?

Have you considered making SBF a singleton?  Would that solve this 
problem cleanly?   Are you saying that multiple StarComponents  would
have difficulty sharing the same StarBlockFactory?  

I ask because I think (someday in the future) we may want to have more 
than one StarComponent instance.  Here is one way it might go.  First 
we would split up StarComponent into NamedStarComponent and 
DeepStarComponent as we've discussed before.  Then we would make the 
star data file (and hence the mesh size) a DeepStarComponent ctor 
parameter and this is how we would support multiple mesh sizes for
deep catalogs.  But all the DeepStarComponents should share the same
StarBlockFactory (I think), otherwise there will be tremendous wastage
since blocks used when we are way zoomed in couldn't be recycled for use 
when we are zooming out.

But if you prefer to make StarComponent a singleton right now, I would
not object even if it might mean a little extra work in hypothetical 
future scenarios.


-- 
Peace, James


More information about the Kstars-devel mailing list