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

Re: 19990701: C++ interface problems

>From: Gregory Orris <address@hidden>
>Subject: Re: C++ interface problems
>Organization: US Navy
>Keywords: 199907012025.OAA24859 netCDF C++

Greg,

> Thanks for the quick response...
> I agree that the small code you posted (and even the example in the 
> distribution) give the proper response.  I'm very hesitant to suggest
> that it could be the NetCDF library, but was curious if anyone else has
> found the SGI version (of practically everything) to be flaky.

I haven't heard reports of this, but the C++ interface is not as
widely used as the C and Fortran implementations, and no extensive
test set exists for the C++ interface either, so it could still
contain lots of bugs.  It's a pretty thin layer on top of the C
interface, so the bugs are usually easy to fix, once identified ...

> Since I spent 5 hours on it last night I should explain what is going on
> in a little more detail (maybe I don't fully appreciate the implementation and
> you could clear this up for me quickly)...
> 
> I'm trying to open a file via a call like 
> 
> NcFile output_data("data.nc",NcFile::Replace);
> 
> then call a function...
> 
> Write_Header(output_data); 
> 
> that defines all of the dimensions and variables and syncs them to
> disk before returning.  This it does just fine (a subsequent ncdump
> shows all is input correctly up to that point).  However, the file
> remains in define mode despite the fact that variables values have been 
> written.  After returning, subsequent writes or inquiries to that 
> class return the same result.  All say its a valid file but choke
> on any data manipulation.  Nothing short of closing the file and 
> reopening it with 
> 
> NcFile output_data_two("data.nc",NcFile::Write);
> 
> will change this.  Invoking (and I know it shouldn't be necessary
> to do this)
> 
> output_data.data_mode();  
> 
> gives the same odd error.  Even if a subsequent attempt to use the C interface
> 
> ncendef(output_data.id());  
> 
> is made the same error occurs.
> 
> Needless to say, one shouldn't have to close and re-open the file
> every time one wants to write to it.  This is one of the most puzzling 
> errors I've gotten in a while.
> 
> I guess what I'm asking is if there is something that the default destructor
> is doing behind my back upon exiting the Write_Header() function?

It's not obvious to me what is going on from the above description,
but I don't think the default destructor for output_data should be
called until it goes out of scope, so I don't understand why it would
be called upon exiting the Write_Header() function.  It's still in
scope in the calling function that declared it as an NcFile, so
presumably, the destructor isn't called until *that* function exits.

The default constructor closes the file after deleting all its NcVar's
and NcDim's , so once the destructor is called, you shouldn't expect
to be able to do much with the file or its variables or dimensions.
But again, I don't think the destructor should have been called.

> I don't expect you to de-bug the code for me, but if you need more info
> and the source to see this problem in the first persion, 
> it could certainly be sent...

If it would be possible to simplify the code enough to just
demonstrate the problem, and if we could reproduce it here, we could
determine if there's a bug in the C++ layer and fix it ...

--Russ