Freeing char array.

[Dudester]

I was working on some code that opens a file using the ofstream class and a pointer to a character array, the character array is a pointer to the filename. When I tree to delete the array my program stalls out and gets stuck at the delete line. I'm using the string class to get the string that is the filename and then converting it to a c string using the c_str method. I'm thinking that this method may not return a null-terminated string. Am I correct on this and should therefore add a null at the end? Here's a simplified version of my code to clarify my problem.

string Input;
getline(cin, Input);

char *pStr = new char[Input.length()];
strcpy(pStr, Input.c_str());

// Open a file and do some stuff.

delete [] pStr; // This is where my program stalls. 

Thanks for the help!
~Dudester~

[Onanymous]

try Input.length() + 1. :) I guess you need space for end of the line character.

[R0mai]

You should allocate Input.length()+1 chars, since you have to allocate a byte to c-string's terminating 0.
300th post...

[helios]

What the point of pStr? You can just use std::string::c_str().

[Dudester]

Lol I would forget about that.

@Helios
In reality I didn't. The code that contains the char array is a member of a class. I didn't want to include the string library with that class so I used pointers instead. The driver for the class uses a string in this case so I wrote the code to be similar.

[helios]

I didn't want to include the string library with that class so I used pointers instead.

Why?

[kempofighter]

You mean the string header file, <string>? Once it is included and used it makes no difference how many places you include it.

By the way, the original program contains undefined behavior. strcpy WILL copy the NULL pointer into a pStr which is not setup to be big enough. You can pass a string reference or a const char* to the function in question without having to dynamically allocating memory. Dynamically allocating memory just so that you can pass a char* to a function is a bad idea.

[Dudester]

I didn't want this class to be dependant on the string class mostly because what happens if I don't want it or I'm not going to make us of it in the program that is using my class. It would just be extra data that isn't being used. The example I gave is not an exact exerpt from my code. It is simplification of what the overall behavior looks like that is causing the problem.

[helios]

what happens if [...] I'm not going to make us of it in the program that is using my class

What?

sizeof(std::string) is usually the size of two pointers. In exchange for that, you save yourself the trouble of manipulating the strings manually, managing the memory manually, and all the possible errors that can come from making mistakes in those two tasks (such as the one above). Do you really think it's not worth it?

[Dudester]

I guess not. I can see where you're coming from. I will make the changes which shouldn't take long. I'll wait a bit longer before trying with pointers again. By the way I was refering to compile size not the size of the strings themselves. I don't like having a program that is larger than it should be. That's how code starts getting bloated.

[Disch]

I didn't want this class to be dependant on the string class mostly because what happens if I don't want it or I'm not going to make us of it in the program that is using my class.

This would make sense if <string> added anything significant to your binary. But as it stands, it's nonsensical.

Have you tried actually doing comparisons of programs built with and without <string>?

Also, using string might actually increase performance because it might reduce the number of times the string is actually copied.

As far as code size goes... The std::string functions are probably no larger than the cstring equivilents. IE: using the string assignment operator doesn't result in any more "bloat" than calling strcpy.

[kempofighter]

Are you writing embedded software for a special kind of chip or is this a windows application? Why are you getting hung up purely on executable size? Even if the size did significantly increase you could end up with a much better program. As far as bloat goes, I do not know what that means. The code that you write will be much simpler and maintainable if you use std::string and avoid reinventing the wheel. It will also be much more secure and less error prone.

[Dudester]

I am still pretty new to programming so I haven't looked too closely into total sizes yet and the only performance testing I've done is on code I've written. IE: testing to see if one method/function performs faster and with less memory than another. Since I haven't checked for library sizes I'm tyring to run on a minimalist standpoint. If I don't need it then there's no point in including it. I'm doing this in the hope that it helps me learn and maintain some better practices for when I finish college.

[Disch]

If I don't need it then there's no point in including it

This is flawed logic.

You don't need a lot of stuff you're using. strcpy, for example. It's perfectly possible to write a program without it.

You don't even need things like multiplication, in the strictest sense. You could do everything with loops, bitshifting, and addition. But that's ridiculous.

The line should be drawn more practically. Instead, think of it as what you have a good use for.

You want to have a string represented, therefore you would have a good use for <string>, therefore you should include it.

No point in writing all this additional code to do what string already does.

[helios]

It's worth noting, however, that that logic does make sense when talking about libraries not provided by the language, as added external dependencies increase complexity, specially for cross platform applications. To name an example, I know of an SVG library that requires, directly or indirectly, around fifteen dependencies. Fif-freaking-teen. Just figuring out the order to build them in is hard enough.

There's no excuse for standard headers. though.

[Dudester]

Thanks for the help and advice guys. I'll remember that.

[Disch]

helios speaks the truth.

My advice about "don't hesitate to use it" is applicable to standard libs. But for external libs, you will want to me more disciminatory.