[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