nvcc + gcc -> error

[mwiesenberger]

Hi, thank you for this great library.

However, I have an issue when I try to use nvcc to compile an application:
I am on your 0.10.6 branch.
I have a file that includes the amalagated json.h header, which is compiled by nvcc-7.5 with gcc-4.9 as the backend compiler. I then get the following error message

~/include/json/json.h:571:16: error: ‘class Json::Value::CZString’ is private
   class CZString {
                ^
~/include/json/json.h:1099:49: error: within this context
   explicit ValueConstIterator(const Value::ObjectValues::iterator& current);
                                                 ^
~/include/json/json.h:571:16: error: ‘class Json::Value::CZString’ is private
   class CZString {
                ^
~/include/json/json.h:1150:44: error: within this context
   explicit ValueIterator(const Value::ObjectValues::iterator& current);

I don't really know what to make of it. In any application that includes json.h and I compile with gcc-4.9 I don't get any errors. If I compile with nvcc with icc-14.0.2 as the backend I get the same message but as a warning instead of an error

~/include/json/json.h(1099): warning #525: class "Json::Value::CZString" (declared at line 571) is an inaccessible type (allowed for cfront compatibility)
  private: explicit ValueConstIterator(const std::_Rb_tree_iterator< std::pair< const Value::CZString, Value> >  & current); 
                                                                                             ^
~/include/json/json.h(1150): warning #525: class "Json::Value::CZString" (declared at line 571) is an inaccessible type (allowed for cfront compatibility)
  private: explicit ValueIterator(const std::_Rb_tree_iterator< std::pair< const Value::CZString, Value> >  & current); 
                                                                                        ^

Again json.h doesn't cause trouble in any project I compile solely with icc-14.0.2.
Any ideas? I'm a bit at a loss if it's an nvcc problem or a problem with the code. I'd appreciate your help.

best
Matthias

[cdunn2001]

I suppose we could make that non-private?

Have you tried with the regular (non-amalgamated) headers?

[mwiesenberger]

Yes sure, I didn't realize it was private...

Yes, I also tried to use the non-amalgamated headers, then the error/warning is in line 221/749 and 221/800
in the file value.h

[mwiesenberger]

ahh now I get it:

changing line 221 to public makes the error go away

[mwiesenberger]

line 219 I mean of course. You might be interested that it then compiles flawlessly with nvcc-7.5 + gcc-4.9 as well as with nvcc-7.5 + icc-14.0.2 as well as with gcc-4.9 and icc-14.0.2 alone.

I'll keep it as a workaround, don't know if you can live with making it non-private? Or do you have other solutions you want me to try?

[cdunn2001]

Can you #ifdef to make it public only for that compiler? If so, submit that as PR and we'll merge it.

[mwiesenberger]

Did it. The issue can be closed I guess?

[dbeurle]

I'm encountering the same issue:

/usr/include/json/value.h:790:92: error: 'CZString' is a private member of 'Json::Value'
private: explicit ValueConstIterator(const std::_Rb_tree_iterator< std::pair< const Value::CZString, Value> >  & current); 
                                                                                           ^
/usr/include/json/value.h:222:16: note: declared private here
private: class CZString { 
               ^
/usr/include/json/value.h:841:87: error: 'CZString' is a private member of 'Json::Value'
private: explicit ValueIterator(const std::_Rb_tree_iterator< std::pair< const Value::CZString, Value> >  & current); 
                                                                                      ^
/usr/include/json/value.h:222:16: note: declared private here
private: class CZString { 
               ^

json/version.h:

# define JSONCPP_VERSION_STRING "1.8.3"
# define JSONCPP_VERSION_MAJOR 1
# define JSONCPP_VERSION_MINOR 8
# define JSONCPP_VERSION_PATCH 3
# define JSONCPP_VERSION_QUALIFIER
# define JSONCPP_VERSION_HEXA ((JSONCPP_VERSION_MAJOR << 24) | (JSONCPP_VERSION_MINOR << 16) | (JSONCPP_VERSION_PATCH << 8))

This happens when using gcc 6.4 and clang 4.0.1 as the host compiler.

$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Nov__3_21:07:56_CDT_2017
Cuda compilation tools, release 9.1, V9.1.85

This commit (3eda8a6) isn't present in value.h.

[cdunn2001]

This commit (3eda8a6) isn't present in value.h.

I don't know what you mean, but I can say that's a very old commit.

*   3cde9a9 (up/0.y.z) Merge pull request #604 from AbigailBuccaneer
|\
| * 347e1ae Use unique_ptr instead of auto_ptr when possible
| * 1335f70 Use std::unique_ptr instead of std::scoped_ptr
|/
*   3eda8a6 Merge pull request #491 from mwiesenberger/0.y.z

Try updating to master, or any 1.y.z release. If you have a problem on the old 0.y.z branch, you'll have to submit a PR to fix it.

[dbeurle]

Thanks for the quick reply.

I am using 1.8.3, see my json/version.h dump I posted above.

This bug is still present even though I'm using the 1.8.3 version, however that patch from 0.y.z doesn't exist in json/value.h on the master branch or in the Fedora provided (1.8.3) version. Is there any particular reason as to why?

I can definitely open up a PR based on what was previously done.

[cdunn2001]

I'm not sure what's going on here. But if the PR passes TravisCI, I think we can merge it.

[dbeurle]

Thank you. Happy holidays.

[mwiesenberger]

Just upgraded our project to the c++11 standard (I know, I know, we're slow) and stumbled on the same issue on the 1.8.4 tag. I guess my old fix did not make it into the master branch :( but with the PR from @dbeurle on master everything is fine again :)

[dbeurle]

We had this problem a few years ago where I worked. Should this be a bug opened with the nvcc compiler @mwiesenberger?

[mwiesenberger]

I think it can't hurt to open a bug report. Can you construct a minimal example to reconstruct the bug?

[dbeurle]

I can but I'm away from any computer with a CUDA toolchain for testing until Monday night. Are you a NVIDIA registered developer?

[mwiesenberger]

No unfortunately not, if you can do it easily I think the problem can wait til Monday :)