Memory Allocation

[yiannakop]

Hi. Suppose u have the following function:

int *temp(int n){
  int i;
  int *array = new int[n];
     for (i=0;i<n;i++)
   array[i] = i;
  return array;
}

If i call the above function in main like this:

temp(1000000);

4Mbytes of memory are allocated, even though the result of temp() is not returned to another pointer. Why? Can I "free" that memory?
Thanx

[Guysl]

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.

[yiannakop]

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);
}

[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.

[yiannakop]

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.

I was afraid that...
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:

Array A1;
Array A2;
....
....
A1 = fft(A2)/sum(A2);
....

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...
Thanx for your answers...
Bye

[Guysl]

well, it seems that destructor, copy c'tor and operator=
are essential in your case.

[Assmaster]

Why not use a std::vector?

std::vector<int> temp(int n){
  int i;
  std::vector<int> array(n);
     for (i=0;i<n;i++)
   array[i] = i;
  return array;
}

This way the returned array will be deallocated automatically if you don't do anything with it.

[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. Anyway, the class's fields are:

private:
  double *data;
  int size;

And the constructor is:

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];	
}

and the destructor:

ArrayD::~ArrayD()
{		
  delete [] data;
}

Any suggestions on the above code? Should the destructor be different??
Thanx...

[Toot]

First, I'd use initialisations instead of code body, e.g.

ArrayD::ArrayD()
: size(0),
  data(NULL)
{
}
// etc

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.

Also, I think you need to check that the array has been allocated in the destuctor before delete'ing it:

ArrayD::~ArrayD()
{
    if (data)
        delete [] data;
}

Lastly, you don't need to specifiy the scope of your variables inside the class's body - so constructor 3 could become

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];
    }
}

Toot

[Paul McKenzie]

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.

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.

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:

int main()
{
   ArrayD a(10);
   ArrayD b = a;  // copy construction (trouble)
   ArrayD c;
   c = a;   // assignment (trouble)
}  // destruction  ( deletion error! )

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).

Regards,

Paul McKenzie

[Philip Nicoletti]

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).

[cma]

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?

[Paul McKenzie]

Originally posted by cma
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.

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