Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

json.hpp:5746:32: error: 'to_string' is not a member of 'std' #136

Closed
Ingener74 opened this issue Oct 11, 2015 · 78 comments
Closed

json.hpp:5746:32: error: 'to_string' is not a member of 'std' #136

Ingener74 opened this issue Oct 11, 2015 · 78 comments
Labels
platform: android related to Android NDK

Comments

@Ingener74
Copy link

Hello.
On Android i have this messages

  • json.hpp:5746:32: error: 'to_string' is not a member of 'std'
  • json.hpp:6911:36: error: 'strtold' is not a member of 'std'

android ndk have no to_strign realization

@gregmarr
Copy link
Contributor

The first one works fine for us, we use the c++-shared library.

We had to add this function to our codebase to handle the second one.
inline long double strtold(const char _nptr, char *_endptr)
{
return strtod(nptr, endptr);
}

@nlohmann
Copy link
Owner

Hey @Ingener74, could you please tell me which compiler you are using?

@Ingener74
Copy link
Author

Hello @nlohmann, i am using arm-linux-androideabi-4.9 toolchain for compiling

@nlohmann
Copy link
Owner

Could this maybe solve your problem: http://stackoverflow.com/a/27589053 ?

@Ingener74
Copy link
Author

Thanks @nlohmann, i known this solution :) but that about strtold?
I wanted to ask whether it will be added to your library? for android

@nlohmann
Copy link
Owner

Ok, I'll have a look at strtold. It would be easier to check on OSX - is there an OSX version of the compiler you use?

@Ingener74
Copy link
Author

On Mac OS X i use compiler

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

but on mac os everythink compiles ok

@nlohmann
Copy link
Owner

I meant the compiler to create code for Android. Is there a way to cross-compile from OSX?

@gregmarr
Copy link
Contributor

You need the android NDK.

@gregmarr
Copy link
Contributor

Yes, it is available for OS X.

@Ingener74
Copy link
Author

Hello @nlohmann i agree with @gregmarr, you need Android NDK for compiling
https://developer.android.com/ndk/downloads/index.html

@ZahlGraf
Copy link

Hi,

for a current project I compiled this library with Android NDK r10e, (it includes gcc 4.9) together with gnustl-shared library.
The errors mentioned by @Ingener74 are still in the json-lib, thus I created a small patch-file for that.

On android, it adds the function std::to_string (common workaround implementation, found on stackoverflow) and std::strtold (workaround implementation suggested by @gregmarr).

Hopefully this patch is usefull for anyone who want to use this library on Android. Maybe linking from the main-README to those compatibility patches would be a good idea.

Best regards,
ZG

From 092170941c6a69cbc3a113b098940b4c03b448c2 Mon Sep 17 00:00:00 2001
From: Andre Netzeband <[email protected]>
Date: Sat, 28 Nov 2015 13:08:39 +0100
Subject: [PATCH] Added better android support.

Added Android NDK support.
---
 src/json.hpp | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/src/json.hpp b/src/json.hpp
index 1e3cd11..e878295 100644
--- a/src/json.hpp
+++ b/src/json.hpp
@@ -70,6 +70,25 @@ Class @ref nlohmann::basic_json is a good entry point for the documentation.
     using ssize_t = SSIZE_T;
 #endif

