Printable View
Hi. Suppose u have the following function:
If i call the above function in main like this:Code:int *temp(int n){
int i;
int *array = new int[n];
for (i=0;i<n;i++)
array[i] = i;
return array;
}
4Mbytes of memory are allocated, even though the result of temp() is not returned to another pointer. Why? Can I "free" that memory?Code:temp(1000000);
Thanx
try the following command:
new int[1000];
new doesn't care what you are doing with the return pointer,
it does what it suppose to do: allocate and return start memory address...
if you don't keep the pointer to that allocation, you can't free it.
Thanx guysl. What if I call that function in another function? Shouldn't all the memory allocated in a function been free after the funcion has finished?
e.g.
void newFunction()
{
temp(1000000);
}
not with memory allocated on the heap with new/malloc.
stack objects get free on end of scope.
dynamic allocated memory gets free by explicit delete/free.
:( I was afraid that...Quote:
Originally posted by Guysl
not with memory allocated on the heap with new/malloc.
stack objects get free on end of scope.
dynamic allocated memory gets free by explicit delete/free.
The problem is that I have some functions for signal processing like:
fft(Array)
abs(Array)
xcorr(Array)
where Array is a class I've defined. All of those functions return an object to Array. Also, I've overloaded some operators. So if I write:
So fft(A2) returns an Array which is divided (by using the overloaded operator /) by sum(A2). The result is returned to A1 but fft(A2) (intermediate retult) is returned no-where, so as u told me can't be free... :mad:Code:Array A1;
Array A2;
....
....
A1 = fft(A2)/sum(A2);
....
Thanx for your answers...
Bye
well, it seems that destructor, copy c'tor and operator=
are essential in your case.
Why not use a std::vector?This way the returned array will be deallocated automatically if you don't do anything with it.Code:std::vector<int> temp(int n){
int i;
std::vector<int> array(n);
for (i=0;i<n;i++)
array[i] = i;
return array;
}
I've explained in another thread why I don't use vector class. I want some extra features and I want a class created by me, not overloaded or sth else. Anyway, the class's fields are:
And the constructor is:Code:private:
double *data;
int size;
and the destructor:Code:ArrayD::ArrayD()
{
// constructor 1:
ArrayD::size = 0;
ArrayD::data = NULL;
}
ArrayD::ArrayD(int size)
{
// constructor 2:
ArrayD::size = size;
ArrayD::data = new double[size];
}
ArrayD::ArrayD(int size,const double p[])
{
// constructor 3:
int i;
ArrayD::size = size;
ArrayD::data = new double[size];
for (i=0;i<ArrayD::size;i++)
ArrayD::data[i] = p[i];
}
Any suggestions on the above code? Should the destructor be different??Code:ArrayD::~ArrayD()
{
delete [] data;
}
Thanx...
First, I'd use initialisations instead of code body, e.g.
Although you won't notice it on consturctors of this size, it's good practice and for complex classes you might notice a performance gain.Code:ArrayD::ArrayD()
: size(0),
data(NULL)
{
}
// etc
Also, I think you need to check that the array has been allocated in the destuctor before delete'ing it:
Lastly, you don't need to specifiy the scope of your variables inside the class's body - so constructor 3 could becomeCode:ArrayD::~ArrayD()
{
if (data)
delete [] data;
}
TootCode:ArrayD::ArrayD(int nSize, const double* pData)
: size(nSize),
data(new double[nSize])
{
// constructor 3:
if (data)
{
for (int i = 0; i < nSize; i++)
data[i] = pData[i];
}
}
What are these "extra features" for why you can't use vector? It would solve all of your problems and make your code more maintainable.Quote:
Originally posted by yiannakop
I've explained in another thread why I don't use vector class. I want some extra features and I want a class created by me, not overloaded or sth else.
Your class has a member that is a pointer to dynamic memory, but ArrayD has no assignment operator or copy constructor. It will fail this simple test:
If you are not aware of why your class fails this simple test, or how to write a copy constructor or op =, then IMO this is more a reason why you should use C++ containers. The people who wrote the std::vector code worked pretty hard at it so as to make your coding easier to handle. Usage of containers would make your class copyable and assignable without writing a user-defined copy constructor and operator = (and destructor).Code:int main()
{
ArrayD a(10);
ArrayD b = a; // copy construction (trouble)
ArrayD c;
c = a; // assignment (trouble)
} // destruction ( deletion error! )
Regards,
Paul McKenzie
I'm a little confused as to what the actual situation you
have is. In your first post, you are returning a pointer
to new'ed memory. In a later post, you say you are
returning an OBJECT of type Array (or ArrayD ?).
If you are returning and object, you should be OK
(assuming the copy-ctor etc. are coded correctly).
I think he's creating pointers-to-ArrayD and passing those to the functions and each function creates new ArrayD objects and returns there pointer.
Instead of passing a pointer, how about passing-by-reference and maybe return-via-reference instead?
Then he needs the copy/assignment to be coded and work correctly. That's the problem with pointers -- you never know that your class is really full of bugs until you start to copy and assign instances of your classes. Exclusive usage of pointers hides all of these memory bugs.Quote:
Originally posted by cma
Instead of passing a pointer, how about passing-by-reference and maybe return-via-reference instead?
That's the price you pay when your object contains pointers to dynamic memory, you now have the "luxury" of writing more code to make your class behave properly (which means more code to maintain, get wrong, etc.). I wished that would be emphasized by more C++ books and tutorials. New C++ programmers would then start to appreciate container classes instead of usage of raw pointers.
Regards,
Paul McKenzie