Van's House

Debug vs Release - v2

Xiang Fan — Tue, 26 Mar 2013 03:37:00 GMT

Four and half a year ago (how time flies), I wrote a post about the potential issues mixing debug and release CRT in the same program.

At the end, it says, 'It's fortunate that this is a linker error. Otherwise, you'll waste lots of time in debugging to find out the subtle incompatibility'. Today, in v2, I'd like to share another example which I encountered in real-world code that demonstrates the subtle incompatibility.

Here are the two source files, which are used to generate a dll and an exe:

dll.cpp
__declspec(dllexport) void useenv();

#include <stdio.h>
#include <stdlib.h>

void useenv()
{
    wchar_t *value;
    errno_t err = _wdupenv_s(&value, nullptr, L"ENV");
    if (err == 0)
    {
        wprintf(L"ENV = %s\n", value);
        free(value);
    }
}

exe.cpp
#include <stdlib.h>

__declspec(dllimport) void useenv();

void setenv(const wchar_t *value)
{
    _wputenv_s(L"ENV", value);
}

int main()
{
    setenv(L"1");
    useenv();
    setenv(L"2");
    useenv();
}

Build the program using the following command line:

cl dll.cpp /MDd /LD /nologo
cl exe.cpp /MD /nologo /link dll.lib

What output would you expect? If everything goes as expected, it should output '1' and '2' on two lines.

However, if you try the example above, the actual output are two '1's. Unlike linker errors, this kind of runtime issues is much harder to find and the fix normally involves changes to the build system / project files which are normally non-trivial.

Now, let's take a closer look at the example.

The magic is in the compiler options. The dll is compiled with /MDd (debug CRT) and the exe is compiled with /MD (release CRT). So 'setenv' calls '_wputenv_s' from release CRT, and 'useenv' calls '_wdupenv_s' from debug CRT,

'Why does this matter?', you may ask. This is because CRT maintains many global states internally. Debug CRT and release CRT both have their own copies, changes to one don't affect the other.

In this case, CRT maintains a cache to the wide string version of the environment variables and the cache is created when you access the environment variable for the first time. The complete process can be illustrated as follows:

The first 'setenv' calls OS API to set the environment variables of the process and they are also cached in the release CRT.
The first 'useenv' tries to read the environment variables and they are not cached in the debug CRT yet. So it reads them from OS and creates the cache.
The second 'setenv' calls OS API and also updates the cached environment variables in the release CRT.
The second 'useenv' reads the environment variables directly from the cache in the debug CRT which are not changed.

So the bug only appears when you call 'useenv' the second time because the cache is created but not correctly updated (I'm not sure whether the behavior of CRT is by-design, but apparently it assumes one CRT in the binary and no direct call to SetEnvironmentString).

It is much more subtle than always fail. Actually it took me quite a while to have a small example from the original code. The first few attempts always output '(null)' instead and you can easily know that sometime goes wrong from that :-)

This is just one of thousands of possibilities how mixing debug and release CRT (or any components compiled with different options) can mess up things. The best practice is to make sure everything is compiled with the same compiler options, but this is not always possible (for example, some libraries are from third party). Then you'd better be very cautious about mixing them in the same binary. Move the incompatible part to a separate dll with an abstract layer (so that there are no assumptions across binary boundary) may help.

Connect Bugs that I Fixed

Xiang Fan — Fri, 28 Dec 2012 22:10:00 GMT

Similar to STL's post on vcblog, I generate a table of connect bugs that I have fixed after I officially worked on the compiler front end:

