String memory issue?

Is this way of creating memory valid?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

struct structTest {
	char* text;
};

struct arrayTest {
	structTest* field;
};

void addBits(arrayTest &z) {
	z.field = new structTest[2];
	z.field[0].text = "Something1";
	z.field[1].text = "Something2";
	z.field[2].text = "Something3";
}

void deleteBits(arrayTest &z) {
	arrayTest z2;
	z2.field = new structTest[1];

	for (unsigned int loop = 0; loop < 2; loop++) {
		z2.field[loop] = z.field[loop + 1];
	}

	z.field = z2.field;
}

int main() {
	arrayTest x;

	addBits(x);

	deleteBits(x);

	system("pause");
};


Regards
Last edited on
z.field[2].text = "Something3"; This is out of bounds because you try to access the third element in the array that has only 2 elements.
What you've actually done is technically incorrect, but there is a way to do it safely.

addBits declares an array of two items and writes three items into it.
deleteBits overwrites the array of two items with an array of one item, then overwrites that too.
The number of items specified (2) is a base zero number? Surely?!?!
Last edited on
I can't believe how many lines of C++ I have written and this has never been obvious or even a (recognised) problem before :)
I just quickly increased all the definitions of arrays in my code by one and I am still getting the same error :(

Any other ideas? I am thinking the error is to do with memory allocation/deallocation. Does that bit look reasonable?
It might help if you describe what you want to do.
Well... that, I guess?!

I have a struct containing arrays of classes and chars.

I have functions written the way I have above which add and remove items from the arrays.

I have done it lots of times in my code with success... but I suddenly have an error that seems to have occurred because memory is messed up.

Makes me wonder if this way of working with structs (the way I pass them in to functions and modify them using this method) is the problem...
The '2' means a size of 2, so indices [0, 1], so yes you need to allocate with size '1 + max index'. The first problem that jumps out at me is:
z.field[0].text = "Something1";

You aren't copying the string 'Something1' into text, you are storing a pointer to that string, which isn't guaranteed to be valid after the expression in which it is initialized. What you want is:

1
2
3
z.field[0].text = new char [strlen("Something1") + 1]; // +1 for the NULL
strcpy(z.field[0].text, "Something1");
// repeat 


Then, you will need to delete text at some point as well, of course. Note this is the C-style way of doing things - you can use "std::string" to make life easier, if you want.
Last edited on
I would upload the VC++ project with the error but it contains lots of files...

z.field[0].text = new char [strlen("Something1") + 1]; // +1 for the NULL
strcpy(z.field[0].text, "Something1");
// repeat


I think this is what I was expecting... thanks man. Will try and report back...
@rollie - string literals stays alive throughout the whole program so that is not the problem.
Peter is right...I was looking at what I wrote and wondering if I was remembering wrong :P

Your issue is probably just array sizes after all.
Last edited on
I changed the copying of strings to the code you described and I am still getting the issue :(

Cheers though... will maintain with this way of handling strings now.



Anyone willing to receive the project via email and have a quick look, please? ;)
pleeeeeeeeeeeeease?
When you say it doesn't work. Do you mean that the above code doesn't work after you fixed it or that your other project that we have never seen doesn't work?
My other project... so it's probably time to move the focus from this code to my old code... but it's too big to upload. Not THAT big just too big for a forum post (23kb).

It's a simple bit of code really... should only take a second to see the issue(s) if someone actually knows C++ (unlike me, it would seem)
Last edited on
OK... just tracked the problem with a watch... I don't think it is a memory issue after all.

Thanks all for looking and for your much appreciated input!
Topic archived. No new replies allowed.