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.
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.
the returned strings. I am guessing that the same semantics apply to the C++code. Also note that those strings are copies of what is in the underlying netcdf file,
so modifying those strings will have no effect on the file.
There should be no place for getVar(char**) and getVar(char*) in C++ lib
Personally, I agree. There is some historical background. The C++ wrapperyou are using is in fact the second attempt to build such a wrapper. The one you are using was provided to us (i.e. to Unidata) by an external collaborator who promised to maintain it, but in fact did not. So the problem we have is that we do not have the resources to really cleanup the C++ code, and so we must rely on users to do most of the maintenance and
improvement.Any contributions you care to make to improve the API will be appreciated :-)
=Dennis Heimbigner Unidata On 2/28/2019 2:42 PM, Panov Sergey wrote:
On Thu, 2019-02-28 at 13:13 -0700, Dennis Heimbigner wrote:I think the key is your observation:char buffer[20]; inst_var.getVar(buffer); to char * buffer; inst_var.getVar(&buffer);If the variable is actually of type string (as opposed to char), then you need to pass a buffer into which string pointers (char*) are inserted so the getVar argument needs to be char** (your second case). I assume getVar is overloaded so that in the first case it is attempting to read a string typed variable using nc_get_vara_text. In the second case, you are invoking the char** overloaded getVar, so it is properly invoking nc_get_vara_string function.I get it, but why I am getting a pointer to some string? If I do not own it, why it is not const? If I own it now, am I responsible for freeing its memory? The netcdf-cxx4 library is C++ lib. There should be no place for getVar(char**) and getVar(char*) in C++ lib . I expected there getVar(string &) and getVar(vector<string> &) calls.=Dennis Heimbigner Unidata On 2/27/2019 10:11 PM, Panov Sergey wrote:I guess it was not a segmentation fault, but a error return triggering C++ exception. I was able to get it to trigger a real segmentation fault, but changing char buffer[20]; inst_var.getVar(buffer); to char * buffer; inst_var.getVar(&buffer); gives me a pointer to a correct string. It is just bizarre!!! Does it mean I now can modify that sting and it is OK? On Thu, 2019-02-28 at 04:31 +0000, Panov Sergey wrote:I have a very basic question -- how to read "string" variable in C or C++ The ncdump tells me the variable type is "string". When I try to read it using void getVar(char* dataValues) const; function of class NcVar of netcdf-cxx4 I am hitting a segmentation fault. I am not sure why it is a segmentation fault, but it comes from ... /* No NC_CHAR conversions, you pervert! */ if (var->type_info->nc_typeid != *mem_nc_type && (var->type_info->nc_typeid == NC_CHAR || *mem_nc_type == NC_CHAR)) return NC_ECHAR; ... code in check_for_vara() function in nc4hdf.c . The var->type_info->nc_typeid is NC_STRING (12) and this check should just fail (the reading of the variable should just fail, but it "throws an exception" ... causes a segmentation fault for some reason). The stack is; check_for_vara nc4hdf.c:477 nc4_get_vara nc4hdf.c:905 nc4_get_vara_tc nc4var.c:1379 NC4_get_vara nc4var.c:1396 NC_get_vara dvarget.c:101 NC_get_var dvarget.c:117 nc_get_var_text dvarget.c:1020 netCDF::NcVar::getVar ncVar.cpp:1340 main cfradial_rd.cpp:47 __libc_start_main 0x00007ffff485a413 _start 0x00000000004021ee The C++ code is calling C function nc_get_var_text() to read this string which should have been normal. What am I doing wrong and what is the right way of reading "string" variables? PS. Does anyone else dislike the official C++ library API or it is just me?_______________________________________________NOTE: All exchanges posted to Unidata maintained email lists are recorded in the Unidata inquiry tracking system and made publicly available through the web. Users who post to any of the lists we maintain are reminded to remove any personal information that they do not want to be made public. netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ NOTE: All exchanges posted to Unidata maintained email lists are recorded in the Unidata inquiry tracking system and made publicly available through the web. Users who post to any of the lists we maintain are reminded to remove any personal information that they do not want to be made public. netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
netcdfgroup archives: