I'm perhaps less keen on the idea of using the minimum dimension.
Passing unequal sized arrays is clearly and error and so I think we
should flag it is such is the loudest way possible so the user can fix
it. I think the times when I have often got this wrong are off by one
cases and getting x and y the wrong way round in contour plots. In an
off by one case if we just plot the data regardless then the user is
quite likely to never notice - in fact if we are off by many (perhaps
the user passes a filtered array in for x and an unfiltered array in
for y) then the results may be absolutely incorrect but the user may
be unaware.
Regarding C++, this is a bit tricky. But the short answer is that the
best way to do this would be to turn out our C++ driver into header
only code. This can be done by simply inlining all the methods, or we
could template it something like this
template<class ARRAY>
void plstream::someFunction(const ARRAY &x, const ARRAY &y)
{
plsomefunction( x.size(), &x[0], &y[0]);
}
then in the main program
plstream pl;
//we can call someFunction with std::vectors of doubles
std::vector<double> x;
std::vector<double> y;
pl.someFunction (x, y);
//or if someone has a different array type class
myCustomArray x;
myCustomArray y;
pl.someFunction(x,y);
In fact plstream::someFunction can be called with any class which has
a size method and for which the &x[0], &y[0] syntax makes sense, so it
would need to understand operator [] and it would have to have all its
elements in contiguous memory.
So that is probably the "best" way, depending upon how you define
"best". It is possible to just allow plstream to accept
std::vector<double> arrays, which is the built in C++ array, however
there are complications. I won't go into the details here, but
basically to do this we need the following
1) The library and the dll must be built with the same version of the
same compiler useing the same compiler and linker flags. This is
because C++ barely touches on defining the binary interface of the
language. If this isn't the case then at best you will get linker
errors or at worst weird run time errors because a library built in
MinGW has a different structure for its std::vector than the
executable built in VC++. By using header only code we guarantee this
because our code gets built into the exe.
2) On windows dlls and exes have their own heap so we cannot resize
any std::vectors that are passed in. That would involve attempting to
free memory the dll doesn't have access to then allocating memory that
the exe wouldn't have access to. This isn't an issue for us though as
we don't resize them.
There are lots of (mostly not very well written) things online about
C++ and dll boundaries. There is something called plain old data (POD)
which is I think the only place the standard really gets involved in
binary interfaces. POD is standard types and classes containing only
POD with no user defined destructor and some other limits. These can I
think be safely passed into and out of a dll because they are pretty
much like C structs with methods. stl containers including std::vector
are not POD.
Don't know what your thoughts are there Alan?
Phil
On 19 January 2016 at 07:50, Arjen Markus <arjen.mar...@deltares.nl> wrote:
> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>> Sent: Tuesday, January 19, 2016 4:47 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] Redacted dimension arguments
>> …, I came up with the following cunning plan....
>>
>> My new plan for handling redacted dimension arguments for the Fortran
>> binding is
>> simply to calculate n as the minimum dimension of the associated arrays
>> with the
>> only sanity check imposed on our users being that the resulting n > 0. I
>> think this
>> way of handling things is a good one because it still gives the users some
>> type of
>> plot (and no memory management issues) even if they screw up and have one
>> associated array inadvertently shorter than the rest.
>>
> I agree on this wrt one-dimensional arrays that are passed, but for
> two-dimensional arrays there is a slight complication with this scheme.
> Thinking out loud here …
>
> Suppose the user passes arrays x(10,10) and y(20,20) to a contouring
> routine, then the most consistent way for the wrapping routine to pass these
> two arrays would be to take an array section: x(1:10,1:10) and y(1:10,1:10).
> Hm, that could be done easily with Fortran – since the C routine has no
> notion of non-contiguous array sections, the interfacing features will
> transform it into a temporary array that is contiguous. No copying back is
> required as the arguments are intent(in).
>
> Okay, this should work – provided it can be done for other bindings in the
> same way. I cannot comment too much on this aspect.
>
> Your remark about the Tcl binding not using redacted dimension arguments
> triggered me look at it again. The current bindings use the matrix data type
> to store the values and that type does actually keep track of the
> dimensions, so with a twist to that binding, we can get the same benefits.
>
> Regards,
>
> Arjen
>
>
>
> 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.
>
> ------------------------------------------------------------------------------
> 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=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
------------------------------------------------------------------------------
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=267308311&iu=/4140
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
