The semantics of the underlying nc_get_var_string is that the caller
must free
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++ wrapper
you 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/
