String ctor

[giles]

Why does the below program crash?

#include <string>

using namespace std;

int main()
{
string name = 0;
return 0;
}

 

[Alf P. Steinbach]

* giles:

Why does the below program crash?

#include <string>

using namespace std;

int main()
{
string name = 0;
return 0;
}

How many times are you going to ask this question?

Oh well, it's because the standard defines the string constructor that way.

Happy now?

 

[wittempj]

If you want to initialize a string do:
-#include <string>
-
-using namespace std;
-
-int main()
-{
- string s = "";
- string t("");
-
- return 0;
-}

 

[Duane Hebert]

Oh well, it's because the standard defines the string constructor that

way.

Any idea why the standard doesn't define std::string spoo(0) to create
an empty string? Seems like a good idea.

 

[Val]

| Why does the below program crash?
|
| #include <string>
|
| using namespace std;
|
| int main()
| {
| string name = 0;
| return 0;
| }

Why does the program below behave weird?

int main()
{
unsigned number = "Hello world".
return 0;
}

 

[Mike Wahler]

way.

Any idea why the standard doesn't define std::string spoo(0) to create
an empty string?

Because it doesn't need to. There are already two other
constructors which can create an empty string:

std::string s;

std::string s("");

Passing zero as the argument to the second one (as the
OP was doing), is passing a null pointer -- undefined behavior.

Seems like a good idea.

Not to me.

-Mike

 

[Stephen M. Webb]

way.

Any idea why the standard doesn't define std::string spoo(0) to create
an empty string? Seems like a good idea.

For consistency. Constructing a std::string object from a single
integral value invokes the std::basic_string(const Char* p, const
Allocator& a = Allocator()) constructor. This kinda works just like
the C library functions strcpy(), strcat(), strlen(), and so on.

You will find that those C functions do not treat a null pointer as a
null string (some implementation may, but dereferencing a null pointer
yields undefined behaviour). All my favorite C library
implementations signal an error.

Another reason is the pay-for-what-you-use principal. Why should
every string construction have to pay the price of a null-check just
in case?

 

[Old Wolf]

:
| Why does the below program crash?
|
| int main()
| {
| string name = 0;
| return 0;
| }

Why does the program below behave weird?

int main()
{
unsigned number = "Hello world".
return 0;
}

Slight difference: your program (with typoes fixed) requires
a compiler diagnostic, but the OP program doesn't.

 

[E. Robert Tisdale]

Why does the below program crash?

cat main.cc

#include <string>

int main(int argc, char* argv[]) {
std::string name = 0;
return 0;
}

g++ -Wall -ansi -pedantic -o main main.cc
./main

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

Because that's what is supposed to happen
when you fail to catch an exception.
Next time, show us your compiler and options
and include any compile-time diagnostics
and run-time error messages that you got.

 

[Karl Heinz Buchegger]

For consistency. Constructing a std::string object from a single
integral value invokes the std::basic_string(const Char* p, const
Allocator& a = Allocator()) constructor. This kinda works just like
the C library functions strcpy(), strcat(), strlen(), and so on.

You will find that those C functions do not treat a null pointer as a
null string (some implementation may, but dereferencing a null pointer
yields undefined behaviour). All my favorite C library
implementations signal an error.

True. But C++ tries to make programmers life easier by not having
to constantly deal with exceptions.
In practice this means that most of the time when someone creates a std::string
from a const char* he has to check that pointer.

Another reason is the pay-for-what-you-use principal. Why should
every string construction have to pay the price of a null-check just
in case?

The same could be said for delete.
Why does delete need to check for NULL, just in case.

Note: I don't consider "This has been so in C" as a very good argumentation.
After all, millions of C programmers lived happily with dynamically allocating
arrays and yet someone felt the need to introduce std::vector to solve a problem.
So the fact that strxxx() doesn't deal with NULL pointers in a logical way
can't be an argument.

 

[Richard Herring]

Why does the below program crash?

cat main.cc

#include <string>

int main(int argc, char* argv[]) {
std::string name = 0;
return 0;
}

g++ -Wall -ansi -pedantic -o main main.cc
./main

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

Because that's what is supposed to happen
when you fail to catch an exception.

Oh. Which exception does the standard mandate for dereferencing a null
pointer?