Tim,
> For SMURF we are starting to use NDG (I'm building up a C interface that
> I will commit tomorrow). This starts us on the road to using GRP as well
> (from C) so I have a couple of questions and comments on GRP C interface:
>
> * I'd really like to use a typedef for the GRP identifier in the C API
> to make it distinct from a normal integer. Would you mind if I changed
> the API to use a "grpid" (typedeffed to an int)? I'll be happy to patch
> CUPID at the same time. In my opinion general Fortran integers that
> actually correspond conceptually to objects should have typedefs.
I see a number of points to consider here:
1) What actual benefit does using a typedef provide? One thing it doesn't
provide is any sort of type safety, since the compiler happily accepts
things like:
typedef int FRED;
void aa( FRED );
main(){
int i;
i = 1;
aa( i );
}
(that is, the compiler doesn't moan about "i" being declared as "int"
rather than "FRED")
2) What about all the other libraries eg NDF, ARY, TRN, etc, ?
3) What about other alternatives such as
typedef struct Grp {
int igrp;
} Grp;
This would provide type security.
> * The SCUBA-2 Data Access library requires that we obtain the file name
> from the Group created by NDG. Is the fact that the group contains
> a filename part of the public interface that can be relied upon?
Yes.
> Is there a constant that we can use from GRP to presize our array
> that receives the name from grpGet?
Not sure what you mean. Individual strings stored in a GRP group are not
allowed to be longer than GRP__SZNAM characters. Is this what you mean?
> * The grpDelet interface does not seem to be as expected. Shouldn't
> it take a pointer to a grpid (int) rather than the value? Isn't it
> meant to be reset to the group variable to GRP__NOID?
Yes - that's an oversight. I've corrected it.
> * The NDG documentation seems to include some functions that have a "1"
> in the name, are they meant to be part of the public API or did they
> slip through? [eg ndg_asso1].
They are part of the public interface.
> * I note that there are some KPG1 wrappers for NDG. Should I be using
> them in preference to ndgAssoc and ndgCreat?
As with all kpg stuff, they were created specifically for the needs of one
or more particular kappa applications, but were deemed to be potentally of
more general use. Use them if they do what you want, otherwise use NDG
directly.
> * For LOGICAL types should we always assume that these are intgers
> with 0 and 1 or should we use a boolean type (defined somewhere)
> similar (or equal) to bool_t?
I'm not really in favour of introducing a boolean type. The standard C way
of doing things is to use int values as boolean.
> Finally, if I have an NDF identifier, is it possible to determine the
> associated filename (or HDS path) without going deep into the
> NDF internals?
Not directly so far as I am aware. There is an indirect means which uses
NDF_MSG to set up an MSG token holding the file name, and then use
MSG_LOAD to get the value of the token. For instance, see KPG_NDFNM.
David
|