Oh and a final point. We should think carefully before removing the
forms where we pass in a raw pointer and a number of elements. There
are cases where only a raw pointer will do, such as when the array
class doesn't have a size method or the array class uses () instead of
[] for element access. A user can write an interface class to deal
with that, but then we have made the interface less user friendly not
more. e.g
class myArray
{
public:
size_t getSize(){ return m_nElements;} //get the number of elements
const double &operator()( size_t index) {return
*(m_pointer+index);}//get an element
private:
size_t m_nElements;
double *m_pointer;
};
//now this won't compile as there is no size method, nor any operator[]
myArray x;
myArray y;
pl.someFunction(x,y);
//the old method used to work
pl.someFunction(x.getSize(), &x(0), &y(0));
The user now has to create an interface class to link plplot to
class plInterface
{
public:
plInterface( myArray *array ){m_myArray = array; }
PLINT size(){return m_myArray.getSize();}
const double &operator[](size_t index){return (*m_myArray)(index);}
private:
myArray *m_myArray;
};
myArray x;
myArray y;
pl.someFunction(plInterface(&x), plInterface(&y));
I'm not saying that the gains outweigh the negative or the other way
round. Just that we need to think about it.
Phil
On 19 January 2016 at 12:47, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> 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
