I just realised I forgot one thing
There isn't a standard 2D container in C++, so you have to create a
vector of vectors, something like
std::vector<std::vector<double>> myMatrix;
However a lot of people don't like this as it is generally considered
rather slow. So I think there are lots of other things people use
including Eigen or Boost classes or just plain C matrices or their own
home solutions.
We should certainly maintain and if needed extend the C++ model that I
think Andrew designed which wraps any kind of 2D array in an class
where the user provides a method to access the required elements.
Phil
On 19 January 2016 at 12:32, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> 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
