dive table and pointers

Linus Torvalds torvalds at linux-foundation.org
Thu Dec 26 16:05:56 UTC 2013


Maybe you could keep a plot_info around as a cache, and then associate that
cache with a magic pointer. And if that magic pointer matches the current
dive pointer (which you get with get_dive()) *and* that dive hasn't been
marked modified, you could trust the current plot info. So you'd use that
magic pointer just to validate things, never as a real pointer that you
actually dereference.

So what you should *never* do is to save of pointers to the dive structure
or to parts of it. Never.  But having a separate dive_info structure that
contains our plot calculations may make sense (we obviously already do
that, it's just that we recalculate it all the time)

    Linus
On Dec 26, 2013 3:02 PM, "Tomaz Canabrava" <tcanabrava at kde.org> wrote:

>
> Em 26/12/2013 20:06, "Dirk Hohndel" <dirk at hohndel.org> escreveu:
> >
> >
> > Tomaz,
> >
> > you asked this on IRC while I was unavailable:
> >
> > There are good reasons why you can't keep pointers to dives around and
> > why you can't simply claim that the position in the dive table
> > represents a specific dive:
> >
> > Things move around.
> >
> > If you download dives from a dive computer or import dives from a file
> > or webservice, dives could be merged - that creates a new merged dive
> > and the two original dives are discarded, so the pointer to a dive could
> > become invalid. Similarly, if you edit a dive and change its start time,
> > the order of the dives in the dive table can change and your "dive #n"
> > in the table might actually be a different dive.
> >
> > Of course we could keep a meta structure that stays consistent across
> > all these operations. You'd get a 'key' that identifies a dive and that
> > key would always give you that dive until it no longer exists.
> >
> > Would that make your life easier? I'll be happy to look into a way to
> > organize our data that way - but it will require some very careful work
> > to make sure that all of the manipulations of the dive table that we do
> > today continue to keep this in a consistent state.
>
> Dirk
>
> I'm redoing the profile as you know, and some stuff that's required is
> that the profile shouldn't need to replot if the dive table changes but the
> selected dive didn't. ( but it's in other part of the table, so it actually
> changed, but it's still the old dive.).
>
> The other thing that I'm trying to do is to create some dive from the
> planner / add dive profile ( that should be the same profile)  but I don't
> want the magic numbers that we have on our code right now. I want the
> entered profile to have a bool handEntered on each stop, is that possible
> or this will increase considerably the size of the memory? ( I know that On
> XML this won't, since we just need to mark the ones that were handEntered.)
>
> The other thing that I m trying to do are unit tests, so things will not
> break easily on next versions. =)
>
> Tomaz
>
> >
> > /D
> >
> > _______________________________________________
> > subsurface mailing list
> > subsurface at hohndel.org
> > http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20131226/54d7d48c/attachment.html>


More information about the subsurface mailing list