Panov... if there's an effort on a rewrite, I'd like to be involved. There
are a number of things I'd like to see in such a rewrite. For starters, to
have it work more like the Python API. C++ has collections (hash maps,
etc), so we should use them. And (like the Python API), we should give the
dimensions when defining things as strings, not as dimension IDs. And we
should never, of course, return pointers that need to be deallocated (that
should be done inside destructors). And so on...
-- Elizabeth
On Thu, Feb 28, 2019 at 5:32 PM Ward Fisher <wfisher@xxxxxxxx> wrote:
> 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/
>
> _______________________________________________
> 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/
