Inputting a dynamic, mutable character array with spaces

Hello :)

This is to anyone who needs the following:

Dynamic array (the size is defined at run-time)
Mutable array (the characters within the array can be edited)
Spaces allowed (the input allows for spaces)

Code:

---

#include <iostream>
#include <string>
using namespace std;

int main()
{
    cout << "Enter the line : ";

    string str; //Declare the string
    getline(cin,str); //Define the string (getline allows for spaces)

    char* characters = NULL;    //Make a new character array
    int size = str.size()+1;    //with str's
    characters = new char[size]; //size
    characters[size-1] = 0;      //terminate with a null

    //Copy str's characters into the array called characters
    for( size_t copy = 0 ; copy < str.size() ; copy++ )
        characters[copy] = str.at(copy);

  //You can output the size of the character array
    cout << strlen(characters) << endl;

    //You can output the actual character array
    for( size_t show = 0 ; show < strlen(characters) ; show++ )
        cout << characters[show];

    cout << endl;

    //You can edit the characters
    characters[0] = 'Z';
    for( size_t show = 0 ; show < strlen(characters) ; show++ )
        cout << characters[show];
}

---

If anyone knows of an easier method, go ahead and post!
Good luck everyone :cool:

Why do you need such a character array when you have a mutable string object? Are you aware of the c_str() member function of std::string?

Oh no I didn't. Whoops. I will look into that right away.

Quote:

---

Mutable array (the characters within the array can be edited)

---

Why is this a requirement?

It is a strange requirement, but such a mutable dynamic array is std::vector.

Code:

---

string s;
getline(cin, s);
vector<char> vec(s.size() + 1); //+1 for null terminator
std::copy(s.begin(), s.end(), vec.begin());

---

Code:

---

#include <iostream>
#include <string>
using namespace std;

int main()
{
    cout << "Enter the line : ";

    string str; //Declare the string
    getline(cin,str); //Define the string (getline allows for spaces)

    //You can output the size of the character array
    cout << str.size() << endl;

    //You can output the actual character array
    cout << str;
    cout << endl;

    //You can edit the characters
    str[0] = 'Z';
    cout << str;
}

---

What not just use this?
Also, do not use NULL, use nullptr. NULL is evil.

Quote:

---

Originally Posted by Elysia

Also, do not use NULL, use nullptr. NULL is evil.

---

Unfortunately, nullptr does not yet exist in standard C++, so be aware that it may not work. Anyway, one might as well initialise characters to the return value of new char[size] instead of first initialising it to be a null pointer, only to be overwritten shortly afterwards.

It is true what you say, but pushing people towards C++0x and ridding the world of NULL is my goal. If they can, they should. If not, then it's too bad. Still, it is better to be aggressive about it than not, since it raises awareness.

Engage in hyperbole much? nullptr may be a null pointer literal and preferable to NULL, but NULL didn't do anything evil.

NULL is the root of much evil. It screws up code, disguises bugs and adds an evil exception in the standard for a conversion that makes no sense (integer -> pointer).

>> NULL is the root of much evil. It screws up code, disguises bugs
I don't see how nullptr mitigates this. The only thing nullptr could mitigate is that exception in the standard for integer to pointer conversion. It's a conversion that Stroustrup seemed to institutionalize by defining NULL as 0. I wont draw attention to idiotic behaviors like using hardcoded addresses, and call NULL evil because of that. Constants are not evil. They are in fact the things we can rely on being.

The problem is a fundamental one. Consider:

Code:

---

void foo(int * p) { /*... */ }
void foo(int n) { /* ... */ }

foo(NULL); // Which overload will it call?
foo(nullptr); // Which overload will it call?

---

This problem becomes even worse when you think of forwarding. A class stores NULL as a parameter and then tries to forward it to a function that has several overloads. Which one will it call?
Worse yet - what if you try to pass NULL to a function that only takes an integer?

This is a fundamental issue that conflicts with C++'s strict type system. There is a reason why the Visual Studio C++ team implemented nullptr in their compiler at the first revision.

Assuming your type system has any promotion rules, normal things should happen. Passing NULL results in a function with a pointer as an argument being called, if one is available. If one isn't available expect warnings at most or an implicit conversion.

Not to mention this is as much a criticism of overloaded functions. When functions are only distinguished by their argument lists, things like this will occur. It occurs with strings versus char* (try calling a legacy function that was overloaded). These are defects within the type system, that do not go away because nullptr is introduced.

Quote:

---

Originally Posted by whiteflags

Assuming your type system has any promotion rules, normal things should happen. Passing NULL results in a function with a pointer as an argument being called, if one is available. If one isn't available expect warnings at most or an implicit conversion.

---

Not if you have an overloaded non-pointer version too. In my example, the int version is called. Perfectly normal. No warnings. Because the null pointer is an integer. Rather silly.

And it won't get rid of all quirks. Of course not. But it will get rid of some.
Small steps at a time, eh? That's why NULL is evil.

Then NULL is evil because Stroustrup made it evil. Take a look at stdlib.h - NULL is ((void*)0) or similar. Had he left NULL alone he wouldn't have created this retarded problem.