new operator

1. How come that changing the size of the memory allocated new char(256);
the size of the file wont change?
2. Why do we need to clear it with memset, when i write "world" to it and print it
hello is no longer there. Looks like it clears itself.

Code:

#include <iostream>
#include <windows.h>

using namespace std;
char *buffer = new char(256);

int main()
{
    strcpy(buffer, "hello");
    cout << buffer << "\n";
    strcpy(buffer, "world");
    cout << buffer << "\n";
    memset(buffer, 0, 256);
    cout << buffer << "\n";
    delete buffer;
    return 0;
}

1. Which file, your program file? Your program file doesn't contain the memory inside of it -- it contains the instructions to go get the memory when the program is run.

2. strcpy will overwrite the first six characters of your buffer.

3. That assumes that your buffer contains six characters in the first place, which I don't believe it does. Are you sure you don't mean "new char[256]" (and consequently "delete[] buffer") instead? Right now, you are getting one char, with the value 256.

I would suggest you use std::string instead of char.

Originally Posted by tabstop

3. That assumes that your buffer contains six characters in the first place, which I don't believe it does. Are you sure you don't mean "new char[256]" (and consequently "delete[] buffer") instead? Right now, you are getting one char, with the value 256.

Yeah except that a char probably wont hold 256 (0x100), so it'll actually hold 0 (0x00) instead.

std::string seconded.

Thanks, i go with string instead then.

So is it ok to replace this:

Code:

char *buffer = new char[256];

while(..)
{
memset(buffer, 0, length);

operation on buffer;
...
}
delete[] buffer;

with this:

Code:

string buffer ;

while(..)
{
operation on buffer;
...
...
}

Or do i need to clear std::string too everytime?

If you want an empty string for each iteration and the logic doesn't ensure that the string ends up being empty by the end of the loop, then naturally you should clear it. For that there is the clear() method.

Thank you Anon!

But if i should use a char* in a function i should go through all this transformation so i wonder if there is any good for using string?

Code:

string str; 
char buf[256];
strcpy(buf, str.c_str());

>> But if i should use a char* in a function

What function do you need a char* for? If it is one of your functions, you should change it to use strings. If it is from another library, then are you sure it doesn't need const char* ?

Its recv(), it takes a char*

Is it worth it to use string with it?

Code:

int recv(
  __in   SOCKET s,
  __out  char *buf,
  __in   int len,
  __in   int flags
);

Originally Posted by Ducky

Is it worth it to use string with it?

You may want to consider using a std::vector<char> instead, at least until it is guaranteed that the pointer returned by &str[0], where str is a std::string, points to the first character of a contiguous array of characters. (There is such a guarantee if str was a std::vector<char> instead.)

If you use std::vector<char>, don't forget to call resize() on the vector before you call recv().

>> Its recv()

Ok, that is one of the few instances where it makes sense to not use string. char buf[256] or std::vector<char> buf(256) would both be appropriate.

What you use for the rest of your program depends on what you're doing, though. If you're manipulating the data as a string, I'd still convert to and from string and only use the character array when working with send and recv. If you're not doing much, then maybe it's ok to use the array the whole time.

Note that for recv, you don't need to copy the string into the buffer using strcpy, because recv fills the buffer. And for send, you shouldn't need to use strcpy either, since c_str() should work. (Note: I don't remember if send takes a char* or const char*. If it takes only a char*, then you'd have to use strcpy or a const_cast.)

Originally Posted by laserlight

You may want to consider using a std::vector<char> instead, at least until it is guaranteed that the pointer returned by &str[0], where str is a std::string, points to the first character of a contiguous array of characters.

Didn't we go through this last time?

Originally Posted by http://herbsutter.wordpress.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/

However, current ISO C++ does require &str[0] to cough up a pointer to contiguous string data (but not necessarily null-terminated!)

&(str[0]) (21.3.1.4) == &(str.data()[0]) (21.3.6.3)== &(ptr to array[0]) == ptr to array

Originally Posted by adeyblue

Didn't we go through this last time?

Yes, we did. I cannot recall the exact outcome of that conversation, but I did not go away convinced that Sutter is correct on this point. I believe it had something to do with ambiguity in the text of C++03. What I am convinced by is that there is no point debating as this will be fixed in the next version of the C++ standard, and for now one should play safe rather than sorry.

EDIT:
Ah yes, I remember now. The problem is that data() returns a const charT*, hence defining the non-const version of operator[] in terms of data() is illogical, but it is precisely that version of operator[] that is in question here.