This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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