Connect ID	Title
581680	Lambda declaration cannot access closure variables when defined as a member function of an inline class
584664	Visual C++ compiler crashes while trying to compile some templates & inheritance code
611359	C++ compiler: Temporary object created when it should not, thus making code that worked in VC9 not work anymore!
612158	Illegal C++ fails to generate C2039 error, allowing buffer overrun
619198	[c++] Compiler fails to deduce template parameter.
622382	fatal error C1001: An internal error has occurred in the compiler
622723	Const pointer sign extension not consistent in 64-bit compiler.
623481	Compiler crash
624283	Private copy operator vs __declspec(dllexport)
624378	Can I double&& in template
624757	Incorrect function template deduction involving pointor to member data
625710	Compilation error in case of repeating forward declaration within class
633274	C++ compiler allows use of unspecialized member function template
633782	C++ #pragma secion doesn't allow read,write,execute
634671	Bug with operator overloading and nested lambdas
634688	Wrong return type when running nested lambda
634966	Argument dependent lookup chooses the wrong function inside sizeof statements
636634	Unexpected error C2751 reported at 'using namespace' directive inside a lambda expression.
637539	using namespace a::b; does not work in a lambda defined on the root level.
640228	compiler template declaration/definition mismatch error
640281	C++/CLI compiler crashes when attempting to compile event System::EventHandler<>;
640356	decltype does not seem to work ok with operator, expressions
641032	Lambda's automagic ctor gets wrong signature (or call) when implicit and explicit capture is mixed.
649496	Visual C++ doesn't respect the access modifier for operator member function templates
649953	Incorrect code generated when returning struct by value and compiling for x86.
650667	Incorrect IDE error
651255	C++ CLI property overriding and renaming
657040	Buggy static_assert
661294	Wrong "this" pointer when using templates in C++ and targeting x64 Platform
663659	Large arrays with const size can crash at run-time on win64
663884	VC10: weird template deduction error with non-type default template argument
667226	private template operators in C++ treated as public
668375	Unexpected error for legal code
669603	std algorithm functions do not compile in certain case
674241	C++ Lambda unable to access parts of types in containing method
674442	Enumeration with negative values are popping C4341 warnings
674672	Callee disassembly expects address which caller is not providing in x64 mode
675321	fatal error C1001: An internal error has occurred in the compiler.
676037	CL crashes while compiling specific line (see description)
678194	decltype strips "member" property from member function pointers
678295	C++ compiler loses member-ness of pointer-to-member-function during template deduction, causes ICE
679623	Incorrectly duplicating object when it is a native one(NDT) in vs2010sp1(C++)
679716	Bug in VC++ 2010 with global refence to array
684720	C++: Inconsistent explicit interface override behavior
684900	template template parameters don't work with unions
684807	C2216 'override' cannot be used with 'inline'
685461	C++ compiler bug in certain situation involving using declaration and overloaded base member functions
686324	cl static assertion parsing error
687345	Local class and lambda
687935	Ambiguous call to overloaded function in c++ when using lambdas
688106	Fatal Error C1001
688107	C2466 emitted twice for the same construct
688198	Invalid error error C2871 when using functions defined within nested namespaced in lambdas.
688443	C2143 emitted twice for the same construct
689504	C2326 on Lambdas with [this]-Capture
689815	std::result_of not working with lambdas
696310	C2027 emitted multiple times compiling deque with an incomplete stored class
696412	Compiling local static auto object causes internal compiler error
697086	VC++ cannot resolve function overload as template parameter
697006	C4430 emitted twice for the same construct
697512	Internal compiler error while compiling specific initializer of global object.
698459	VS Stop Working in Win7
698688	auto compiler error with multiple name declaration
704352	The function pointer types estimated by template are wrong
704624	Memory leaks with lambda expressions
706674	compile error C2663 in lambda, if boost 1.48 posix_time.hpp is included.
706537	shared_ptr and lambda function crash with C1001
715680	D8030: INTERNAL COMPILER ERROR
716372	C++ - fatal error C1001 when using static local variable with non-trivial constructor in static local lambda
718297	Access private function
718578	VS2010 C++ Template Member Functions in Lambdas Error
718729	[C++] Reference default argument falsely converted to pointer on instantiation of more than 2 explicit specializations
720670	C++ type equality not recognized under SFINAE context
724319	Failed to compile program using boost::program_options and lambda expression
724362	decltype がサイズが 0 の配列への参照を作れる / decltype can generate references of zero sized array
725056	unable to match function definition
725189	Microsoft C++ compiler crash
725876	decltype deduces wrong type
729345	Rvalue reference overloading rules
732006	auto -> decltype causes C1001 crash
736295	fatal error C1001 when using Lambda Expression
736576	Incorrect name lookup in a lambda expression defined inside a class member function
736931	The explicit capture of an entity by a nested lambda-expression does not cause its implicit capture by the containing lambda-expression.
736965	internal compiler error instead of compiler diagnostic
711056	Friend Template Classes and Lambda Functions
741267	Visual Studio 2010 C++: Static objects imported via using directives in lambdas cause compilation issues!
743303	Initializer list in a lambda crashes
746042	It does not work to instantiate a template with two different anonymous enums
746056	Error C1001 with range-based for-loop containing complex expression
746135	lambda expression problem
746680	Internal Compiler error (C1001) and sometimes crash with VS2012
747514	Inconsistent behavior when passing rvalue reference to function vs. function pointer
748530	Function pointer to templated function becomes that of non-templated function of the same name
750224	Visual Studio 2010, compiler crash
751729	range-based for and shared_ptr internal error
752136	Array<> deallocated too early
753113	VS2012 C++ Compiler Crash
753699	C++ compiler crashes instead of returning error for simple erroneous C++ code
753981	Errors C2950 and C3416 are the same and shouldn't be errors at the first place.
754807	Possible minor bug in Visual C++ 2010/2012 regarding conditional operator
759048	Compiler crash on C++ code
759235	Cannot build project
760771	fatal error C1001: An internal error has occurred in the compiler.
761026	XMMATRIX not properly aligned when using c++11 auto keyword.
761148	Internal Compiler Error using const wchar_t* in inline method
762838	Partial template specialization error with namespace & final
770391	Uniform Initialization Error with Nov 2012 CTP of Visual C++
770526	[Codename Milan] Delegating constructors not working with explicit constructors
770888	const ref to initializer_list is not recognized as valid ctor
771018	CL crashes when compiel code with initializer_list
771272	C/C++ Compiler Driver Crash
771311	Variadic template bug in vs2012 november CTP
771533	[Codename Milan] Regression making function operator public with using statement
771534	[Codename Milan] Regression - Warning 4554 erroneously emitted
772001	[Codename Milan] C++11 compilation issue (C2065)
772093	x86 C++ compiler crash
773505	std::forward and variadic templates failed in Nov 2012 CTP
774153	[Codename Milan] Missing <initializer_list> include causes compiler crash
774268	Failure to bind rvalue to a constant reference when rvalue is returned from virtual function
774456	[Codename Milan] ambiguous begin()/end() of initilizer_list
774527	After upgraded from VS2008, build project in VS2012 shows error: c1xx : fatal error C1083: Cannot open source file: '??????????????????????????????': No such file or directory
775016	[Codename Milan] std::forward ignore namespaces in variadic template functions

