[RESOLVED] is there any problem if I set a char to '\0' within a string?

[Feoggou]

Just to make sure: I have a string like this:

WCHAR* wsThing = new WCHAR[nLen]; //assume nLen = 20;
wsThing[8] = 0;
delete[] wsThing;

I just want to make sure: it releases all memory, right?

[laserlight]

Yes, but consider:

std::vector<WCHAR> wsThing(nLen); //assume nLen = 20;
wsThing[8] = 0;
// Look ma, no need to remember to delete[]!

[monarch_dodra]

You can do it, but you are undermining the system. Passing the string as an array to a C-Style API will break the API. You may have weird behavior when putting the string in a stream.

Strings hold char, but they are really supposed to represent text. If you just want a container of char, consider using a vector<char> instead. The interface will be better adapted, and your code less confusing.

[Feoggou]

You can do it, but you are undermining the system. Passing the string as an array to a C-Style API will break the API. You may have weird behavior when putting the string in a stream.

Strings hold char, but they are really supposed to represent text. If you just want a container of char, consider using a vector<char> instead. The interface will be better adapted, and your code less confusing.

sorry for asking, but for whom is this message, for me or for laserlight?

I only need to make sure that delete[] deletes the characters after '\0' as well. I'm using the string with windows API functions. the display is correct (I've had no problems with it).

[monarch_dodra]

sorry for asking, but for whom is this message, for me or for laserlight?

I only need to make sure that delete[] deletes the characters after '\0' as well. I'm using the string with windows API functions. the display is correct (I've had no problems with it).

It was for you, but it was irrelevant. I hadn't taken the time to read your full message, sorry. I thought you were talking about std::string, when in fact you were talking about plain old char arrays.

The delete will be correct, as delete does not look at the object contents contents to know the bounds. However, for mostly every other function of the type strlen, or strcopy, you have to make sure your string is null terminated.

Also, consider using std::string, arrays are evil.

[ninja9578]

delete doesn't care what's in the array. Null terminators are placed in the middle of arrays all the time, thats how you change the length of a string

However, seeing that you're using C++, might I recommend std::wstring instead? That does all the memory management for you.

[Dateol]

Try this
wsThing[19]='\0';
//Well, that is your ma!

[GCDEF]

Try this
wsThing[19]='\0';
//Well, that is your ma!

Why?

[Sharpie]

This is an Obama application, then they are the peasants, farmers or idiotic laymen,
and we are the government sometimes the general, sometimes the CIAs etc, All that high! ****ing

[GCDEF]

This is an Obama application, then they are the peasants, farmers or idiotic laymen,
and we are the government sometimes the general, sometimes the CIAs etc, All that high! ****ing

This forum attracts more than its share of nuts. What is the purpose of that post, and did you forget your meds?

[ninja9578]

Yes, but consider:

std::vector<WCHAR> wsThing(nLen); //assume nLen = 20;
wsThing[8] = 0;
// Look ma, no need to remember to delete[]!

You can even do this

WCHAR wsThing[nLen];
wsThing[8] = 0;
//I don't need delete[] either :)

It's not standard, but most compilers allow you to do this. GNU certainly does, I would be very surprised if VC++ doesn't. I'm guessing that behind the scenes, it uses an autoptr.

[Lindley]

That does not work in VS because it's only standard in C99, and VS does not support C99. Since gcc supports C99 anyway, allowing c++ to do it too is an easy extension, but you should absolutely not write C++ that way if you have any expectation of portability.

[laserlight]

I'm guessing that behind the scenes, it uses an autoptr.

I have the impression that gcc's implementation of variable length arrays uses the stack, so the g++ extension probably does so too rather than make use of a smart pointer behind the scenes.

[ninja9578]

Oh, I guess so. I actually don't see a reason for this to not be added to the standard. It is really easy to implement:

int x[y];

mov ax, [y]
muli ax,  4  ;4 bytes to an int
add sp, ax

[Lindley]

Well, it does slightly complicate the computation of the stack position of other locals.