error C2039: '_snprintf': is not a member of 'std' - Windows

[phunkyfish]

I used the latest release (single include file), compiled using VS2017 - Visual Studio 2017 Developer Command Prompt v15.9.1.

As a work around I removed std:: from all the snprintf calls.

I was building an addon for kodi: kodi-pvr/pvr.vuplus#156

Full gist of build output: https://gist.github.com/phunkyfish/c8456619bd85c16b1f9243e83517ac46

Note that it builds for all other platforms without issue.

[nlohmann]

This is strange, because the MSVC builds run without problems on AppVeyor, see https://ci.appveyor.com/project/nlohmann/json.

[phunkyfish]

Microsoft (R) Program Maintenance Utility Version 14.16.27023.1
Copyright (C) Microsoft Corporation.  All rights reserved.

d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(3930): error C2039: '_snprintf': is not a member of 'std'
d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(20292): note: see declaration of 'std'
d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(3921): note: while compiling class template member function 'std::string nlohmann::detail::lexer<nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>>::get_token_string(void) const'
d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(5020): note: see reference to function template instantiation 'std::string nlohmann::detail::lexer<nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>>::get_token_string(void) const' being compiled
d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(4967): note: see reference to class template instantiation 'nlohmann::detail::lexer<nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>>' being compiled
d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(13447): note: see reference to class template instantiation 'nlohmann::detail::parser<nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>>' being compiled
d:\jenkins\workspace\binary-addons\kodi-windows-x86_64-master\tools\depends\target\binary-addons\pvr.vuplus\src\enigma2\utilities/json.hpp(20307): note: see reference to class template instantiation 'nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>' being compiled
NMAKE : fatal error U1077: 'C:\PROGRA~2\MIB055~1\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
Archiving artifacts
‘cmake/addons/build/zips/pvr.vuplus+windows-x86_64/pvr.vuplus-*.zip’ doesn’t match anything: ‘cmake’ exists but not ‘cmake/addons/build/zips/pvr.vuplus+windows-x86_64/pvr.vuplus-*.zip’
No artifacts found that match the file pattern "cmake/addons/build/zips/pvr.vuplus+windows-x86_64/pvr.vuplus-*.zip". Configuration error?```

[phunkyfish]

Might it be the version: Utility Version 14.16.27023.1

[nlohmann]

It seems that Microsoft somewhere uses a macro and forwards snprintf to _snprintf and then the resulting code std::_snprintf makes no sense. I'll check what I can do.

[phunkyfish]

Json CPP had similar problem.

open-source-parsers/jsoncpp#224

Maybe you just need to add:

#if defined(_MSC_VER) && _MSC_VER < 1500 // VC++ 8.0 and below
#define snprintf _snprintf

To support version earlier than 15

[nlohmann]

Sigh... Yet another instance where I need to "patch" C++11 code such that it can compile with the most recent Microsoft compiler...

[phunkyfish]

Unfortunately that’s not uncommon.

[gregmarr]

Are you sure this definition is from VC++ itself and not some other library that you're including?

[phunkyfish]

I’m not sure at all. While developing I build the addon on Mac which doesn’t have the issue. The windows build happens on the automated build system for the addon.

[1996sc30]

Are you sure this definition is from VC++ itself and not some other library that you're including?

I also had this problem, but the query found that other libraries defined it. I am also very upset now.

[phunkyfish]

This is tricky, my guess is the occurrences of this will rise with adoption and it will be difficult to define to users what the correct workaround is.

[nlohmann]

@1996sc30 You are saying that the define came from another library, but not this one? Meaning the error has nothing to do with this library?

[1996sc30]

@1996sc30 You are saying that the define came from another library, but not this one? Meaning the error has nothing to do with this library?

Yes！Indeed so.

[nlohmann]

@phunkyfish Can you confirm @1996sc30 's observation?

[phunkyfish]

Let me find who to ask and I will bring them in on this thread.

Should the code be compatible with utility version 14.16.27023.1?

@1996sc30 can you confirm what compiler and utility version you are using? Also which was the offending library that caused this problem?

[nlohmann]

@phunkyfish I do not understand the question.

[1996sc30]

Let me find who to ask and I will bring them in on this thread.

Should the code be compatible with utility version 14.16.27023.1?

@1996sc30 can you confirm what compiler and utility version you are using? Also which was the offending library that caused this problem?

I am using VS2015 and using nlohmann/json as the latest version, the conflict is the other library(evpp—https://github.com/Qihoo360/evpp) I used in the project .

[nlohmann]

So it seems we can close this issue?

[phunkyfish]

Yes, thanks!

[goodguysoft]

I experienced this issue with Visual Studio 2015. My application used Python as embedded scripting language, and pyerror.h redefines snprintf to _snprintf if configuration property HAVE_SNPRINTF is not defined. When I added HAVE_SNPRINTF definition to my project, json.hpp started to compile. So, it looks like Microsoft itself doesn't redefine snprintf, however, software that supports compatibility with older Visual Studio versions may create such definition, especially if it is configured in incorrect way.

So, when you have such issue, first of all you have to review other open source dependencies that you have in your project.

[phunkyfish]

Yes, the solution in my case was to undef in my app to allow the standard declaration to work.

[cqc-alec]

I'm not sure why this is closed as out of scope. Any program that includes nlohmann/json.hpp may run into this error, because that file references std::snprintf. Would it not be better to #undef snprintf there, rather than in potentially every file that includes it? Or could that cause other issues?

[nlohmann]

Would it not be better to #undef snprintf there, rather than in potentially every file that includes it? Or could that cause other issues?

I don't think so. This would be as surprising for users of the library as other libraries introducing such macros in the first place. std::snprintf is C++11 standards-compliant, and whoever has issues compiling that, should take care of fixing the issue.

[cqc-alec]

std::snprintf is C++11 standards-compliant, and whoever has issues compiling that, should take care of fixing the issue.

Fair point. :-)

[kedakedaxia]

you can add “#undef snprintf” At the head of the file json.hpp

[nlohmann]

No, it’s not the library‘s job to clean up such names.

[gregmarr]

Agreed that users of C++ libraries that #define snprintf should bear the burden of cleaning up after the non-compliant library, and hopefully getting the library authors to fix it themselves. They can create a simple wrapper header that includes the offending header and then does the #undef snprintf.

[planetchili]

Sigh... Yet another instance where I need to "patch" C++11 code such that it can compile with the most recent Microsoft compiler...

This works fine on MSVC. In my case the offender was the Autodesk FBX SDK.

[jweinst1]

Is there any chance in the future of just using snprintf from <stdio.h> and not <cstdio> to avoid this issue for projects that compile both windows and linux releases? and also use other third party packages.