Hello Sergey,
A rewrite in part or in whole would be gratefully accepted; we are a bit
resource constrained, with the C library and the Fortran interface taking the
bulk of our efforts. Rewriting/cleaning up the C++ interface is on our (very
long) list of things to do, but given the relatively low usage (compared to
C/Fortran) makes it hard to prioritize it at times. So, any and all
contributions would be very gratefully considered!
-Ward
On Feb 28, 2019, 3:28 PM -0700, Panov Sergey <sergey.panov@xxxxxxxxxxx>, wrote:
> 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/
> _______________________________________________
> 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/
