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

[Ingener74]

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]

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]

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

[Ingener74]

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

[nlohmann]

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

[Ingener74]

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]

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]

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]

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

[gregmarr]

You need the android NDK.

[gregmarr]

Yes, it is available for OS X.

[Ingener74]

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

[ZahlGraf]

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 <andre@netzeband.eu>
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]

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

[nlohmann]

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

[ZahlGraf]

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

[Ratstail91]

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]

@Ratstail91, what do you propose?

[gregmarr]

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]

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

[Ratstail91]

@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]

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.

[Ratstail91]

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

[nlohmann]

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

[fh127]

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]

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

[nlohmann]

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]

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]

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]

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]

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]

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]

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

[nlohmann]

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]

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]

It's j.dump();

[nlohmann]

https://github.com/nlohmann/json#serialization--deserialization

[JamesBremner]

@gregmarr Thanks! Works perfectly

I must say the prompt support is impressive!

[nlohmann]

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]

@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]

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]

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

[JamesBremner]

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]

@JamesBremner what does
gcc -v
show?

[JamesBremner]

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

[JamesBremner]

gcc version 4.9.2 (Raspbian 4.9.2-10)

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

[tksatware]

@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]

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]

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]

@nlohmann Done!

[gregmarr]

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]

@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]

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]

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