Re: more about the c++ interface

Hi Tomas,

> I have just written an application which makes use of the c++
> interface to NetCDF and writes measurements to portable files
> which can be moved between computers.
> NetCDF works fine and I am pleased with the performance and the
> c++ interface. I think I have found an error the "values()" and
> the "as_*()" functions of NcTypedComponet part of the c++ interface
> (which I therefore avoided in my application).
> 
> The problem I see with these functions is that the c++-info says
> about the values() function of NcTypedComponet that it:
> "Returns a pointer to the block of all values for the variable or
>  attribute.  This will be deleted when the variable or attribute is
>  destroyed."
> It appears to me that this is not correct. Each call to values
> used get_space() to allocate new space for the values and return
> a pointer to the newly allocated space (filled with the values
> of the variable). Repeated calls to values() return different
> pointers and the NcTypedComponet variable does not keep track
> of the space it has allocated. This space will therefore not
> be deleted when the NcTypedComponet is deleted.

Thanks for pointing out this problem.  No one else had noticed the
inconsistency in the documentation, so maybe no one else is using this
member function.  I'll work on fixing this before the general netCDF 2.4
release, but I don't think I'll hold up the 2.4 beta release for this.  I've
mentioned the problem in the release-notes, which I've just made available
at

   http://www.unidata.ucar.edu/packages/netcdf/release-notes.html

If there are no more unanticipated problems, I should be announcing the beta
release later today.

> Furthermore, it seems to me that each call to the as_char(int n),
> as_short(int n), etc. functions makes an independent call to values()
> through the "return values()->Nc_as(TYPE)(n);" expression.
> The pointer returned by "values" in this case (different pointer
> and new space for each call?) disappears and can never be deleted
> by the application. Finally, why do these functions use an "int"
> in their arguments rather than "long" which is used for indexing
> everywhere else in NetCDF?

Again, you're the first to have pointed out this problem, which I've fixed
in the 2.4 beta release.  I think I originally used "int" rather than "long"
because attribute lengths are "int" in the C interface (and will remain so),
but using "long" is correct and seems to work fine for attributes as well.

> I think each NcTypedComponet should have a pointer which is initially
> zero and potentially points to all the values of this variable
> if the user has called values() or any of the as_*() functions.
> The pointer should only be assigned new values the first time
> these functions are called and there should be an explicit
> function which the user can call to release the values if
> he so chooses after he/she has used them (i.e. a release_values()
> function) which sets the pointer to zero after deleting the values
> vector. This pointer should be deleted when the variable itself is
> deleted if it is non-zero at that point in time.
> In this way the description in the info file will be correct.

Good suggestions.  I'll look at implementing this soon.

> Finally I want to say that I appreciate the effort that you
> at UCAR have put into NetCDF and the continuing work to improve
> the library and make it more useful for the general public.
> I have found it very useful and I am especially impressed with
> the amount of work you have put into the documentation and
> description of the library which is the part of development
> work of this kind that is ofter neglected.

Thanks for your kind words.  Unfortunately I haven't had enough time to
bring the documentation for the 2.4 beta release up to what it should be,
but that's one of the main things I'll be working on for the general
release.

--Russ