NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Ionutz, >Date: Tue, 30 Mar 1999 14:35:29 +0900 >From: Ionutz Borcoman <address@hidden> >Organization: . >To: Steve Emmerson <address@hidden> >Subject: Re: 19990329: c++ interface bug? NcFile::get_var() >Keywords: 199903251256.FAA21940 In the above message, you wrote: > gcc is obsolete on Debian 2.2. Even my kernel 2.2.3 and my glibc2.1 are > compiled with egcs. The gcc was completly replaced and I have no > intention to put it back. :-) > > About the problem with NULL pointers: yes, I think here is the problem. > We have a similar problem with our VDK library. The problem might not lie with a null pointer. I thought that your netCDF file didn't contain the variable "P"; thus, I misinterpreted where your program crashed. If, instead, your netCDF file contains a "P" variable but not an "xxx" variable, then your program might be crashing in the "printf" statement of the following: var = nc->get_var("xxx"); if(!var) printf("not existent variable\n"); I suggest that you determine where, exactly, your program is crashing. A debugger that understands both C and C++ might help. > It seems more not a compiler problem, but that netCDF C++ interface is > not ANSI C++ compliant. NcFile::get_var() is compliant. It's equivalent to the following when the named variable doesn't exist: NcVar* NcFile::get_var( NcToken name ) const { return 0; } So the issue isn't conversion between pointer types, but rather conversion of zero to a null pointer of type NcVar* -- which is always allowed. > I already have this copyright, but I'm not very good at interpreting > these documents :-) Who is? :-) -------- Steve Emmerson <http://www.unidata.ucar.edu>