Data passing problem

[Robert Helling]

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.

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  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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171124/9c3cdedb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171124/9c3cdedb/attachment.sig>