On the plus side, you found this problem early.
Sometimes people go for months or years believing their 'working' code is good only to find their stale pointers are down to pure dumb luck.
the memcpy looks good. you changed types (unsigned char vs char) above; are you doing a comparison that fails due to signs when you think it was 'corrupted'?
Are you doing any string operations, which would work on a c-string (football) but not png data (has random zeros wherever).
the way it is written, objectData == data for the first data_size bytes. So, if data is a valid pointer, and has at least data_size bytes, the above should have worked, barring other snafus like threaded program(?) where maybe something else touched data while you were copying it.
I don't get it... you had the size in the first version with memcpy, was it not set correctly?
that aside:
you need to call delete for every chunk of memory that you got with new. Every time. The where is what matters; here it looks like you want objectSize to live for a while after your copy, so when do you delete it? The destructor is a likely place to do that. Also, I highly recommend these changes:
constructor: set objectSize to null.
above code: if objectSize is not null, delete it first, before the new statement. You can skip the test and just delete it if you want, this is the *logic* but delete of null does not do anything and tests/conditions cost as much as just calling it, so you can leave the if off if you want.
proceed as above.
as it stands, if you call this routine more than once, you will leak memory, and if these are sizeable image files, you will actually be leaking LARGE amounts of memory. This is NOT good.
vectors are microscopically slower than your code, but if you don't understand pointers well, and really even if you do, you are introducing potential for bugs and problems by using pointers over vectors. Unless this is extreme high performance required code, I would use the vector... and if it is extreme performance, you have ... a lot of things yet to do to make this code efficient!
Made another version with getSize() method which simply returned sizeof(objectData). That didn't solve my problem because I ended up with the same result as originally:
1 2 3 4 5 6 7
public:
unsignedint getSize() { returnsizeof(objectData); }
...
ResourceObject ro(data, sizeof(data));
unsignedint ro_size = ro.getSize(); // still only 8 bites
I was told that sizeof will not work on the objectData member because it is a pointer & not a static char array. So, I would have to store the data size separately. So, I created the member variable objectSize to store it. Now, getSize() method returns objectSize:
I'm sorry, I really don't understand how I am creating memory leaks. I didn't think that objectSize was a pointer, so I wouldn't need to call delete on it. objectData is a pointer, so I call delete[] objectData; in the destructor.
sorry. I have a form of visual issue where front loaded variables all look the same to me, and I confused objectSize and objectData as you noticed.
Again, I don't know how you are using this stuff.
To leak memory would take the following scenario:
- you have some other method that is copying the data exactly the same way your constructor is doing it
- you call it more than once per object.
If you are keeping the memory to the constructor and destructor as shown, there is no problem! I just know how tempting it is to get something working and copy it... :)