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

Re: 20010205: C++ Interface (cont.) (fwd)

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.

  • Subject: Re: 20010205: C++ Interface (cont.) (fwd)
  • Date: Mon, 05 Feb 2001 15:58:57 -0700
------- Forwarded Message

Date:    Mon, 05 Feb 2001 13:27:57 -0700
From:    Russ Rew <address@hidden>
To:      Paul Hamer <address@hidden>
cc:      address@hidden
Subject: Re: 20010205: C++ Interface (cont.) 

>To: address@hidden
>From: Paul Hamer <address@hidden>
>Subject: Re: 20010130: C++ Interface
>Organization: NOAA/FSL
>Keywords: 200101310014.f0V0EJX29757 netCDF C++

Paul,

> ... Yes the fill mode is just a transient property
> of that instance so therefore get_fill() needs only to return
> the value held for this instance. i.e. The constructor could 
> initialise a private copy of the mode to NC_FILL, after all you
> don't provide any way to change this on construction and this
> is the default as specified in the documentation. The method
> get_fill() merely returns this value. set_fill() would call
> the underlying C function (ncsetfill() or nc_set_fill()) and
> reset the objects private copy of this mode. Hence get_fill() is
> truly const and reflects the current state of the object.
> 
> A relatively minor change class private memebers, the constructor
> and methods get_fill()/set_fill() would seem to solve this 
> problem.

When I said "transient property of that instance", I was referring to
the file descriptor of an open file in the C layer, corresponding to
the file handle returned from nc_open().  I had in mind a scenario in
which the C layer would independently change the fill mode of a netCDF
file opened in the C++ layer by independently opening the same file,
but now I think this could only happen by using an invalid file
handle, from a previously closed file, for example.

So you're right, and I'll make the appended change for the next (and
hopefully final) netCDF 3.5 release.

Thanks for reporting the problem and persisting against my resistance!

--Russ

cvs diff: Diffing .
Index: netcdf.cpp
===================================================================
RCS file: /upc/share/CVS/netcdf-3/cxx/netcdf.cpp,v
retrieving revision 1.3
diff -r1.3 netcdf.cpp
209c209,213
<     return ncsetfill(the_id, a_mode) != ncBad;
---
>   if (ncsetfill(the_id, a_mode) != ncBad) {
>     the_fill_mode = a_mode;
>     return TRUE;
>   }
>   return FALSE;
214,221c218
<     int mode = ncsetfill(the_id, Fill);
<     if (mode == NC_FILL)
<       return NcFile::Fill;
<     if (mode == NC_NOFILL) {
<       ncsetfill(the_id, NoFill); // reset it
<       return NcFile::NoFill;
<     }
<     return NcFile::Bad;
---
>     return the_fill_mode;
305a303
>     the_fill_mode = Fill;
Index: netcdfcpp.h
===================================================================
RCS file: /upc/share/CVS/netcdf-3/cxx/netcdfcpp.h,v
retrieving revision 1.4
diff -r1.4 netcdfcpp.h
113a114
>     FillMode the_fill_mode;


------- End of Forwarded Message