Did I get it right that Unidata/UCAR would welcome a fork or even a
total clean re-write of the NetCDF C++ API library?
-Sergey
On Thu, 2019-02-28 at 15:07 -0700, Dennis Heimbigner wrote:
> 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/
