> On May 25, 2015, at 1:29 PM, Arjen Markus <arjen.mar...@deltares.nl> wrote:
>
> 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
>
>
I don’t have a strong opinion either way on the C++ vs C and I think we can
achieve design objectives with either language. I do think we run the risk of
breaking compatibility with some percentage of the current uses of PLplot.
My biggest concern, however, is that switching to C++ will consume a big chunk
of time. If we are going to make that investment, then a good scrub of the API
should be done to make sure we do not handicap ourselves.
My top recommendation is that we appoint a manager of the legacy PLplot to
support the users during the transition. My gut feeling PLplot 5 will be
around for quite awhile.
> > -----Original Message-----
> > From: Hazen Babcock [mailto:hbabc...@mac.com <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
> > <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
> > <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_______________________________________________
>
> <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
> <https://lists.sourceforge.net/lists/listinfo/plplot-devel>
------------------------------------------------------------------------------
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
