Hi everyone,
An issue related to the use of C++ that has not been raised yet, but which
surfaced recently in my comprehensive testing efforts is the fact that linking
a C++ program requires a C++-enabled linker. Thus introducing C++ as the
language in which PLplot is to be implemented would complicate the use of
static builds. That may not be the most common option nowadays, but I think we
need to take a conscious decision: do we want to continue to support static
builds or not? One pro for static builds is that they make deployment,
especially of binary-only distributions much easier (and safer).
Regards,
Arjen
> -----Original Message-----
> From: Hazen Babcock [mailto:hbabc...@mac.com]
> Sent: Monday, May 25, 2015 7:18 PM
> To: 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
> 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
https://lists.sourceforge.net/lists/listinfo/plplot-devel
