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

Re: 20010130: C++ Interface

>To: address@hidden
>From: Paul Hamer <address@hidden>
>Subject: C++ Interface
>Organization: UCAR/Unidata
>Keywords: 200101310014.f0V0EJX29757

Hi Paul,

> Why, when you have const method NcFile::get_fill()
> do you call ncsetfill within it? Doesn't this imply
> that you're changing the object? Further, one would
> expect a client of the NcFile class to want to find
> out what the current fillmode is not set it when they
> call get_fill().
> 
> Have I completely misunderstood this option?

First, I'm sorry it's taken so long to answer your question.  We were
involved in a meeting last week that consumed a lot of time.

The implementation of get_fill() in the C++ interface was constrained
by two things:

 - For maintenance purposes, the C++ interface is implemented as a
   thin layer over the C interface rather than a fat layer that keeps
   its own copy of the same state that is kept in the C layer.  This
   also permits C++ and C interface calls to occur from the same
   program and remain consistent, as might happen if a C++ program
   makes calls to a library that calls the C interface.

 - The C interface has no nc_get_fill() call that gets the "fill state"
   set by the last nc_set_fill() call.  Instead, it was designed
   (perhaps wrongly) to overload the nc_set_fill() call to be used in
   both setting and returning the previous "fill state".

So to avoid violation of encapsulation in the C interface, only the
ncsetfill() (or nc_set_fill()) function is available for use in
accessing the current fill mode.  The NcFile::get_fill() function has
to set the state then restore it to the value of the returned previous
state in order to access it.  So the function is logically const, but
does make a transient change to the state of the file before restoring
it.

Looking at the implementation of nc_set_fill() makes it apparent that
even this transient change can be expensive, however, because changing
from NcFile::NoFill mode to NcFile::Fill mode would result in a call
to nc_sync() in the underlying C library.

From the documentation at

  
http://www.unidata.ucar.edu/packages/netcdf/guidec/guidec-10.html#HEADING10-400

the fill state of an open netCDF dataset is a transient property of
that open instance, not a property of the file.  So if we could
guarantee that a file opened in the C++ interface would never have its
fill mode changed from the C interface, we could just save the fill
mode as part of the C++ state of the open instance and return from
NcFile::get_fill().  Unfortunately, I don't think we can guarantee
that ...

--Russ