2

I am working with the HDFql C++ wrapper library and trying to integrate it with R via Rcpp. I'm an experienced coder in general, but not in C++ specifically. I made another post about trying to resolve an issue with declaration conflicts. The compiler error message is copied below:

../inst/include/HDFql/H5public.h:156:19: error: conflicting declaration ‘typedef long long int ssize_t’ typedef long long ssize_t;

(Link to the actual declaration in the header file)

Basically, both HDFql and Rcpp have typedefs for long long and they conflict. However, the HDFql wrapper defines it's own namespace on this line right here, so I don't understand why I'm getting this conflict in the first place (I thought that's what namespaces are for!). I'm hoping a C++ guru can help me with two questions:

  1. Why is this conflict happening even though the library is using a namespace? (EDIT: @Igor answered this in comment)
  2. Pretend I'm the developer of the HDFql C++ wrapper (I'm not). How would I change the wrapper library or namespace structure so that these types of conflict can't occur? (Edit: maybe write a second wrapper for HDFql as per this answer?)

I'd appreciate any insights you have!

mikeck
  • 3,534
  • 1
  • 26
  • 39
  • I am pretty sure forum/issue tracker of the named library would be much more appropriate than general C++ discussion on SO. – SergeyA Apr 13 '18 at 19:13
  • Is `ssize_t` defined inside the namespace? Are you using `using namespace namespace_name;`? – NathanOliver Apr 13 '18 at 19:14
  • 1
    Yes, `HDFql.hpp` defines a namespace. But `ssize_t` declaration is in a different header, `H5public.h`, and in the global namespace. Further, it's in `extern "C"` section, which suggests it's intended to be usable from C, and so can't possibly be in a namespace. – Igor Tandetnik Apr 13 '18 at 19:16
  • And `ssize_t` is also something which can be declared by dozen of system headers. – SergeyA Apr 13 '18 at 19:18
  • @SergeyA, I agree that for resolving this issue specifically I should seek out the library forum/issue tracker, but I am trying to understand the problem *in general*. – mikeck Apr 13 '18 at 19:28
  • @IgorTandetnik thanks, I think I understand the answer to Question 1 now. If you have any thoughts or general guidance on Question 2, I'd love to hear them. – mikeck Apr 13 '18 at 19:31
  • @NathanOliver, I'm not `using` but I think @Igor's comment explains it. `ssize_t` is defined outside of the namespace. – mikeck Apr 13 '18 at 19:32
  • @IgorTandetnik Thank you, but I need you to dumb it down for me ;) I would appreciate it if you could explain why and how defining my own version of `H5_SIZEOF_SSIZE_T` would solve the issue (wouldn't I then have 3 definitions?) and would accept+upvote such an answer. – mikeck Apr 13 '18 at 20:00
  • The whole section where `ssize_t` is defined is surrounded by `#if H5_SIZEOF_SSIZE_T==0 ... #endif`. So if `H5_SIZEOF_SSIZE_T` is defined, externally, to something other than zero, the whole section will be skipped. However, upon closer inspection, you can't just set it to any odd non-zero value - it's apparently expected to be defined to the value equal to `sizeof(ssize_t)`. I imagine some other parts of the code might rely on that. – Igor Tandetnik Apr 13 '18 at 20:22
  • According to HDFql release notes (http://www.hdfql.com/resources/RELEASE.txt), the issue (of conflicting with other C/C++ header dependencies) has been solved in version 2.0.0 – SOG Mar 28 '19 at 11:32

0 Answers0