These are only a small portion of bugs we have fixed (less than 20% of mine), and there are still large amount of active bugs on which we are working.

If you find any bugs in the compiler, feel free to report them through Microsoft Connect.

November CTP of Visual C++ compiler, more C++11 features

Xiang Fan — Sat, 03 Nov 2012 23:34:00 GMT

Our team announced Novemeber CTP of Visual C++ compiler.

It contains the following C++11 features besides those already in VS2012:

Variadic templates
Uniform initialization and initializer_lists
Delegating constructors
Raw string literals
Explicit conversion operators
Default template arguments for function templates

System.Uri doesn’t allow trailing dot

Xiang Fan — Tue, 07 Feb 2012 06:19:58 GMT

Again, System.Uri tries to be smart and does something on my behalf :-(

This time, the victim is trailing dot (which is common in wiki pages). See this connect bug for details.

The workaround is similar to the one described in this post. The only difference is that we need 'GenericUriParserOptions.DontCompressPath' instead.

C++: Under the Hood

Xiang Fan — Tue, 07 Feb 2012 03:32:26 GMT

This is an article written by Jan Gray. It is quite old, but most of the contents still apply today.

The original article on MSDN can no longer be found. Here is the pdf version on OpenRCE: http://www.openrce.org/articles/files/jangrayhood.pdf.

Overview:

How are classes laid out?
How are data members accessed?
How are member functions called?
What is an adjuster thunk?
What are the costs:
    Of single, multiple, and virtual inheritance?
    Of virtual functions and virtual function calls?
    Of casts to bases, to virtual bases?
    Of exception handling?

C++98 -> C++11: Pass by value or pass by reference?

Xiang Fan — Sat, 04 Feb 2012 03:29:00 GMT

In GoingNative 2012, there are some discussions on the new coding style for C++11. One interesting thing which is mentioned by Bjarne Stroustrup, Stephan T. Lavavej and Herb Sutter is the most efficient way to pass the argument.

In C++98, pass by reference is in general more efficient because it saves extra copies (if the copy is expensive, otherwise the extra indirection may hurt the perf instead). However, after the introduction of move semantics in C++11, the story is now a little different (Note that premature optimization doesn’t buy you anything, so the following is to give you a full picture of the new thought introduced in C++11, see the guidelines at the end and use it when appropriate)

Let’s see the following example:

#include <iostream>
#include <vector>

using namespace std;

struct String {
    String(const wchar_t *) {
        cout << "ctor" << endl;
    }
    String(const String &) {
        cout << "copy ctor" << endl;
    }
    String(String &&) {
        cout << "move ctor" << endl;
    }
};

void f1(String s) {
    vector<String> v;
    v.push_back(std::move(s));
}
void f2(const String &s) {
    vector<String> v;
    v.push_back(s);
}

void g() {
    String s(L"");
    cout << "f1(s)" << endl;
    f1(s);
    cout << "f1(L"")" << endl;
    f1(L"");
    cout << "f2(s)" << endl;
    f2(s);
    cout << "f2(L"")" << endl;
    f2(L"");
}

If you run the code, you will find that 'f1' has one less copy ctor call for rvalue argument and the same amount of copy ctor call for lvalue argument than 'f2', which means 'f1' is more efficient (assume that move ctor is much cheaper than copy ctor).

The trick is as follows: for lvalue argument, 'f1' has one extra copy to pass the argument because it is by-value, while 'f2' has one extra copy to call push_back. So no difference; for rvalue argument, the compiler has to create a temporary 'String(L“”)' and pass the temporary to 'f1' or 'f2' anyway. Because 'f1' can take advantage of move ctor when the argument is a temporary (which is an rvalue), the costs to pass the argument are the same now for 'f1' and 'f2'.

This means in C++11 we can get better performance by using pass-by-value approach when:

The parameter type supports move semantics.
The cost of move constructor is much cheaper than the copy constructor (both the time and stack usage).
Inside the function, the parameter type will be passed to another function or operation which supports both copy and move.
It is common to pass a temporary as the argument.

One example for the above guidelines (no copies here!):

// Assume that Matrix has a cheap move ctor
Matrix operator-(Matrix m)
{
// Manipulate m
return m;
}

Matrix m = -(a + b);

Note, I learn today (April 2nd, 2013) that 'return m;' is in general more efficient than 'return std::move(m);'. Both will use move constructor of Matrix, but the latter inhibits NRVO (which means the compiler can't eliminate the call to the move constructor).

They are the same in the above example because 'operator-' returns function parameter. If you return a local variable instead of a function parameter, you can save one call to the move constructor.

The criteria for copy / move constructor elision is in C++11 standard draft n3485.pdf, 12.8 / 31:

in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value

The complex two-stage overload resolution to choose move constructor when you return an lvalue object is in 12.8 / 32:

When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If overload resolution fails, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object’s type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue. [ Note: This two-stage overload resolution must be performed regardless of whether copy elision will occur. It determines the constructor to be called if elision is not performed, and the selected constructor must be accessible even if the call is elided. —end note ]

System.Uri doesn’t allow embedded escaped slashes

Xiang Fan — Sun, 15 Jan 2012 19:05:27 GMT

I use C# a lot to write small utilities and sometimes find that it is annoying to have to dig into the source code to figure out why .Net framework doesn’t work as I expected. This happens again when I am using LinkedIn API (BTW, this is the first occurence of such experience).

LinkedIn API allows you to get the details of user’s connection using url like the following:

http://api.linkedin.com/v1/people/url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Flbeebe/connections

However, if you create a url like the above in C# and send the request to LinkedIn, the server will reject the request and complain about the wrong signature.

I hit this kind of issue several times before (due to slightly different escaping rules between the requirement of oAuth 1.0 3.6 / 2 (RFC3986) and Uri.EscapeUriString in .Net 2.0 (RFC2396)). But this time, the root cause is different.

After spending lots of time debugging by myself and searching the web later, I reached the following post: http://connect.microsoft.com/VisualStudio/feedback/details/94109/

So it is clear that .Net framework explicitly alters the input url for ‘security’ reason. But it doesn’t expose the interface to allow the user to change this behavior (even if it is simply a parser flag called ‘GenericUriParserOptions.DontUnescapePathDotsAndSlashes’ which can be set internally).

Well, I’m on my own to hack it. The workaround posted in the bug changes the parser flag for all Uri objects with the same url scheme, so I have to write a more isolated version:

      public static class HackedUri
    {
        private const GenericUriParserOptions c_Options =
            GenericUriParserOptions.Default |
            GenericUriParserOptions.DontUnescapePathDotsAndSlashes |
            GenericUriParserOptions.Idn |
            GenericUriParserOptions.IriParsing;
        private static readonly GenericUriParser s_SyntaxHttp = new GenericUriParser(c_Options);
        private static readonly GenericUriParser s_SyntaxHttps = new GenericUriParser(c_Options);

        static HackedUri()
        {
            // Initialize the scheme
            FieldInfo fieldInfoSchemeName = typeof(UriParser).GetField("m_Scheme", BindingFlags.Instance | BindingFlags.NonPublic);
            if (fieldInfoSchemeName == null)
            {
                throw new MissingFieldException("'m_Scheme' field not found");
            }
            fieldInfoSchemeName.SetValue(s_SyntaxHttp, "http");
            fieldInfoSchemeName.SetValue(s_SyntaxHttps, "https");

            FieldInfo fieldInfoPort = typeof(UriParser).GetField("m_Port", BindingFlags.Instance | BindingFlags.NonPublic);
            if (fieldInfoPort == null)
            {
                throw new MissingFieldException("'m_Port' field not found");
            }
            fieldInfoPort.SetValue(s_SyntaxHttp, 80);
            fieldInfoPort.SetValue(s_SyntaxHttps, 443);
        }

        public static Uri Create(string url)
        {
            Uri result = new Uri(url);

            if (url.IndexOf("%2F", StringComparison.OrdinalIgnoreCase) != -1)
            {
                UriParser parser = null;
                switch (result.Scheme.ToLowerInvariant())
                {
                    case "http":
                        parser = s_SyntaxHttp;
                        break;
                    case "https":
                        parser = s_SyntaxHttps;
                        break;
                }

                if (parser != null)
                {
                    // Associate the parser
                    FieldInfo fieldInfo = typeof(Uri).GetField("m_Syntax", BindingFlags.Instance | BindingFlags.NonPublic);
                    if (fieldInfo == null)
                    {
                        throw new MissingFieldException("'m_Syntax' field not found");
                    }
                    fieldInfo.SetValue(result, parser);
                }
            }

            return result;
        }
    }

However, I feel guilty for hacking.

Speed up iostream

Xiang Fan — Thu, 12 Jan 2012 17:15:00 GMT

Throughput of iostream is considered much slower compared with its C counterpart.

For example:

printf("1234567\n");
cout << "1234567" << endl;

If you iterate 10⁵ times, printf takes about 50ms while cout takes >1s. This looks quite annoying.

After digging into the source of iostream (not an easy task :-) ), I finally figure out that the bottleneck is the implicit flush inside ‘endl’.

‘endl’ does more than outputting a single ‘\n’. The standard (C++03 27.6.2.7 / 5) says:

Effects: Calls os.put(os.widen(’\n’) ), then os.flush().

After eliminating the unnecessary flush, cout is even faster than printf in some cases!

Here is the number (the time below is measured by redirecting the output to ‘nul’):

printf	“1234567\n”	“%d\n”, i
VC10	56ms	64ms
g++ 4.5.3	24ms	70ms

cout	“1234567\n”	i << “\n”
VC10	36ms	178ms
g++ 4.5.3	46ms	90ms

cout	“1234567” << endl	i << endl
VC10	1260ms	1420ms
g++ 4.5.3	520ms	550ms

Note that the standard requires the library not to use full-buffer for stdout / cout (if the destination is a file, then it is on), so you have to do it by yourself. Otherwise the performance will be very poor (10x slower). GCC turns on full-buffer even though this is non-conformant :-).

