> > On 2015-05-22 13:00+0100 Phil Rosenberg wrote: > >> Hi All >> I mentioned this briefly during the previous release cycle, but we all >> had more pressing things to deal with. Dealing with errors is >> something we really need to get a hold on for PLPlot 6 and one of the >> big drivers for considering a major API change. However, I am certain >> that the reason why this has been a problem s that propagating those >> errors back up through many layers of function calls is tedious and >> error prone so it has been much simpler to simply call exit(). >> >> Here is one possible solution. We switch the core code to C++ with a C >> frontend. >> > > However, let's be clear here the cost of that benefit is > likely to be considerably higher than you are estimating now. > For example, there is going to be substantial costs in terms of > doxygen and DocBook documentation, and also the domestic bindings and > foreign bindings (e.g., the PDL and Lisp bindings for PLplot) are of > some concern. Of course, in theory you could write a perfect C wrapper > library for the C++ core so bindings on that C wrapper work just as > well as they do for PLplot 5. But that C wrapper would really > have to be perfect and would make the bindings less efficient. Note, > I don't want to emphasize that last point too much since reliability > is much more important to me than speed. But at some point, I assume > you will want to address that issue (e.g., for the swig-generated > bindings) by ignoring the C wrapper and binding directly to the C++ > core instead which adds to the cost of this change.
I agree with Alan that it is not immediately obvious that this approach will save a lot of effort. All the API functions are going to have to be modified anyway, even if only to return some sort of no error code. This in turn will mean updating all the examples and a lot of the documentation. So the additional saving might be something like 10% on top of this? A C++ solution would also involve adding "extern" to every part of the API that we want to expose. It could be argued that the exercise of dealing with the propagation issues might help to clean up issues that were otherwise just papered over. I think we'd have to do this anyway in order to take advantage of your proposal to use the out of scope array deletion feature of C++, as every array in PLplot is now going to have to be a C++ object. This is also going to be a lot of work, though we'd face similar cleanup issues in C. By my count there are currently 146 calls to plexit() in PLplot core, most of which are related to memory allocation. So I lean slightly towards staying with C, but if others think that C++ is the way to go, then that is ok with me and I'll try to help with things like updating the examples, documentation, etc. Some questions: 1. C++ compilers are universal? Are there any major platforms that we want to support that do not have readily available C++ support? 2. In my readings on this subject some have mentioned that a C++ compiler can be substantially slower? Is this true? Significant? -Hazen ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
