dive table and pointers

[Tomaz Canabrava]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20131226/64e681ee/attachment.html>