<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 24, 2017 at 9:10 AM, Robert Helling <span dir="ltr"><<a href="mailto:helling@lmu.de" target="_blank">helling@lmu.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi,<div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So far so good. Only calls C++ -> C.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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 </div><div><br></div><div><a href="https://github.com/Subsurface-divelog/subsurface/pull/843/commits/1ead4398b982bd2ff1ecbcb3be3ee9434cef8e3f" target="_blank">https://github.com/Subsurface-<wbr>divelog/subsurface/pull/843/<wbr>commits/<wbr>1ead4398b982bd2ff1ecbcb3be3ee9<wbr>434cef8e3f</a></div><div><br></div><div>But now the linker complains that it doesn’t know about PlannerPointsModel::instance()<wbr>. 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). </div><div><br></div><div>So, I am clueless: How am I supposed to solve this?</div><div><br></div><div>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.</div></div></blockquote><div><br></div>Sorry, I didn't disappear, I actually said what could be done to fix this in a kind-of-sane-way.</div><div class="gmail_quote">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.</div><div class="gmail_quote"></div><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">(plan for the future, less globals, more passing variables around)</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>I see two ways to deal with that:</div><div><br></div><div>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 <br></div><div><br></div><div>2 - pass the pointer to the deco_state in the plan() function as a parameter from the PlannerModel.<br></div><div><br></div><div>Tomaz<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>Best</div><span class="HOEnZb"><font color="#888888"><div>Robert<br><div>
<div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br>-- <br>.oOo.oOo.oOo.oOo.oOo.oOo.oOo.<wbr>oOo.oOo.oOo.oOo.oOo.oOo.oOo.<wbr>oOo.oOo.oOo.oOo.oOo.oO<br>Robert C. Helling Elite Master Course Theoretical and Mathematical Physics<br> Scientific Coordinator<br> Ludwig Maximilians Universitaet Muenchen, Dept. Physik<br> Phone: <a href="tel:+49%2089%2021804523" value="+498921804523" target="_blank">+49 89 2180-4523</a> Theresienstr. 39, rm. B339<br> <a href="http://www.atdotde.de" target="_blank">http://www.atdotde.de</a></div><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br></div><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">Enhance your privacy, use cryptography! My PGP keys have fingerprints</div><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">A9D1 A01D 13A5 31FA 6515 BB44 0820 367C 36BC 0C1D and</div><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">DCED 37B6 251C 7861 270D 5613 95C7 9D32 9A8D 9B8F</div><div style="color:rgb(0,0,0);font-family:Menlo;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br></div></div></div><br class="m_-5668166846216813739Apple-interchange-newline"></div><br class="m_-5668166846216813739Apple-interchange-newline"><br class="m_-5668166846216813739Apple-interchange-newline">
</div>
<br></div></font></span></div><br>______________________________<wbr>_________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.<wbr>org</a><br>
<a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface" rel="noreferrer" target="_blank">http://lists.subsurface-<wbr>divelog.org/cgi-bin/mailman/<wbr>listinfo/subsurface</a><br>
<br></blockquote></div><br></div></div>