C++ question about arrays....

[MrViggy]

If this is a school project and if you are restricted to NOT use STL, check out realloc

I'm not sure you can use realloc in conjunction with 'new[]' and 'delete[]'.

Viggy

[VladimirF]

I'm not sure you can use realloc in conjunction with 'new[]' and 'delete[]'.

I am sure I should't.
But I am also sure - I can:

int _tmain(int argc, _TCHAR* argv[])
{
	char* p = new char[16];
	strcpy(p, "this is a test");
	p = (char*)realloc(p, 10000);
	free(p);
	return 0;
}

If you look at the current MS, for example, implementation of new(), you'll find malloc().

[VladimirF]

Nop i dont think we are allowed.

There obviously are MANY ways to do what you want. But only you know the restrictions placed on your project.
So – what SHOULD you use? And what exactly is your question?

[MrViggy]

I am sure I should't.
But I am also sure - I can:

int _tmain(int argc, _TCHAR* argv[])
{
	char* p = new char[16];
	strcpy(p, "this is a test");
	p = (char*)realloc(p, 10000);
	free(p);
	return 0;
}

If you look at the current MS, for example, implementation of new(), you'll find malloc().

Well, yeah. I didn't think it would be an issue with POD. What about objects that have real constructors and destructors?

Viggy

[Russco]

I am sure I should't.
But I am also sure - I can:

int _tmain(int argc, _TCHAR* argv[])
{
    char* p = new char[16];
    strcpy(p, "this is a test");
    p = (char*)realloc(p, 10000);
    free(p);
    return 0;
}

If you look at the current MS, for example, implementation of new(), you'll find malloc().

I think code like this could be a problem. free wont call destructors and replacing it with delete[] wont work as realloc will not do new[]'s bookkeeping. Could lead to resource leaks if the type being stored releases resources in the destructor. Seems crazy to recommend something like that when its ubersimple to new[] a new block and copy the contents of the old block over to the new block, or even if c++0x is being used, moved over rather than copied.

[VladimirF]

Well, yeah. I didn't think it would be an issue with POD. What about objects that have real constructors and destructors?

That will get ugly. The constructor, of course, will be called by new(), but free() will not call destructor.

[VladimirF]

I think code like this could be a problem. free wont call destructors and replacing it with delete[] wont work as realloc will not do new[]'s bookkeeping. Could lead to resource leaks if the type being stored releases resources in the destructor. Seems crazy to recommend something like that when its ubersimple to new[] a new block and copy the contents of the old block over to the new block, or even if c++0x is being used, moved over rather than copied.

I agree, 100%. My argument was purely academical. I do NOT recommend to pair new() with free().

[monarch_dodra]

mixing alloc/free with new/delete is undefined behaviour 100% of the time. POD is not enough to guarantee compatibility.

The standard does not give one single situation were it is legal.

The fact that you are mixing them and it doesn't crash is because undefined behaviour doesn't guarantee a crash.

[Paul McKenzie]

i meant a way by using normal arrays with pointers and new/delete operators...

If expert programmers mess up using new/delete, I hold little chance that a beginner will get it right.

It is not "easy" to use dynamically allocated memory, unless

1) you know exactly what you're doing at every single step and

2) if there is a problem, you know how to diagnose and fix it.

There was a recent thread here that I was involved in -- it must have been over 50 posts in legnth, trying to get a student in getting a dynamic array working correctly, and I still don't think it was correct.

as VladimirF noticed it is a school project that my teacher has not thought us of vectors and gave us the project. so i think it should be done in another way

Why not ask the teacher? The goal of your assignment is to do something with student information -- I see no request in writing a dynamic array class. So you'll spend all of your time (as you're doing now), trying to get a dynamic array to work, and the time is flying by without completing the real goal of the assignment, which is to manage student information.

...is there?

Yes, code your own dynamic array. The problem is that beginner C++ students, going by my experience, never codes one correctly. Even many C++ teachers don't get it right.

Regards,

Paul McKenzie

[VladimirF]

I feel a need to defend myself for some reason.
In no way did I advocate mixing new with free. I merely stated that a particular compiler, in its particular version, might implement them the same way. And only then you pay no penalty for such major mistake.
As for the use of dynamic arrays or other dynamic memory allocations – I see a point in teaching those things. If for no other reason than to later point: and now see how much better STL containers are! May be it will be easier to demonstrate the benefits of proper design if you can show potential danger of doing otherwise?

[Russco]

I feel a need to defend myself for some reason.
In no way did I advocate mixing new with free. I merely stated that a particular compiler, in its particular version, might implement them the same way. And only then you pay no penalty for such major mistake.
As for the use of dynamic arrays or other dynamic memory allocations – I see a point in teaching those things. If for no other reason than to later point: and now see how much better STL containers are! May be it will be easier to demonstrate the benefits of proper design if you can show potential danger of doing otherwise?

Personally I think that STL use should be taught before dynamic allocation. Of course you need to learn both but why start with the more low level concept. Should we all learn asm before C++? No, of course not, however once you know C++ and start to look at how the compiler is translating your high level language to machine code, then and only then is a knowledge of assembly helpful. I view dynamic allocation the same way. I dont think you are ready to learn about that until you have at least become familiar with the higher level concepts. Look at the OP. He is messing with dynamic allocation and asks how to copy objects which surely is prerequisite knowledge. You must fully understand copying to get dynamic allocations right. Maybe learn about RAII before dynamic allocation too instead of the more normal other way around. Another analogy. Dont most people learn to drive before they learn car maintenance? Isn't this the same? How many drivers know exactly how the internal combustion engine works? Is that knowledge needed to drive?
The other benefit of doing things this way around is that most of the time when you would have been tempted into manual dynamic allocations, your first thought will now be to reach for a container class and so limiting the allocations made manually therefore in theory lessening the chances of bugs creeping in. Your code will naturally be easier to debug, well once you have learnt how to make sense of the error messages anyway.

[VladimirF]

Personally I think that STL use should be taught before dynamic allocation. Of course you need to learn both but why start with the more low level concept.

I respectfully disagree. Programmers who never used dynamic memory (and made mistakes) often do not understand why you need to reserve some space in a vector, for example. Just because you said so? Try to remember that!
Understanding how things work sure helps you in controlling them, even on a higher level.
Funny that you used a car example. I had a very similar argument with my older brother many years ago. My point is that if you know what (approximately) is going on when you step on a break, you’d have easier time understanding different breaking techniques.
Paraphrasing famous quote: understanding few principals relieves you from memorizing a lot of facts.

[Philip Nicoletti]

Stroustrup's take (see section 4) :

http://www.research.att.com/~bs/new_learning.pdf