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.
Probably the biggest issue is the use of plsc.
Consider two threads which both set different streams then call
another plplot function function. Between the first thread's call to
set the stream and it's subsequent call to the other function it is
entirely likely that the second thread will change
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
On 2015-03-24 14:59- Phil Rosenberg wrote:
> Probably the biggest issue is the use of plsc.
>
> Consider two threads which both set different streams then call
> another plplot function function. Between the first thread's call to
> set the stream and it's subsequent call to the other function
> On Mar 24, 2015, at 2:00 PM, Alan W. Irwin wrote:
>
>> On 2015-03-24 14:59- Phil Rosenberg wrote:
>>
>> Probably the biggest issue is the use of plsc.
>>
>> Consider two threads which both set different streams then call
>> another plplot function function. Between the first thread's ca
On 2015-03-24 14:55-0400 Jim Dishaw wrote:
> One solution to the plsc issue is to use thread local storage. Both gcc and
> msvc support it.
I had frankly never heard of that, but I have now looked it up, and it
does sound like it might work, but with some caveats.
The biggest of those in my opi
