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

[netCDF #BIE-294861]: [netcdfgroup] as_double weaknesses

Sjur,

> Since I discovered this problem, and that as_double() allocated
> memory dynamically, I have stopped using it. I now use the ordinary
> set_cur() and get() functions. Arrays must still be allocated, but
> now in my own code, and I can at least re-use the arrays when in a
> loop. I've also switched to Viet Eitner's 4.1.1 port, but still use
> the old C++ interface (which I compile into my program, not into the
> netcdf.dll).
> 
> I did use as_double() quite extensively, so it surely didn't always
> crash. Now it's some time ago, and I am no longer sure that it
> wasn't me causing a glitch. I did write, but apparently not send
> another e-mail about the problem, in which I included a function,
> see below.

Thanks for the example.  Now we may be able to diagnose and fix the
problem, assuming we can reproduce it here.

> Is the new C++ interface (exceptions, templates) far from ready?

It is documented and can be used as is, with conditions explained
below.  A link to the documentation is now available from the netCDF
Documentation page (see the link "netCDF-4 C++ interface"):

  http://www.unidata.ucar.edu/netcdf/docs/
  http://www.unidata.ucar.edu/netcdf/docs/cxx4

Please read the Introduction on the Main Page tab, which explains who
contributed the code and how it differs from the current C++ API.

You may notice that Doxygen is the documentation system.  We have
tentative long-term plans to move generation of netCDF reference
documentation to Doxygen.

The code is available and builds OK if you configure using
--enable-cxx4, including running "make check".  There are some 
examples as well.  As far as I know the API is in use at CCFE, 
but we only occasionally incorporate their updates in our 
releases.  I think we incorporated one update since 4.1.1,
but am not sure.

The limitation in the current implementation that I requested Appel
to address before we announce the availability of his contributed
software is its inability to create netCDF classic or netCDF-4
classic-model format files.  Currently it can only create netCDF-4
files.

> Does it have the same API as the old one, or do I have to rewrite
> all the code when switching? I am very much looking forward to get
> rid of all the macros.

It has a new API, which is not identical to the old one.  The new API
uses namespaces, exceptions, and templates.  I'm hoping we can rewrite
the old netCDF-3 C++ API on top of Appel's new API, as we did for the
transition from the version 2 C API by rewriting it on top of the
version 3 C API.  That would make transition fairly painless.  But
that's not a priority in our plans, and we have very limited C++
expertise here.

> And of course I have to bug you by asking how the Win-MSVC port is
> proceeding :-)

Our latest plans are to just build DLLs with cygwin, and include the
cygwin libraries in the DLLs, so that users don't have to install
cygwin to make use of the DLLs with their client code.  That plan
involves the least porting, because the current code already builds
under cygwin on Windows.

--Russ

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



Ticket Details
===================
Ticket ID: BIE-294861
Department: Support netCDF
Priority: Critical
Status: Closed