C99 7.19.3 / 7: As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.

#ifdef _MSC_VER
vector<char> v(1024);
cout.rdbuf()->pubsetbuf(&v[0], v.size());
#endif

Protected or Private II

Xiang Fan — Sat, 07 Jan 2012 23:05:00 GMT

Someone reminds me that it has been nearly 2 years since my last blog post. How time flies!

Many things happened during this period. I moved to Redmond and I’m now officially working on C++ compiler. The work is busy and also challenging.

Recently, there was a thread in our internal discussion list which mentioned a way to bypass the access check in C++.

I had a blog post which discusses how to access ‘protected’ member. However, the approach is non-conformant and doesn’t work for ‘private’. The internal discussion points me to a post which shows a conformant way to bypass the access check! The approach is creative and it makes me think how to improve it to be extensible and easier to use.

The main idea is based on the following statement in the C++ standard (C++03, 14.7.2 / 8):

The usual access checking rules do not apply to names used to specify explicit instantiations. [ Note: In particular, the template arguments and names used in the function declarator (including parameter types, return types and exception specifications) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible. —end note ]

The tricky part is, even if you can use the private member in the template argument of explicit instantiation, you can’t declare an object of such a type because access check happens during the declaration. That means you can’t get back the member from the instantiated type directly. So we have to take advantage of global variable instead. But unlike the original post, there is no need to use base classes. The following code shows the idea:

