Re: [RFC] std::string(0);

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Fri, Jun 11, 2004 at 02:50:36PM +0200, Daniel Frey wrote:

> I would like to suggest a small improvement to basic_string. As the 
> subject already says, it's about std::string(0);
> 
> Obviously, it's illegal to pass a const char* to the ctor of 
> basic_string that is zero. The current implementation results in a SEGV. 
> I would like to catch *some* of the cases at compile-time instead of 
> having a crashing program. :)

The merits of this idea aside, using 3.4 I get:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
Abort trap (core dumped)

So the problem has been addressed and is a lot more debuggable than just
a segfault. It still crashes, but with an obvious message.

IRC 3.3 also throws an exception, but doesn't use the verbose terminate
handler by default.


Apologies in advance if the following is nonsense, I'm rushing to catch
a train...

Your idea would mean that std::string(1) results in an access error,
rather than an error about converting int to const char* - I don't know
how much that would matter, since it fails to compile either way, but I
can see an argument that the required diagnostic isn't given.

Would there be any issues for implicit conversions?  e.g.

struct MyStupidAllocator
{
    MyStupidAllocator(int) {}
    // ...
};

std::basic_string<char, std::char_traits<char>, MyStupidAllocator> s(1);

Wouldn't this change from a foolish, but legal program to an illegal one?

jon


-- 
"Fanaticism consists in redoubling your efforts when you have forgotten 
 your aims."
	- George Santayana