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

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

Code:

---

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

---

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

Yes, but consider:

Code:

---

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

---

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.

Quote:

---

Originally Posted by 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.

---

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).

Quote:

---

Originally Posted by Feoggou

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.

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.

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

Quote:

---

Originally Posted by Dateol

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

---

Why?

:ehh: 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 :sick:

Quote:

---

Originally Posted by Sharpie

:ehh: 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 :sick:

---

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

Quote:

---

Originally Posted by laserlight

Yes, but consider:

Code:

---

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

---

---

You can even do this

Code:

---

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.

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.

Quote:

---

Originally Posted by ninja9578

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.

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:

Code:

---

int x[y];

---

Code:

---

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

---

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

from the example you gave (http://www.parashift.com/c++-faq-lit...html#faq-17.11)
I don't understand why he tried to write all that code with simple char* strings.

I would have done like this:

Code:

---

void userCode(char const* s1, char const* s2)
 {
//concatenates strings s1 and s2 and stores it in copy (which means the function does nothing fruitful

  int len = strlen(s1) + strlen(s2) + 1;
  char* copy = new char[len];
  StringCchCopyA(copy, len, s1);
  StringCchCatA(copy, len, s2);

  delete[] copy;
 }

---

and by the way, null-terminated strings (like char* copy) are faster than string and wstring. And you have all functions you need for working with them. unlike "string": or tell me how you format a string using "string".

Also, if you work with windows API (I do), you inevitably use null-terminated strings (char*, wchar_t*), and, rather than copying them into a "string", etc. and perform operations, it is usually better (and always faster) to work with pure char* and wchar_t* functions.

Quote:

---

I don't understand why he tried to write all that code with simple char* strings.

---

The try block was to avoid memory leaks. This is right there in the comment.

Quote:

---

Originally Posted by Feoggou

I would have done like this:

---

Please note that this is the Non Visual C++ Issues forum. Furthermore, your example is flawed as a comparison: there is only one use of new[], so there is no worry about a memory leak should an exception be thrown. This is different from the example that you are criticising.

Quote:

---

Originally Posted by Feoggou

and by the way, null-terminated strings (like char* copy) are faster than string and wstring.

---

It depends.

Quote:

---

Originally Posted by Feoggou

And you have all functions you need for working with them. unlike "string": or tell me how you format a string using "string".

---

You could use a stringstream, Boost.Format if it is available, or if you prefer, make use of null terminated string formatting functionality through the c_str() member function.

Quote:

---

The try block was to avoid memory leaks. This is right there in the comment.

---

sorry for asking, but how can a memory leak happen there?

Quote:

---

Please note that this is the Non Visual C++ Issues forum. Furthermore, your example is flawed as a comparison: there is only one use of new[], so there is no worry about a memory leak should an exception be thrown. This is different from the example that you are criticising.

---

I don't get it: why is it wrong that I use only a new? if I know exactly how much I need, it is pointless to use 2 strings and 2 new[] operations.
by the way, doesn't C++ have strcat? why worry so much with strcpy when you need to concatenate strings?

and I understand that simple C++ doesn't have "strcat_s", right?

Quote:

---

Originally Posted by Feoggou

sorry for asking, but how can a memory leak happen there?

---

Let's remove the try/catch blocks from that example:

Code:

---

void userCode(char const* s1, char const* s2)
{
    char* copy = new char[strlen(s1) + 1];    // make a copy
    strcpy(copy, s1);                        //  of s1...

    ...code that fiddles with copy...

    char* copy2 = new char[strlen(copy) + strlen(s2) + 1];  // append s2
    strcpy(copy2, copy);                                    //  onto the
    strcpy(copy2 + strlen(copy), s2);                      //  end of
    delete[] copy;                                          //  copy...
    copy = copy2;

    ...code that fiddles with copy again...

    delete[] copy;
}

---

Now, suppose an exception is thrown on this line:

Code:

---

char* copy2 = new char[strlen(copy) + strlen(s2) + 1];  // append s2

---

Control leaves the body of the function such that it reaches an appropriate handler for the exception. Unfortunately, this means that this line will never get executed, thus resulting in a memory leak:

Code:

---

delete[] copy;

---

Quote:

---

Originally Posted by Feoggou

I don't get it: why is it wrong that I use only a new? if I know exactly how much I need, it is pointless to use 2 strings and 2 new[] operations.

---

The flaw is in the comparison: you are comparing a case where the try/catch blocks are unnecessary to a case where they are necessary.

Quote:

---

Originally Posted by Feoggou

by the way, doesn't C++ have strcat? why worry so much with strcpy when you need to concatenate strings?

---

You might want to read this article entitled Back to Basics by Joel Spolsky. As an example, it explains why you should be wary of the repeated use of strcat. That said, in this case it was rather pointless to avoid strcat, since strlen(copy) results in the same unnecessary computation, unless an optimising compiler recognises that the result will be the same. But if that string length had been cached (like how it is for std::string), then using strcpy as demonstrated would have been more efficient.

Quote:

---

Originally Posted by Feoggou

and I understand that simple C++ doesn't have "strcat_s", right?

---

strcat_s is not part of the C++ standard library.

Quote:

---

Originally Posted by Feoggou

I don't get it: why is it wrong that I use only a new? if I know exactly how much I need, it is pointless to use 2 strings and 2 new[] operations.

---

Let's say for some reason you need 2 new[] operations, though. If the second one throws an exception, then the first will become a memory leak if you don't have a try/catch. With only one new[] this is less of an issue. Still, the very possibility is reason enough to prefer RAII containers such as std::string or std::vector rather than using new[] directly.

Quote:

---

by the way, doesn't C++ have strcat? why worry so much with strcpy when you need to concatenate strings?

---

A strcat() call is effectively equivalent to a strlen() on the first string followed by a strcpy() from the second to the first. This makes it linear in the combined length of the two strings (or amortized linear if you consider the possibility of reallocations and assume a smart reallocation scheme such as doubling capacity as necessary).

By contrast, std::string::operator+= is also linear (or amortized linear if there's a reallocation)----but if no reallocation is necessary, then it's linear in the size of the second string rather than in the size of both together. So it's probably slightly faster. And in addition, and necessary reallocation details are handled transparently, so it's a lot harder to screw it up via bad code or a poor choice of reallocation scheme.

Quote:

---

and I understand that simple C++ doesn't have "strcat_s", right?

---

Correct, that's one of the Microsoft extensions to the C standard library which serves little purpose except to reduce portability. Maybe if you're stuck in pure C land they could be some small aid to safety, but doing things the C++ way is usually a better option.

Quote:

---

Now, suppose an exception is thrown on this line:

Code:

---

char* copy2 = new char[strlen(copy) + strlen(s2) + 1];  // append s2

---

---

ok, but let's suppose an exception is thrown here:

Code:

---

char* copy = new char[strlen(s1) + 1];

---

isn't this possible? If it is, this is unhandled.

Quote:

---

Originally Posted by Feoggou

ok, but let's suppose an exception is thrown here:

Code:

---

char* copy = new char[strlen(s1) + 1];

---

isn't this possible? If it is, this is unhandled.

---

That would be fine. There is nothing to delete[] at that point (or more generally, no resources to deallocate), at least not within the scope of the function.

so you mean that if there was a code like this:

Code:

---

char* buffer1 = new char[24];
char* buffer2 = new char[35];
....
delete[] buffer2;
delete[] buffer1;

---

there would be no problem with the first, but with the second there could be?

if yes, why is it so?

Quote:

---

Originally Posted by Feoggou

there would be no problem with the first, but with the second there could be?

---

More like: the second could cause a problem for the first.

Quote:

---

Originally Posted by Feoggou

if yes, why is it so?

---

I have already explained it to you, and Lindley confirmed it: an exception could be thrown (in particular, std::bad_alloc, though if you were dealing with class types, other exceptions may also be possible), causing control to leave the scope such that the delete[] for the already allocated dynamic array of objects is never executed. In short, the code is not exception safe.

I asked that question because... when I learnt C++ years ago (I don't think STL was then, at least I did not have access a book with STL) I did not meet examples like this:

Code:

---

try {
p = new int (87);
} catch (bad_alloc xa) {
cout << "Allocation Failure\n";
}

---

so my question was, what could go wrong? not sufficient memory available? what else is possible?

Quote:

---

Originally Posted by Feoggou

so my question was, what could go wrong? not sufficient memory available? what else is possible?

---

Insufficient memory, or perhaps insufficient contiguous memory for the desired allocation, is one potential problem. If you are constructing objects of some class type, the constructor might throw an exception, e.g., due to invalid arguments or some other constraint violation.

The solution that I recommended in my first reply in this thread is basically RAII: associate the lifetime of a resource, such as memory, with that of an object whose destructor will free the resource when the object is destroyed, usually because the variable goes out of scope.

ok, thanks for all your help.