// AccessControlHack.h
template<typename T, typename F, F pf, F* ppf>
class C {
    static int init() {
        *ppf = pf;
        return 0;
    }
    static int i;
};
template<typename T, typename F, F pf, F* ppf>
int C<T, F, pf, ppf>::i = init();

// S.h
#include <stdio.h>
struct S {
public:
    S() {i1 = 4;}
private:
    void f1() {printf("Hello World 1\n");}
    static void f2() {printf("Hello World 2\n");}
    int i1;
    static int i2;
};
int S::i2 = 15;

// SHack.h (include S.h)
struct SHack {
public:
    SHack(S *p) : m_p(p) {}

    void f1();
    static void f2();
    int get_i1();
    static int get_i2();
private:
    template<typename T>
    static void VerifyPointer(T p);

    S *m_p;
};

// SHack.cpp (include AccessControlHack.h)
namespace {
    void (S::*gpf1)();
    void (*gpf2)();
    int S::*gpi1;
    int *gpi2;
}
template class C<S, void (S::*)(), &S::f1, &gpf1>;
#ifndef _MSC_VER
template class C<S, void (*)(), &S::f2, &gpf2>; // bug of VC
#endif
template class C<S, int S::*, &S::i1, &gpi1>;
template class C<S, int *, &S::i2, &gpi2>;

template<typename T>
void SHack::VerifyPointer(T p)
{
    if (!p) {
        throw "The pointer has not been initialized. Using hack class before main could lead to undefined behavior.";
    }
}
void SHack::f1()
{
    VerifyPointer(gpf1);
    (m_p->*gpf1)();
}
void SHack::f2()
{
    VerifyPointer(gpf2);
    (*gpf2)();
}
int SHack::get_i1()
{
    VerifyPointer(gpi1);
    return m_p->*gpi1;
}
int SHack::get_i2()
{
    VerifyPointer(gpi1);
    return *gpi2;
}

// Main.cpp (include SHack.h)
int main()
{
    S s;
    SHack sh(&s);
    sh.f1();
#ifndef _MSC_VER
    SHack::f2();
#endif
    printf("%d\n", sh.get_i1());
    printf("%d\n", SHack::get_i2());
}

The above code compiles and runs correctly using VC10 and GCC 4.5.3. Is this a defect in the standard? I have no idea :-)

Some comments,

I find a bug in VC which incorrectly does access check on non-static member functions during explicit instantiation.
Because the member pointer is initialized in the dynamic initializer for ‘C::i’, the approach has the dependency on initialization order of global variables which is not guaranteed across translation units. That is why I add a check in ‘VerifyPointer’.

C++0x features in VC2010 - nullptr

Xiang Fan — Mon, 10 May 2010 07:21:00 GMT

Summary Page

(n3090.pdf is the current working draft of C++0x standard, it is available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3090.pdf)

What we have before C++0x

Everyone knows that null pointer value is NULL. In C++, NULL is defined as follows:

#define NULL 0

One interesting thing about '0', it can be converted to any pointer types. However, this is not true for 0’s underlying type 'int'.

This leads to big problem when template is involved. For example (It is simplified from std::make_shared):

template <typename T>

struct CtorWrapperUnary

{

template<typename U> T *operator()(U u)

{

return new T(u);

}

};

struct A {

A(int *) {}

};

void bar()

{

CtorWrapperUnary<A> f;

f(0); // error C2664: 'A::A(int *)' : cannot convert parameter 1 from 'int' to 'int *'

}

The functor "CtorWrapperUnary" wraps the constructor of A. However, the functor can’t accept argument '0' while A’s constructor can. The root cause is that the special property of '0' is lost when it is converted to a variable 'u' of type 'int'.

What we have now in C++0x

To solve the above problem, we have to have a type which can be converted to any pointer types.

In C++0x, this type is std::nullptr_t, and nullptr is a keyword which has value of this type.

With nullptr, we can rewrite the code as:

void bar()

{

CtorWrapperUnary<A> f;

f(nullptr);

}

One difference between '0' and 'nullptr' is we can’t use the former as the non-type argument of pointer type (see n3090.pdf 14.4.2/5).

template<int *>

struct A {};

void foo()

{

A<0> b1; // No conversion from 0 to ‘int *’

A<(int *)0> b2; // OK

A<nullptr> b3; // OK

}

BTW, VC is not conformant here. It also allows the definition of b1.

Known issues / limitations

After the introduction of nullptr, it is reasonable to change the definition of NULL (The standard says this is implementation defined):

#define NULL nullptr

However, many code bases incorrectly assume NULL to be an integer or '0'. For example:

void f()

{

char str[] = "a";

int n = NULL;

str[0] = NULL;

}

So the change will break lots of existing code L.

Known bugs in VC2010

1. nullptr is allowed as non-type argument for function template

template<int> void f();

void g()

{

f<nullptr>();

}

2. nullptr is allowed as template template argument

template<template <class> class> class C {};

C<nullptr> c;

3. Some arithmetic operations on nullptr do not generate an error

https://connect.microsoft.com/VisualStudio/feedback/details/505780

void test()

{

auto x = nullptr;

x++; // should give error

x += 1; // should give error

}

We have special handling for nullptr when processing expressions. But apparently some cases are missing.