Suggestions about nullptr behavior in C++/CLI code
as By Design
10/27/2009 8:56:45 PM
The way you implements nullptr in cli is inconsistent with strings. For example, the following functions:
(The following discussion is based on cli environment, not native)
void UnmanagedFunction(const wchar_t *s);
void ManagedFunction(String ^s);
If we call them like this:
We both know what will happen: The L"123456" will be translated to an unmanaged wchar, and L"654321" will be translated to managed string literal. That is, the compiler didn't assume the string as either managed or unmanaged, it translate them according to the context (in this case, the function which is used)
And if we write something like this:
void ConfuseFunction(const wchar_t *s);
void ConfuseFunction(String ^s);
Then call it:
At first I assume the compiler will be confused and throw me an error, however, it's not, L"999999" will be translated to managed string literal. The only way to call the const wchar_t* one is:
But for nullptr, things become different:
Unmanaged one will failed to compile under cli. And for the confuse one:
Also will failed.
The solution it use __nullptr, !BUT!, this is a Microsoft only extension, there is no guarantee that everyone will use it. If I use someone else's open source code, like boost (I'm sure boost will handle the nullptr problem very well, but, just for example, whatever...), if they use nullptr, those "perfectly working unmanaged code" will failed to compile under cli environment, and we must change all of them to __nullptr manually. That's is something we don't what to do.
My suggestion is simple: Let the compiler translate nullptr according to the context, default to managed if confused, like what you did with strings.
(Sorry for my poor English if that's causing any trouble to you ^_^)
PS. Didn't have much time to dig into beta2. If I'm wrong, I'll be happy to know.