Re: 19981007: netCDF 3.4 compile warnings & C++ interface

>To: <address@hidden>
>From: "Dr Paul A Bristow" <address@hidden>
>Subject: netCDF 3.4 compile warnings & C++ interface
>Organization: .
>Keywords: 199810072008.OAA17192

Hi Paul,

> I have built the netcdf 3.4 test program OK using MSVC++ 5.0 SP3 with the
> Visual Studio IDE but have some queries.
> 
> 1  I had to do some file renaming - .hh and .cc file extensions are not
> recognised as a C style file and so the editor doesn't work right (not in
> glorious technicolor! and doesn't do other things right either).
> Microsoft decree .c, .h, .cpp only.
> 
> netcdf.hh can't be changed to netcdf.h of course, so I had to rename to
> netcdfcpp.h, and to change references within files too.
> 
> This is a nuisance caused by global failure to agree on file types.  Any
> suggestions?

When we first named these files, the ".cc" and ".hh" extensions were
fairly common, and we wanted to avoid using ".C" or ".H" because of the
use of netCDF on systems with case-insensitive file names.  We thought
using the same extension, ".h" for both C and C++ header files would be
wrong, because it would prevent an editor from knowing to highlight C++
keywords and not just C keywords, for example.

I was surprised that there doesn't seem to be any MSVC++ option that
tells it to treat files with a specified extension as C++ source or
header files, but we haven't been able to find mention of any such an
option.

As you point out, it would be desirable to rename the source files
to conform to the almost universal conventions MSVC++ has promulgated,
except for the backward compatibility problem that "netcdf.hh" can't be
renamed to "netcdf.h".  For the next release, I propose to change the
extensions on the ".cc" files to ".cpp" and change the ".hh" files to
".h", except that "netcdf.hh" will just #include <netcdfcpp.h>, where
the prototypes will be defined.  That will give us backward
compatibility as well as conformance with the MSVC++ conventions, and
we'll change the documentation to mention "netcdfcpp.h" instead of
"netcdf.hh".

> 2  I get several compile warnings, for example doing var.c
> 
> int
> NC_findvar(NC_vararray *ncap, const char *name, NC_var **varpp)
> {
>  NC_var **loc;
>  size_t slen;
>  int varid;
>  // unsigned int varid; stops warning C4018
>  assert(ncap != NULL);
>  if(ncap->nelems == 0)
>   return -1;
>  loc = (NC_var **) ncap->value;
>  slen = strlen(name);
>  for(varid = 0; varid < ncap->nelems; varid++, loc++)
>  {
>   if(strlen((*loc)->name->cp) == slen &&
>    strncmp((*loc)->name->cp, name, slen) == 0)
>   {
>    if(varpp != NULL)
>     *varpp = *loc;
>    return(varid); /* Normal return */
>   }
>  }
>  return(-1); /* not found */
> }
> 
> 
> compiler documentation says:
> 
> Compiler Warning (level 3) C4018
> 'expression' : signed/unsigned mismatch
> There was an attempt to compare a signed and unsigned number. The signed
> value was converted to an unsigned type for the comparison.
> When performing an equal (= =) or not equal (!=) comparison between signed
> and unsigned types, cast one type to the other to ensure proper comparison.
> 
> Changing "int varid" to "unsigned int" varid (or a "size_t varid" perhaps)
> makes the warning go away.
> And also should it really be a != comparison rather than a <?
> 
> typedef struct NC_dimarray {
>  size_t nalloc;  /* number allocated >= nelems */
>  /* below gets xdr'd */
>  /* NCtype type = NC_DIMENSION */
>  size_t nelems;  /* length of the array */  <<<<<<< nelems seems to be a 
> size_t here.
>  NC_dim **value;
> } NC_dimarray;
> 
> This is tiresome because it produces a fair bit of clutter in the 'output'
> window, obscuring reall error messages.

This looks like a bug, and I'm forwarding it to Glenn Davis to verify
that we should put in the necessary cast to make the warnings go away.

> 3  My project must work using Standard C++ Library - #include <iostream> not
> #include <iostream.h> etc
> Has anyone tried to do this yet?  Can you see any snags?

I don't know that anyone has done this yet.  At some point, we may
rewrite the C++ interface and fix such problems.

> Would it is useful to use templates in place of the macros too?

Yes, if we knew that all C++ compilers had finally got around to
properly implementing templates, which wasn't the case the last time we
tried this ...

> 4  Has anyone used MSVC 6 yet?

No, no one has reported using MSVC version 6 yet, and we still just have
version 5.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu