On Fri, Nov 24, 2017 at 9:10 AM, Robert Helling <[email protected]> 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 > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
