C2664 (C++/CLR) cannot convert 'nullptr' to 'nullptr &&' #987
Comments
|
Can you compile and run the unit tests (https://github.com/nlohmann/json#execute-unit-tests)? |
|
I'll give that a try. I should note that compiling json.hpp in a native C++ project in the same Visual Studio is successful. |
|
First of all, i forgot to disable using precompiled headers. With the provided TestLibrary.zip you was not able compiling to reproduce the error. Here is the corrected one: The error output of that project: Here is the result of the unit test: |
|
new information: editing line 1808 from to check, if compiler is a C++/CLI compiler the predefined macro my workaround so far is to add following lines somewhere at the beginning of json.hpp: and change the mentioned line to: for further information: |
|
Thanks for the feedback! I wonder whether it is sufficient to make the change only at that position. |
|
I think it should, because the keyword The plain C++ code on Windows is working with my workaround, on my Embedded Linux environment with GCC/G++ also. Now I'm implementing the C# wrapper, then I'll see if that is working as well. |
Uh, doesn't that mean that C++/CLI is not following C++ standards then? It should be using the C++ names for everything, else how would they expect to be able to compile C++ code? Better yet, why didn't they put their weird .NET |
|
I think exactly the same. Here is Microsoft's statement: |
|
Also, why try to change Some wrapper cpp: #define nullptr __nullptr
#include "../path/out/of/source/json.cpp"
#undef nullptrAnd similar for headers too. This requires no changes to whatever number of libraries one may wish to use in the broken C++/CLR. I'm surprised the compiler itself doesn't have a method to do that itself to regain some sense of standards? |
|
That should work. I will try that out tomorrow at work. But yes, Microsoft's compiler should be smart enough to fit the keyword |
nlohmann
added
the
solution: proposed fix
You'd think that alone would show that the compiler could test both versions and use whichever is appropriate. ;-) But eh, extend, embrace, then break compat, that's their way... |
|
If the snippet from #987 (comment) fixes the the problem, I would close this issue. |
Unfortunately, this is true. |
|
Also do note, if a library has many cpp files that you want to fixup like that, you can actually import them all into a single file just fine (and in fact this usually speeds up compilation compared to multiple files too). :-) |
|
Well, C++/CLI is technically a different language, and it had https://blogs.msdn.microsoft.com/hsutter/2003/11/23/ccli-keywords-under-the-hood/ nullptr: This has been proposed in WG21/J16 for C++0x, and at the |
|
Herb Sutter is a ISO C++ committee member for many many years. Furthermore as Microsoft's software architect he should have recognized, that introducing the keyword |
|
This was his post. He expected C++/CLI to follow C++0x. Not sure what happened there. |
|
I don't know either. The idea to have both side in a class (i call that a Janus class) is fascinating. But knowing that C++/CLI does not fulfill the C++ standard bothers me. |
Hmm, so when are they going to get around to that? |
|
I think that will never happen, because you should not break broken compatibilities. |
I would say that is the credo of Microsoft, except the past few major versions of Windows they've majorly broken some backwards compat... ^.^; |
|
Ok, i tested @OvermindDL1 proposal macroizing the keyword
To make that work, you have to allow macroizing keywords by setting (Sorry Microsoft, that is a hack to teach to your compiler that Finally, that "hack" works indeed, but is really a PITA. |
I'm working on a C++ to C# wrapper using C++/CLR and MS VS Community 2015 (Version 14.0.25431.01 Update 3).
Compiling the single header json.hpp fails with described error in the title. The json.hpp version in 3.1.1.
I uploaded a tiny test project to reproduce the compile error:
TestLibrary.zip
For me a possible workaround is to encapsulate the json object and return the dump()ed string to pass to the C++/CLR and pass that string to the C# world instead of passing the dump()ed string from my C++/CLR class to the C# environment.
Thanks in advance.
The text was updated successfully, but these errors were encountered: