Proposed resolution:

Add to the synopsis in [basic.string]

basic_string( nullptr_t ) = delete;

[ 2009-07 Frankfurt ]

We considered three options:

• The proposed resolution.
• NAD
• Interpret a null pointer as the empty string.

The consensus was NAD.

[ Batavia (2009-05): ]

We are unable to achieve consensus on an approach to a resolution. There is some sentiment for treating this as a QOI matter. It is also possible that when string is brought into the concepts world, this issue might be addressed in that context.

[ Post Summit: Alisdair requests this be re-opened as several new language facilities are designed to solve exactly this kind of problem. ]

[ Redmond: No great enthusiasm for doing this. If we do, however, we want to do it for all places that take charT* pointers, not just the single-argument constructor. The other question is whether we want to catch this at compile time (in which case we catch the error of a literal 0, but not an expression whose value is a null pointer), at run time, or both. Recommend NAD. Relegate this functionality to debugging implementations. ]

Today, my colleagues and me wasted a lot of time. After some time, I found the problem. It could be reduced to the following short example:

  #include <string>
  int main() { std::string( 0 ); }

The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and Comeau online) compile the above without errors or warnings! The programs (at least for the GCC) resulted in a SEGV.

I know that the standard explicitly states that the ctor of string requires a char* which is not zero. STLs could easily detect the above case with a private ctor for basic_string which takes a single 'int' argument. This would catch the above code at compile time and would not ambiguate any other legal ctors.