On Thursday 21 Nov 2013 12:50:43 Alan W. Irwin wrote: > To James and Andrew: > > I am switching this discussion to the plplot-devel mailing list for obvious > reasons. > On 2013-11-21 15:08-0000 James Tappin wrote: > > When a program using plplot is run without a device specified (or with an > > unknown device), the program produces a list of devices and prompts for a > > device. > > > > Is there any way to get that list to a program (e.g. to put them into a > > selector widget, or to find available print-like devices)? [Preferably to > > Fortran]. > > @Andrew: > Could you take a critical look at the API of this function as > well as plgFileDevs (the equivalent of plgDevs which is restricted to > returning a list of file devices). I am no API expert, but it > makes absolutely no sense to me that the first two arguments of > these functions have types of const char *** type. Surely the type > should be char ** for returning an array of character strings? > Anyhow, we use a variant of char ** for the pllegend arguments > involving arrays of character strings which is why I spotted > this issue. It appears to me the current API means that an extra & > and a special cast has to be used in the > call, see > > plgFileDevs( (const char ***) &plFramePtr->devDesc, (const char ***) > &plFramePtr->devName, &ndev ); > > in plframe.c, for example. Anyhow, if you decide to change the API of > plgFileDevs and plgDevs (with a lowercase renaming as suggested below > if you think these functions should be propagated to all our > languages), then it should be done now (to give us several weeks to > test the result) or delayed until after our next _stable_ release.
Alan, If we were just passing in an array of character strings then char ** would be fine, but in this case we need to return these arrays of strings to the user and so we need to pass in a pointer to the array of character strings. So I think the API is appropriate given the current implementation. Of course, there are other ways of achieving the same thing and you could argue about whether the current implementation is "safe" since we return pointers direct to the internal dispatch table rather than copies and so a malicious user could overwrite plplot internal information. Andrew ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
