Andrew Yes that's exactly what I would do - use C++ internally, then have a C layer that interfaced outwards with error codes. I must confess to only recently realizing how amazingly useful C++ features like throwing errors and smart pointers are. But I now rely on them so much I actually genuinely struggle when using C style memory management and error checking.
Interestingly again the memory management issues would be more easily dealt with by use of a C++ array which knew its own size. Even then it would be a lot easier (but still easy to forget) to check the size had been increased. But anyway I am biased as C++ is my favorite language. I'm sure that there is more than one person on this list that would say that we could rewrite PLplot in python! Phil On 24 March 2015 at 13:07, Andrew Ross <andrewr...@users.sourceforge.net> wrote: > > Phil, > > The same thought had also crossed my mind. This is a more modern way to > handle errors. You would need the C interface to catch the exceptions and > return an error code since not all of our languages would handle them. > This might require C++ -> C -> some thing else which is not pretty > either... > > As you point out almost all plabort calls are memory management related > which does reduce the problem a bit. > > Andrew > > On Mon, Mar 23, 2015 at 04:51:44PM +0000, Phil Rosenberg wrote: >> Yeah it's something I've been thinking about too. But not a fun task. >> >> To be honest I was starting to think that the least intrusive method >> would be to convert everything to C++, with a C frontend and use >> try-catch blocks with throw. Well I'm joking - sortof. >> >> But yes this has caused me major pain in the past when using >> wxWidgets. Almost all abort calls are from memory allocation failures. >> so sorting resilience to these failures would be a major step in the >> right direction. >> >> Phil >> >> On 19 March 2015 at 21:25, Jim Dishaw <j...@dishaw.org> wrote: >> > >> > On Mar 19, 2015, at 4:03 PM, Andrew Ross >> > <andrewr...@users.sourceforge.net> wrote: >> > >> >> On Thu, Mar 19, 2015 at 03:30:21PM -0400, Hazen Babcock wrote: >> >>>> From: Andrew Ross <andrewr...@users.sourceforge.net> >> >>>> >> >>>>> The attached patch fixes the memory leak for me. Pressing the close >> >>>>> button >> >>>>> should now behave the same as pressing 'Q', i.e. it will abort the >> >>>>> program and clean up correctly. It looks like this was changed at some >> >>>>> stage in the past, but I don't know why. I guess this would allow a >> >>>>> programme to continue, and to potentially reopen a new xwin window. If >> >>>>> we >> >>>>> want to retain this functionality it will require a bit more thinking >> >>>>> about. >> >>>> >> >>>> Thinking some more about this, I seem to recall the change was made >> >>>> because of interactive bindings. For example, if you are using octave >> >>>> and >> >>>> pressed the close button then the call to plabort would kill your entire >> >>>> octave session which is clearly not desirable. We definitely don't want >> >>>> to >> >>>> apply my patch as is. I need to work through all the tidy up code in >> >>>> xwin.c to check exactly the path that is being followed. The current >> >>>> code >> >>>> is doing the right thing in terms of closing the window and ignoring all >> >>>> further commands to the plplot stream, we just need to ensure that the >> >>>> tidy function is called at the end. A clean way of doing this would be >> >>>> to >> >>>> have multiple levels of stream_closed. 0 = open, 1 = closed, but still >> >>>> need to call tidy, 2 = closed and tidy already called. >> >>>> >> >>>> Only the xwin and cairo drivers set this flag, but it is checked in the >> >>>> core plplot code. I can simply implement this change Alan, but your call >> >>>> whether you want to commit it at this late stage. It should be trivial. >> >>> >> >>> Yes, it was implemented for exactly the reason that you state. I added >> >>> this in September of 2010 (v11159, v11160). I'd appreciate if we did not >> >>> revert to the old behavior which was, in my opinion, very unfriendly. >> >> >> >> I agree Hazen. My fix (which I'll wait until post-release to apply) >> >> doesn't revert to calling plabort. >> >> >> >> This strikes me as another reason why we need to bite the bullet and tidy >> >> up our error handling in plplot. We really need to get rid of plabort() >> >> and >> >> all the calls to exit(). Libraries shouldn't exit - they should return an >> >> error and let the calling program make the decision. >> >> >> >> We've known this for a long time, but it will be a pretty intrusive (and >> >> backwards incompatible) change to plplot. Maybe I should just take this on >> >> post-release if others are in agreement. >> >> >> > >> > I was planning on cleaning up error and warning handling post-release. >> > While working on plbuf and metafiles, I kept grappling with how to best >> > handle errors and warnings. >> > >> > >> > ------------------------------------------------------------------------------ >> > Dive into the World of Parallel Programming The Go Parallel Website, >> > sponsored >> > by Intel and developed in partnership with Slashdot Media, is your hub for >> > all >> > things parallel software development, from weekly thought leadership blogs >> > to >> > news, videos, case studies, tutorials and more. Take a look and join the >> > conversation now. http://goparallel.sourceforge.net/ >> > _______________________________________________ >> > Plplot-devel mailing list >> > Plplot-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/plplot-devel >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for >> all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Plplot-devel mailing list >> Plplot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
