Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2016-01-19 03:47:10
|
@Phil (and other C++ enthusiasts here): There is a question for you at the end about redacted dimension arguments for the C++ case. @Everybody: Normally for higher-level languages that treat arrays as first-class objects (i.e., _all_ the computer languages we support other than C, Tcl, and [strangely] C++, see below) that carry their dimension information along with them, we use a redacted PLplot API, where arguments containing a redundant dimension are removed from argument lists. So, for example, plline(n, x, y) gets called as plline(x,y), from Python, Fortran, etc. But for this and like cases what should be the rule for calculating the dimension argument (e.g., n in the plline arguments) for the corresponding C call and what sanity checks should be made concerning n? For our swig-generated bindings (e.g., Python, Jave, Octave, and Lua) n is calculated from the actual length of the first related array argument (e.g., the x argument for plline) and the sanity check is the length of the other related arrays (e.g., the y argument of plline) are checked whether they have the same length, and if not, an error occurs. And this model has propagated further to other high-level languages (e.g., at least to D) and perhaps all of them since the swig-generated bindings were implemented first. For our new Fortran binding the current status is the dimension information is usually taken from the first array and no further checking done of the dimensions of the other associated arrays, and I was starting the process of converting that bad model (lots of chance for user error there) to the above model. However, then I started to consider the extra burden this "sanity check" would impose on our Fortran users, 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 also think this change should be done for all our languages that redact dimension arguments from argument lists. If there is general agreement that would be a good goal to have, I am willing to take a further look at this in the long term or happily encourage from the sidelines if someone else wants to make these language bindings changes in the shorter term. I also realized when researching this post, that our C++ binding has no redaction of the n argument for plline (or presumably any other part of our C++ API). I assume this is because our C++ binding currently just uses C-style arrays, but although I have only minimal knowledge of C++ my quick google search found an article that stated "C++ provides an alternative array type as a standard container" which have more powerful capabilities (like carrying array information with the object than C-style arrays. @ Phil (and other C++ enthusiasts here): Could you comment on why we are not using this possibility which should allow redacted argument lists for our C++ binding and much less chance of user error due to array issues? If you are enthusiastic about choosing to use the more powerful array type in our C++ binding arguments, I would encourage you to go ahead and make that change. To ease the transition to the new kind of arrays in argument lists you would probably want to keep the non-redacted form available in overloaded form around for a while but only if a user specifically chooses it with a CMake option such as -DPL_DEPRECATED_cxx=ON (as a gentle reminder to users to move to the more powerful array API before it is too late and we remove the deprecated version that uses C-style arrays). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
|
From: Arjen M. <Arj...@de...> - 2016-01-19 07:50:17
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > 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. |
|
From: Alan W. I. <ir...@be...> - 2016-01-19 10:54:43
|
On 2016-01-19 07:50-0000 Arjen Markus wrote: > Hi Alan, > > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> 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 Hi Arjen: Thanks for this additional discussion of the 2D case. I agree with your conclusion. > - provided it can be done for other bindings in the same way. I believe each language should be moved to less constrained rules for dimensions of arrays independently of the rest of the languages. I also think such a project would be pretty straightforward for any language binding written in C or C++ (e.g., all our swig-generated bindings). I don't know a lot about some of our other language binding methods, but hopefully some method can be found to move to the less constrained rules when someone takes a look. > 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. That would be great. And if we could get the C++ enthusiasts on side as well, that would mean all our bindings would be redacted. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-19 12:32:52
|
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 <Arj...@de...> wrote:
> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Alan W. I. <ir...@be...> - 2016-01-19 20:14:15
|
On 2016-01-19 12:32-0000 Phil Rosenberg 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. Hi Phil: You make good points above, and I have to admit I have never heard user complaints about demanding exactly consistent array sizes for our many language bindings that enforce that constraint. So I am now leaning toward just continuing that model with Fortran although this may come as a shock to our Fortran users. (I think our old binding did not have any dimension constraints at all.) However, I can address that in the release notes where we are already listing all the ways the new Fortran binding differs from the old one. Anyone else want to weigh in here before I finalize this decision for our Fortran binding? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-19 12:48:04
|
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...@gm...> 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 <Arj...@de...> wrote:
>> Hi Alan,
>>
>>
>>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> 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
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
|
|
From: Phil R. <p.d...@gm...> - 2016-01-19 13:07:20
|
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...@gm...> 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...@gm...> 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 <Arj...@de...> wrote:
>>> Hi Alan,
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alan W. Irwin [mailto:ir...@be...]
>>>> 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
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
|
|
From: Alan W. I. <ir...@be...> - 2016-01-19 20:39:01
|
On 2016-01-19 13:07-0000 Phil Rosenberg wrote: > 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. My own feeling is the advantages of full-featured arrays outweigh the simplicity (but also dangers) of C-style arrays. So assuming you go ahead and implement full-featured arrays as arguments for the routines in our C++ binding, my tentative advice would be to wean C++ users of our code off of C-style array arguments by deprecating them. But I leave that judgement call to support or deprecate C-style arrays up to you and the others here who are familiar with C++. [...] > I'm not saying that the gains outweigh the negative or the other way > round. Just that we need to think about it. You have obviously already made an excellent start on the required thinking which is really good. However, I hope Andrew (who has been the principal maintainer of our C++ binding for many years) also gets involved in this discussion. @Andrew: any thoughts? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
|
From: Jerry <lan...@qw...> - 2016-01-20 08:47:53
|
On Jan 19, 2016, at 5:32 AM, Phil Rosenberg <p.d...@gm...> 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 agree with Phil. Jerry |
|
From: James T. <jt...@gm...> - 2016-01-20 09:16:34
|
On 20 January 2016 at 08:47, Jerry <lan...@qw...> wrote: > > On Jan 19, 2016, at 5:32 AM, Phil Rosenberg <p.d...@gm...> > 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 agree with Phil. > > Jerry > A suggestion -- not sure if it is practical or not -- how about a flag to permit unequal lengths? |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X