Andrew Ross wrote: > > >>Ah yes. I should have looked more closely at this. Was there a reason >>you didn't do this for the plvect / plcont functions in the F95 >>bindings? I'm not sure I would advocate changing this now as we already >>have plvect / plcont implemented, although with different arguments to >>their C counterparts. Perhaps you could think about this? >> >>Andrew >> >> >> With respect to the matter of providing a transformation function to plcont() and plvect(): I have looked at the current API and have considered possible solutions to make the F77 and F95 versions more like the C counterparts.
The problem is not passing a function name - that is easy and has been around in Fortran for many decades. The real problem is passing arbitrary data to the function, as Fortran (up to F2003, that is) has no equivalent for C's void pointers (void *data). I can see a number of solutions, none of them very appealing: - For F77 we would be stuck with a single argument, for instance an array holding all the required data. That is awkward, if you need to combine integers and reals. It can be done though. - For F95 the type system allows you to gather all information into a derived type (equivalent in C: a struct), but then the compiler will complain that the argument has to be of the right type. You could get around it via the transfer() function, but that requires quite some understanding on the user's side. Another way would be to keep the plcont() and plvect() routines (or specially named versions of them) out of the PLplot module. Some compilers might still complain though: you would be passing derived types to routines that essentially are expected to have a F77-compatible interface. Alternatives: - For F95 define a suitable derived type that can be expected to be useful for most applications. That way we would have an interface that makes the compiler happy. - For F77 and F95, let the function itself take care of the data that it needs. In F77 you could use a COMMON block, in F95 you could use module data. I hesitate to go ahead and implement either one of these solutions, though the two alternatives give the best and most robust solutions (though not the most general). Does anyone feel strongly about extending the Fortran API in this way or shall we leave it as it is as far as these functions are concerned? Regards, Arjen ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
