> -----Original Message-----
> From: Hazen Babcock [mailto:hbabc...@mac.com]
> Sent: Monday, May 25, 2015 7:18 PM
> To:plplot-devel@lists.sourceforge.net
<mailto:plplot-devel@lists.sourceforge.net>
> Subject: Re: [Plplot-devel] PLPlot 6 and C++
>
> >
> > 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
<mailto:Plplot-devel@lists.sourceforge.net>
>https://lists.sourceforge.net/lists/listinfo/plplot-devel
DISCLAIMER: This message is intended exclusively for the addressee(s)
and may contain confidential and privileged information. If you are
not the intended recipient please notify the sender immediately and
destroy this message. Unauthorized use, disclosure or copying of this
message is strictly prohibited. The foundation 'Stichting Deltares',
which has its seat at Delft, The Netherlands, Commercial Registration
Number 41146461, is not liable in any way whatsoever for consequences
and/or damages resulting from the improper, incomplete and untimely
dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
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
<mailto:Plplot-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/plplot-devel