+#ifdef __ANDROID__
+   // Workaround for Android NDK builds (version r10e) that does not support std::to_string and std::strold so far
+   namespace std
+   {
+       template <typename T>
+       std::string to_string(T Value)
+       {
+           std::ostringstream TempStream;
+           TempStream << Value;
+           return TempStream.str();
+       }
+       
+       inline long double strtold(const char * str, char ** str_end)
+       {
+           return strtod(str, str_end);
+       }       
+   }
+#endif
+
 /*!
 @brief namespace for Niels Lohmann
 @see https://github.com/nlohmann
-- 
2.5.0.windows.1

BTW: Unit-Tests are running fine on Android Emulator with these changes.

0001-Added-better-android-support.patch.txt

@nlohmann
Copy link
Owner

Thanks! I'm on holiday right now and shall have a look then!

@nlohmann
Copy link
Owner

nlohmann commented Dec 6, 2015

Thanks @ZahlGraf! I added your patch to the code. @Ingener74, can you please check if this fixes your original issue?

@ZahlGraf
Copy link

ZahlGraf commented Dec 6, 2015

Thanks :) In the meanwhile I'm using your lib very successfully on an Android project.

@Ratstail91
Copy link

Hi, I just wanted to add that this bug goes a lot deeper than Android; I was getting this issue with a fresh install of MinGW on Windows 10. After chasing proposed changes across the net, I fixed it by manually patching some headers using this:

http://tehsausage.com/mingw-to-string

After these changes, it still wasn't working, but it wasn't because of _GLIBCXX_HAVE_BROKEN_VSWPRINTF, but rather _GLIBCXX_USE_C99, which needed to be defined in os_defines.h. Finally, because I was using stricmp(), I had to switch to using -std=gnu++11 as a compiler option.

I hope this helps someone, because that workaround is terrible ;)

@nlohmann
Copy link
Owner

@Ratstail91, what do you propose?

@gregmarr
Copy link
Contributor

I didn't notice that you'd added the std::to_string overload. I haven't updated our project to use this version yet, but I suspect that this is going to cause problems for us, as the C++ library that we use for Android (c++_shared, from LLVM) already contains that function. Also, it is not allowed for user code to add things to the std namespace except in very specific circumstances. I think that adding std::to_string should be done by the application, not the library, as the reason it's missing is the application's choice of which NDK standard library to use, not an inherent platform limitation. This is analogous to not supporting g++ 4.8.

@nlohmann
Copy link
Owner

Hi @gregmarr, I understand. If you experience problems with the current version, please let me know.

@Ratstail91
Copy link

@nlohmann I'd recommend not adding std::to_string, partially because of what @gregmarr said. Instead, I'd determine what implementations of C++ that this tool is compatible with, and give some advice for those who are having trouble with it, possibly in a help or README file. I'd be happy to write that up myself, since I've dealt with it.

Worst case scenario, you could write a custom function to_string_ex(), implementing the necessary functionality yourself, but this is not recommended.

@whackashoe
Copy link
Contributor

nlohmann::to_string is alternative that makes it easy for those with fucked up standard lib implementations and is obvious that it acts similar to std::to_string.

@nlohmann nlohmann reopened this Dec 15, 2015
@Ratstail91
Copy link

@whackashoe Adding it to namespace nlohmann is an option, but I still don't like it...

nlohmann added a commit that referenced this issue Dec 15, 2015
@nlohmann
Copy link
Owner

I removed the hack for MinGW/Android and added a small section to the README file. Thanks everybody for the discussion!

@fh127
Copy link

fh127 commented Jan 8, 2016

Hi, I am using the implementation c functions to support in Android ndk, the next function:

    son.hpp:6911:36: error: 'strtold' is not a member of 'std'

The method use in JNI Android

     inline long double strtold(const char * str, char ** str_end)
   {
       return strtod(str, str_end);
  }   

Launch the next error when I compile:

      error: 'strtod' is not a member of 'std'
      return std::strtod(str, str_end);

@nlohmann
Copy link
Owner

nlohmann commented Jan 8, 2016

Hi @fh127, did you have a look at the notes regarding Android in the README file?

zewt added a commit to zewt/json that referenced this issue Feb 28, 2016
The MingW link doesn't help for Android, and points people down the
wrong path.  On Android all you need to do is tell the build system
to use a newer compiler and standard library.

The unit tests run successfully with this configuration on Android.

Related to nlohmann#136.
@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

Then again, what about http://stackoverflow.com/questions/12975341/to-string-is-not-a-member-of-std-says-g-mingw/12975602#12975602?

This issue has been fixed in MinGW-w64 distros higher than GCC 4.8.0 provided by the MinGW-w64 project. Despite the name, the project provides toolchains for 32-bit along with 64-bit. The Nuwen MinGW distro also solves this issue.

@JamesBremner
Copy link

I have several clients who are accustomed to a long list of build instructions including "Download and install the code:blocks IDE" Although they are unaware of it, this simple step not only gives them the IDE, but also a mingw distro with a g++ compiler. Asking my clients to muck around with integrating different distros with the current codeblocks release, all so that I can use a sexy new json parser in some code that they never look at - well, it just isn't going to sell.

I guess the point is that it is much easier to do a global search and replace, then insert a small chunk of new code into your json.hpp file.

The code::blocks installation works out-of-the-box and everything I do depends on it - so, please, stop suggesting that I hack at it.

I would prefer to point my clients to your website and tell them to download an 'official' version of your code If necessary I can fork your repo, install the fix and point my clients there. I just thought you would welcome the opportunity to gain a new class of users and I could avoid maintaining a copy of your code.

@JamesBremner
Copy link

Bad news: the fix does not work in real code.

If more that one file includes json.hpp, then I get multiple definition linker errors.

The problem is that the implementation of the replacement functions cannot be placed in the header, but must be in a single cpp file.

This rather wrecks the beatiful simplicity of integrating your package.

@TurpentineDistillery
Copy link

One extreme is to support one specific version of one specific compiler on one specific platform. Another absurd extreme is to support all versions of all compilers out there and all of their warts. Clearly, the line must be drawn somewhere. I think most would agree that "ISO c++11" is a simpler and cleaner differentiation than "ISO c++11 or that one version of code::blocks"

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

The code::blocks installation works out-of-the-box and everything I do depends on it - so, please, stop suggesting that I hack at it.

I will.

But I also will not add those parts that MinGW failed to implement into my library. As much as it hurts to hear that people may not be able to use the library: please understand that it may not make sense for me to support an objectively broken C++11 system.

@JamesBremner
Copy link

Please note:

C:\Program Files (x86)\CodeBlocks16\MinGW\bin>g++ --version
g++ (tdm-1) 4.9.2

The README says

Currently, the following compilers are known to work:

GCC 4.9 - 6.0 (and possibly later)

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

Yes. And there is the note on the MinGW bug right below.

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

I think we won't find a solution here:

  • I will not adjust the library to implement the subset of the STL that is missing in MinGW. This just would not make sense.
  • You will not change the compiler or "hack" the shipped STL. I can understand this.

Unless there is another solution, unfortunately this library is not a candidate for a vanilla code:blocks installation.

@JamesBremner
Copy link

But the note is not helpful. The fixes mentioned do not work - I have tried them.

Anyway, I am on the point of giving up on this. 5 hours and counting.

There does not seem to be any obvious way to serialize ( convert a json object to a test string )

My old parser was happy with

  json::Object j;
  ...populate...
  string text =  json::Serialize( j );

but this throws an exception

nlohmann::json j
... populate ...
string text = j.get<string>();

Surely a one line to convert a json object into the equivalent human readable form is a basic requirement for a parser? I must be missing something.

@gregmarr
Copy link
Contributor

gregmarr commented Mar 6, 2017

It's j.dump();

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

@JamesBremner
Copy link

@gregmarr Thanks! Works perfectly

I must say the prompt support is impressive!

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

But the note is not helpful. The fixes mentioned do not work - I have tried them.

The comments on StackOverflow sounded promising. I am not aware of a different solution.

@JamesBremner
Copy link

@nlohmann I think we won't find a solution here:

OK. The elegance of the parser and the prompt support makes me wish to continue.

I will fork your repo, install the fix ( the one that works! ) and point my clients there.

@tksatware
Copy link

tksatware commented Mar 6, 2017

I am using the library with code::blocks 13.12, which uses the gcc installed in the system. gcc is here
gcc version 4.9.2 (Raspbian 4.9.2-10)
It works out of the box, but you need to enable C++11 in the compiler options.

Just go to Settings->Compiler and tick the option
[ ] Have g++ follow the C++11 ISO C++ language Standard [-std=c++11]

The library will work perfectly then. "out of the box"!

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

@JamesBremner Can you comment on @tksatware 's observation?

@JamesBremner
Copy link

JamesBremner commented Mar 6, 2017

I am using the code::blocks v16.1 with C++11 enabled @tksatware must be doing something more, since he using a much older version of codeblocks

@tksatware
Copy link

tksatware commented Mar 6, 2017

@JamesBremner what does
gcc -v
show?

@JamesBremner
Copy link

C:\Program Files (x86)\CodeBlocks16\MinGW\bin>g++ --version
g++ (tdm-1) 4.9.2

@JamesBremner
Copy link

gcc version 4.9.2 (Raspbian 4.9.2-10)

This looks very linuxy. I am runninning mingw under windows.

@tksatware
Copy link

tksatware commented Mar 6, 2017

@JamesBremner I will install it Code::Blocks tomorrow under Windows and have a look. On Windows, I am using VS2015 Update 3, which also works fine. The mingw road was always too hacky for me.
But actually, this is gcc 4.9.2 in disguise and should work.

@JamesBremner
Copy link

Here is the v2.1.1 release fixed up to compile under windows code::blocks v16.1

https://github.com/JamesBremner/nlohmann-json-parser-for-mingw

@nlohmann
Copy link
Owner

nlohmann commented Mar 6, 2017

Nice work. Please note that the library is called "JSON for Modern C++" and is more than just a parser, so I would suggest you change the README from "This is a copy of the modern C++ JSON parser" to "This is a copy of JSON for Modern C++".

@JamesBremner
Copy link

@nlohmann Done!

@gregmarr
Copy link
Contributor

gregmarr commented Mar 6, 2017

If more that one file includes json.hpp, then I get multiple definition linker errors.
The problem is that the implementation of the replacement functions cannot be placed in the header, but must be in a single cpp file.

Sounds like you were missing an inline.

@JamesBremner
Copy link

@gregmarr Good idea. I have re-implemented the missing functions in the header file using inline and so the cpp source file is no longer needed. At the cost of a little bloat, the neat header only design is restored.

I have to note that the inline was also missing form the fix that you posted back in May.

@JamesBremner
Copy link

I have replaced my old JSON parser with yours in my first project - a simple open source scheduler. The application source code replacement was very straightforward ( once the compile problems were sorted ).

I do like the automatic handling of json objects versus json arrays. So far, everything is simply just a nlohmann::json

FYI, here is the commit

JamesBremner/schedule@46a5002

@gregmarr
Copy link
Contributor

gregmarr commented Mar 6, 2017

@JamesBremner Cool. FYI, I wrote a template function, which is automatically inline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: android related to Android NDK
Projects
None yet
Development

No branches or pull requests