Hi Alan I've cut and pasted some bits together of your last couple of emails
> However, isn't being forced to use separate threads in order to > (automatically) have separate PLplot contexts for each thread a > relatively minor inconvenience compared to the very much larger user > inconvenience required by adding a context address to most API calls? > Not necessarily. This may force someone to restructure their code as they would have to have separate contexts in separate functions and may actually generate race conditions that people will need to deal with using mutexes. >I believe there are some 300 functions in our public and private API, >and not all of those will be affected by this (because there are no >error conditions they generate or they need to propagate). So I would >estimate "hundreds" of functions rather than "thousands" would be >touched by this propagation effort. Note that some functions are called tens of times within plplot, and with an error code return mechanism it is each call that needs a check. Also some functions return values; this would need restructuring with the potential for introducing bugs - possibly very hard to find bugs. In each function there would need to be an examination of all the memory allocations and code would need to be introduced at each check point to do freeing to avoid memory leaks. >Also, I think the editing task for propagating return codes would be a >similar effort to the editing task for replacing the call to plexit by >the generation of the equivalent message to stderr and an immediate >return with non-zero return code. Note, the number of plexit calls is >220, By contrast with an exception model we have less than 1 change to make per plexit call. These can almost be done by find and replace. You may wonder why this is less than. I imagine almost all of those are memory allocation failures. If we create a plmalloc function which allocates and tracks memory then this function can generate the exception if the memory allocation fails. This removes all requirements to even check whether a memory allocation has succeeded. Almost all the plexit calls vanish by writing just one function, but even better all the cases where we were lazy and didn't bother to check if our allocation succeeded (I wonder how many of those exist in plplot right now?) get automatically fixed. 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. However I used to think exceptions were just a feature that I didn't really understand I probably didn't need to. The thing that changed my mind was some reading about coding style. Can I strongly recommend that you have a look at chapter 10 of C++ In Action: Industrial-Strength Programming Techniques. It has been published online for free and you can find this chapter at http://www.relisoft.com/book/tech/5resource.html. The important bit is from the beginning to the subsection Ownership of Resources. I know you are not big into C++, but all you have to know to understand this part of the chapter is that in C++ new is basically like malloc, delete is basically like free, when you create an object (either statically or using new) a function called its constructor is automatically called and when it goes out of scope (or if you delete it after creating it with new) then a function called its destructor is called. It may help to know that earlier in the book they create a calculator project as an example which gets briefly referred to. Reading this chapter was a revelation to me! >For each replacement of a "plexit" call you simply check >(by testing with a temporary fake error message and temporary fake >non-zero return code) that the fake return code propagates correctly. I'm not sure how you practically do this? Nor am I sure this is maintainable. Don't forget that a program may reach many potential plexit calls with a single API call and it may reach the same plexit call multiple times, but in different states. We also need to check for memory leaks. The testing required sounds huge to me. Anyway, sorry if this sounds negative, it's not meant to be. As I said I've found exceptions quite recently and they have revolutionised my coding style, so I feel quite passionate about them. 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
