memcpy driving me crazy

Hi all,

I want to create a buffer to send to some external device. I store the values in char arrays.

I want to copy the values into one buffer with this code:

Code:

---

void CRobotData::GenerateBuffer(char * pBuffer)
{
        // Declare variables
        int iPointerAddress = 0;

        // Copy all data
        memcpy(pBuffer + iPointerAddress, m_a, 4);
        iPointerAddress += 4;
        memcpy(pBuffer + iPointerAddress, m_b, 4);
        iPointerAddress += 4;
        memcpy(pBuffer + iPointerAddress, m_c, 4);
        iPointerAddress += 4;
        memcpy(pBuffer + iPointerAddress, m_d, 4);
}

---

The buffer is created like this:

Code:

---

char * pBuffer = new char[16];
ZeroMemory(pBuffer, 16);

---

What happens is this:
pBuffer = "0000000000000000ýýýýÝÝÝÝA"

It is driving me crazy, why isn't the buffer 16 x 0 as it should be?

Thanks!

It looks like your buffer is 16 characters long, and m_a, m_b, m_c and m_d all have values the ascii character '0'. So it's behaving as expected.

Your buffer isn't null-terminated, so if you expect to use it as a null-terminated string, you'll need to allocate 17 characters, and put a null character at the end.
(memcpy has no way to guess that you're dealing with a string, it's just copying memory)

I see 16 zeroes.

But I don't want it to behave like text, just a buffer so I can send it directly into a machine.

When I close the buffer with a \0, the buffer will be 17 long, and I can only send 16 to the machine.

Quote:

---

Originally Posted by Tischnoetentoet

The buffer is created like this:

Code:

---

char * pBuffer = new char[16];
ZeroMemory(pBuffer, 16);

---

What happens is this:
pBuffer = "0000000000000000ýýýýÝÝÝÝA"

It is driving me crazy, why isn't the buffer 16 x 0 as it should be?

---

Could it be that you are confounding the null character ('\0') with the character for the digit '0'? In any case, pBuffer shouldn't be looking like you posted after a ZeroMemory, but show as an empty string when displyed as a string. Or how have you been looking at the buffer contents?

Besides that, instead of allocating the buffer with new and doing all that pointer arithmetic: Wouldn't it be easier to define a struct (with #pragma pack(1)) which simply represents the layout of the buffer and use that instead?

Apart from terminating it null you should track the length of your data, and/or use static allocated arrays as much as possible. Especially when you expect your buffer to hold a null value.

And you now the size of the array why not creating it statically?

[char]char buffer[16];[/code]

When I use ZeroMemory, the buffer is "", but after I fill it again, it has the values behind it again.

Quote:

---

Besides that, instead of allocating the buffer with new and doing all that pointer arithmetic: Wouldn't it be easier to define a struct (with #pragma pack(1)) which simply represents the layout of the buffer and use that instead?

---

Yes, that would be nicer. I could just send the pointer of the struct as the buffer. But the problem is that I need some other structs too. All values always should have the same values, except for some of them.

When I use a structs, I cannot set any default values, that's why I tried to create a solution with a class that creates the buffer and always stores the right data.

I know the size of the buffer. My buffer class also has a function GetBufferSize. This function calculates the length of the buffer so I know how large my array must be.

Quote:

---

Originally Posted by Tischnoetentoet

When I use ZeroMemory, the buffer is "", but after I fill it again, it has the values behind it again.

---

Well, that's pretty obvious: If you are treating your buffer like a string (which must be null-terminated in C/C++, remember) what you see after calling ZeroMemory() is of course an empty string, since the null terminator is in the first place. If you then write values to the buffer, you will see the character representations of those values, until a null character is encountered - this may be within your 16 byte buffer, or at any arbitrary place in memory after your buffer, depending on the random memory contents (since your buffer is not explicitly null-terminated, which is fine, since it's not a string). However, you seem to be using either some string output function or the debugger for looking at that char array, and both expect a null-terminated string. The bottom line: There is nothing wrong with your buffer: It is 16 bytes long and contains 16 '0' characters. What's in memory after your buffer is completely irrelevant.

Quote:

---

Originally Posted by Tischnoetentoet

Yes, that would be nicer. I could just send the pointer of the struct as the buffer. But the problem is that I need some other structs too. All values always should have the same values, except for some of them.

---

Well, it depends on your specific situation of course. But the usual way to handle this is to define various structures for the different buffer layouts you need.

Quote:

---

Originally Posted by Tischnoetentoet

When I use a structs, I cannot set any default values

---

Why not? You can even define a ctor for the struct which initializes it with the correct default values.

Quote:

---

Why not? You can even define a ctor for the struct which initializes it with the correct default values.

---

You are making me curious about the struct with constructor. I will search about some information about the struct.

When I create a struct with a constructor, can I still use the address of the struct as start of the buffer? Because the size of the struct will be larger because there is a constructor included.

Quote:

---

Originally Posted by Tischnoetentoet

You are making me curious about the struct with constructor. I will search about some information about the struct.

---

It's just the same as with a class... The only difference between class and struct are the default protection levels for members and inheritance.

Quote:

---

Originally Posted by Tischnoetentoet

When I create a struct with a constructor, can I still use the address of the struct as start of the buffer?

---

Sure. Just as you can with a class.

Quote:

---

Originally Posted by Tischnoetentoet

Because the size of the struct will be larger because there is a constructor included.

---

No, it won't. The constructor is code - it is not part of the struct's memory layout. What would be the point of including the code for the ctor (or any other member function, for that matter) in the memory layout and duplicate it for every instance? No, an instance of a struct with two int member variables has a size of 8 bytes. An instance of a struct with two int member variables and 100 member functions is still 8 bytes in size.

Thank you!

This is very interesting! I will check if I can port my code to structs!