[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 970624: Restriction of variable name in ncgen?

> >To: address@hidden
> >cc: address@hidden
> >From: Tom Umeda <address@hidden>
> >Subject: Restriction of variable name in ncgen?
> >Organization: BAAQMD
> >Keywords: 199706241737.LAA02160

> Tom Umeda
> address@hidden

>
> 1.
> We have been using the netCDf library for several years.
> However, we have been using variable names with embedded
> "." 's to indicate nested grid number, e.g., THETA.2
> would be the variable name for potential temperature on
> the second nested grid.
> "ncgen" does not support "."'s within the variable names,
> but all other members of the distribution seem to handle it
> with no problem, libnetcdf.a and ncdump.
> We would like to see ncgen support "." in the variable names.
>
> Is there any reason not to extend the variable names to include "."'s?

It was necessary to form some restriction on names to avoid the
use of unprintable characters and such. I believe the syntax of names
in cdl was chose to match the intersection of syntax of identifiers
in the C programming language with identifiers in FORTRAN
so that there would be a natural, easy way to connect
identifiers in the programming language with the CDL names.

Consider the following example:

netcdf test {
        variables:
                float theta;
}

ncgen produces the following code from the above input:

   ...
   /* variable ids */
   int theta_id;
   ...
   stat = nc_def_var(ncid, "theta", NC_FLOAT, RANK_theta, 0, &theta_id);

Suppose that we allowed '.' in netcdf names, like this

netcdf test2 {
        variables:
                float theta.2;
}

If the same convention were used, this would produce
   ...
   /* variable ids */
   int theta.2_id;
   ...
   stat = nc_def_var(ncid, "theta.2", NC_FLOAT, RANK_theta.2, 0, &theta.2_id);

Which would not be valid C code.

There is a similar problem with FORTRAN.

Since programmers seem to be able to live with the constraints of
the identifiers when programming in their chosen language,
we did not feel that this was too big a contraint for CDL.
We could extend the range of possible netcdf names
to be larger and somehow map these into the language identifiers.
This would require care and probably confuse human readers of
ncgen generated code.

By the way, netcdf-3 now enforces the same constraints on identifiers
as CDL when creating new names. So, at least now we are consistant.

> 2.
> We have been migrating our netcdf application to the C++
> environment.  What is the future of the netCDF C++ interface?

The current C++ interface will continue to be supported.
We hope to provide a nicely designed java interface soon.
We hope to find time to provide an alternate, improved C++ interface
(that "lines up" directly with the java interface)
once the C++ Standard Library effort has solidified.

-glenn