Let me take "smart-temporary" class _dgematrix for example. I understand _dgematrix as a class to store "intermediate" data during the calculation of a formula. For example, to calculate X = A*B+C, A*B is stored in an array in a _dgematrix object, say T, and T+C is stored essentially in the same array. This array will be given to X.
The memory leak occurs when someones calls without an "=", like "A*B+C;" or "func(A*B+C);". In both cases, the array in the _dgematrix object is NOT destroyed.
So far, I see in the code that the array in a _dgematrix object is either transfered to a dgematrix object or destroyed in some cases when the host _dgematrix object is involved in a calculation. There needs a special flag in the deconstructor of the _dgematrix class to tell whether the array should be explicately destroyed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>"A*B+C;" or "func(A*B+C);". In both cases, the array in the _dgematrix object is NOT destroyed.
In case of "func(A*B+C);", there are basically no memory leak unless the func returns a CPPL objects, I believe. If the func is "dgematrix func([whatever])", there must be a memory leak.
>There needs a special flag in the deconstructor of the _dgematrix class to tell whether the array should be explicately destroyed.
CPPLapack released in 2003 uses a kind of flag for the judgment of temporary objects. We called it "to_return system". Being inelegant, the system comes with a lot of forbidden codes...
We have been thinking about a nice system to eliminate the forbidden codes, but good idea havn't come. Please check cpplapack-2003_10_20.tar.gz out and brush it up.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The cause of the problem in "to_return system" seems that an object (such as dgematrix) releases its ownership of the pointer (i.e. array) without assuring another object acquires the ownership. But it can be improved by minor modification.
Use to_return member variable to indicate that an object is ready to release its ownership of the pointer. Do not use to_return variable to determine if the memory pointed by array should be deleted in the destructor. Instead, delete the memory whenever array is non-null. When to transfer ownership of the pointer from one object to another, let the former object know the pointer ownership is acquired by the latter by setting array of the former to be NULL. Sample code is: http://lss.mes.titech.ac.jp/~iaimf/src/main.cpp http://lss.mes.titech.ac.jp/~iaimf/src/mat.hpp http://lss.mes.titech.ac.jp/~iaimf/src/Makefile
(in which to_return is renamed to hold.)
This modification does not suffer the forbidden codes in CPPLapack released in 2003. The code assures only one object owns a pointer at a time, and thus no memory left un-destroyed. Also it is possible to give users the ability to control the hold variable. See the following code in which memory assigned to A is overwritten. Without A.hold=false, extra memory for a temporary object would be required.
vec A(3);
vec B(3);
vec C(3);
A.hold = false;
C = A + B;
Also note, in the sample code, the copy constructor initially set hold true. Maybe it is good to inherit the value of hold when copying.
Comments?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Appending the following code after the declaration of "D" in your main.cpp, I got "D.hold=0" although D.hold should be 1.
std::cout << "D.hold=" << D.hold << std::endl;
I think this is the critical problem of "hold system" and "to_return system".
We can easily override the copy constructor to get D.hold=1 for this case. But if we do so, the temporary object created in operator + is also set as a hold object as well. This is the main reason that I gave up "to_return" system.
Is there any good idea to overcome this problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me take "smart-temporary" class _dgematrix for example. I understand _dgematrix as a class to store "intermediate" data during the calculation of a formula. For example, to calculate X = A*B+C, A*B is stored in an array in a _dgematrix object, say T, and T+C is stored essentially in the same array. This array will be given to X.
The memory leak occurs when someones calls without an "=", like "A*B+C;" or "func(A*B+C);". In both cases, the array in the _dgematrix object is NOT destroyed.
So far, I see in the code that the array in a _dgematrix object is either transfered to a dgematrix object or destroyed in some cases when the host _dgematrix object is involved in a calculation. There needs a special flag in the deconstructor of the _dgematrix class to tell whether the array should be explicately destroyed.
ADD:
"Darray" in the _dgematrix class should also have the same leak problem.
>"A*B+C;" or "func(A*B+C);". In both cases, the array in the _dgematrix object is NOT destroyed.
In case of "func(A*B+C);", there are basically no memory leak unless the func returns a CPPL objects, I believe. If the func is "dgematrix func([whatever])", there must be a memory leak.
>There needs a special flag in the deconstructor of the _dgematrix class to tell whether the array should be explicately destroyed.
CPPLapack released in 2003 uses a kind of flag for the judgment of temporary objects. We called it "to_return system". Being inelegant, the system comes with a lot of forbidden codes...
We have been thinking about a nice system to eliminate the forbidden codes, but good idea havn't come. Please check cpplapack-2003_10_20.tar.gz out and brush it up.
Thank you.
The cause of the problem in "to_return system" seems that an object (such as dgematrix) releases its ownership of the pointer (i.e. array) without assuring another object acquires the ownership. But it can be improved by minor modification.
Use to_return member variable to indicate that an object is ready to release its ownership of the pointer. Do not use to_return variable to determine if the memory pointed by array should be deleted in the destructor. Instead, delete the memory whenever array is non-null. When to transfer ownership of the pointer from one object to another, let the former object know the pointer ownership is acquired by the latter by setting array of the former to be NULL. Sample code is:
http://lss.mes.titech.ac.jp/~iaimf/src/main.cpp
http://lss.mes.titech.ac.jp/~iaimf/src/mat.hpp
http://lss.mes.titech.ac.jp/~iaimf/src/Makefile
(in which to_return is renamed to hold.)
This modification does not suffer the forbidden codes in CPPLapack released in 2003. The code assures only one object owns a pointer at a time, and thus no memory left un-destroyed. Also it is possible to give users the ability to control the hold variable. See the following code in which memory assigned to A is overwritten. Without A.hold=false, extra memory for a temporary object would be required.
vec A(3);
vec B(3);
vec C(3);
A.hold = false;
C = A + B;
Also note, in the sample code, the copy constructor initially set hold true. Maybe it is good to inherit the value of hold when copying.
Comments?
Sorry for my late reply. Let me ask a question.
Appending the following code after the declaration of "D" in your main.cpp, I got "D.hold=0" although D.hold should be 1.
std::cout << "D.hold=" << D.hold << std::endl;
I think this is the critical problem of "hold system" and "to_return system".
We can easily override the copy constructor to get D.hold=1 for this case. But if we do so, the temporary object created in operator + is also set as a hold object as well. This is the main reason that I gave up "to_return" system.
Is there any good idea to overcome this problem?
The anonymous comment at 2006-03-11 02:45 is by me.