We have discussed a few API breaking changes recently. Error
reporting, thread safety, C++ API changes and the Fortran API changes
are pretty close to complete by the seems of things.

Is it time to bring up the possibility of PLPlot 6 again and how we
intend to manage that?

Alan there are some further points below

>
>> I am a fairly recent convert to exceptions, but I now use them
>> throughout my C++ code, because using exceptions totally frees me from
>> having to worry about errors. I don't have to worry about checking
>> return values or  anything like that, I am free to concentrate on the
>> interesting aspects of the code writing, rather than getting bogged
>> down in error checking and avoiding memory leaks. But more
>> importantly, if used in well styled code, exceptions are bomb proof,
>> they actually make it impossible to miss or fail to deal with an
>> error.
>
>
> Is this possibility only available in C++?  If so, it does not help us
> with our core C library which does need an error reporting system now.
> We do not want to use the the possibility that we _might_ move to C++
> in the future for our core library as an excuse for inaction on this
> important topic for our current core C library.
>
Regarding this point - C can do similar things using the
setjmp()/longjmp() function and a resource pool/tracker. It is not as
simple to implement as in C++, but I still think it would be much
easier to implement and much easier to support than trying to
propagate error codes through our internals. I still strongly
recommend a read of that book chapter and if you ever feel like
experimenting with C++ that book is excellent, although a bit out of
date now we have C++11 and beyond.
It just dawned on me that we could simply put longjmp(errcode); inside
plexit() and then all we need to do is add the code to catch this in
the API functions and the job is complete.

Anyway please just have a read about exceptions before we make this call.

>However, it should be noted that memory allocation errors (for
>debugged code that calls malloc et al. correctly) are essentially
>always a sign of an emergency condition where you have run out of
>memory due to some process leaking memory like crazy.  And remember
>this is an extremely rare emergency condition in any case.  For
>example, in my decades of experience with PLplot I have _never_ seen a
>plexit message concerning memory allocation failing.  So my conclusion
>is an immediate exit is unlikely to irritate users in this
>one particular memory allocation error case.

I would suggest that we should report back on memory allocation
failures rather than exit. Even with a memory allocation failure,
someone using plplot in an application (e.g. in GDL) may be able to
offer their user a final chance to save their work, or may be able to
free some memory. I'm not sure I have ever hit a memory allocation
error within plplot, but I certainly regularly hit memory allocation
errors during data analysis in general.

Phil

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to