Data passing problem

Fri Nov 24 00:38:47 PST 2017

On Fri, Nov 24, 2017 at 9:10 AM, Robert Helling <helling at lmu.de> wrote:

> Hi,
>
> in my ongoing project of localising all planner variables (so that it can
> run concurrently) I ran into a problem that I don’t see an elegant solution
> for. Maybe somebody else can enlighten me in how to approach this:
>
> First of all, there are the two parts of the code: The internals written
> in C and the UI/Qt part written in C++. At the time we moved from GTK to
> Qt, it was announced that the general strategy should be that C++ calls C
> (considered as elaborate helper functions) but not the other way around.
> There are a few exceptions to this rule and those are assembled in
> qthelper.cpp which has a number of extern “C” functions to be used for
> example in places where the advanced data structures of Qt come in handy (I
> used it to access hash tables and locks for example). This is the general
> theory.
>
> In the planner we have the following situation: There is the UI where the
> different waypoints are entered. This is represented by a
> DivePlannerPointsModel, basically a pimped version of the table of
> waypoints. As soon as anything in this model changes (or other parameters
> are changed in the UI), we need to compute a new deco plan. This is done in
> plan() from the C part, in planner.c to be precise. The output of that is a
> struct dive that holds the information about the entire dive including deco
> (and notes). This goes to displayed_dive.
>
> Then it is signalled to the profile display that it should update itself.
> The profile widget then invokes functions from profile.c to turn the
> information in displayed_dive into a form that holds the information of
> what is actually going to be plotted.
>
> So far so good. Only calls C++ -> C.
>
> But now comes the problem: it is one of the stupidities that the ceiling
> does not only depend on the actual dive (i.e. the depth profile and what
> gas was breathed at which point) but also on the duration of the deco phase
> of the dive (called deco_time) and the ceiling at a certain point in the
> dive. But which part of the dive is actually the deco part does not have a
> good definition (except in the planner where it is defined to be that part
> of the dive that was not entered by the user but which was computed by the
> computer). This information is known in the planner plan.c (and now
> contained in the deco_state struct which I want to turn into a local
> variable). But this information needs to get to profile.c.
>
> It makes sense that it is actually the PlannerPointsModel that sets up the
> memory for this deco_state and hands down a pointer to it when it calls
> plan() so plan can populate this info. Thus after plan() ran, the
> PlannerPointsModel knows the deco_duration. But how can I get it to
> profile.c?
>
> What I tried was to add a function to qthelper.c that invokes
> PlannerPointsModel::instance() to ask it for a pointer to its struct
> deco_state. This could then be called from profile.c and Bob is your uncle.
> This is what I did in commit
>
> https://github.com/Subsurface-divelog/subsurface/pull/843/commits/
> 1ead4398b982bd2ff1ecbcb3be3ee9434cef8e3f
>
> But now the linker complains that it doesn’t know about
> PlannerPointsModel::instance(). So yes, probably I could change some
> CMakeLists.txt (which I still would have to figure out how) to make sure
> qthelper.cpp gets linked against our model library. But on IRC, Tomaz
> advised me against this (before disappearing).
>
> So, I am clueless: How am I supposed to solve this?
>
> Let me mention that in our code up to now we solve this by making struct
> deco_state (or at least deco_time) a global variable. This is of course the
> ugliest possibility that I want to get rid of.
>

Sorry, I didn't disappear, I actually said what could be done to fix this
in a kind-of-sane-way.
The problem is not C++ -> C, as we have qthelper.cpp that has many c++
functions that are exported as C and C code calls it.
The problem is the same we had in the Gtk days: If we allow everything to
call everything, our code will be a tangled mess again (and I spend a long
time untangling the interface, then untangling the interconnected parts of
the interface).

(plan for the future, less globals, more passing variables around)

I see two ways to deal with that:

1 - in planner.c define a (deco_struct*)(fetch_deco_information_callback)
and set this callback in PlannerModel, so you can call the function pointer
without linking to the library

2 - pass the pointer to the deco_state in the plan() function as a
parameter from the PlannerModel.

Tomaz

> Best
> Robert
>
> --
> .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.
> oOo.oOo.oOo.oOo.oOo.oO
> Robert C. Helling     Elite Master Course Theoretical and Mathematical
> Physics
>                       Scientific Coordinator
>                       Ludwig Maximilians Universitaet Muenchen, Dept.
> Physik
>                       Phone: +49 89 2180-4523 <+49%2089%2021804523>
>  Theresienstr. 39, rm. B339
>                       http://www.atdotde.de
>
> Enhance your privacy, use cryptography! My PGP keys have fingerprints
> A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
> DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F
>
>
>
>
>
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171124/100879f3/attachment-0001.html>