Matthias Troyer-2 wrote:
On 16 Sep 2009, at 10:38, ruya wrote:
SType is not a SearchFunctor. It is a template parameter of SearchFunctor. Look, I am not a professional coder or something. I could accept that my code has memory leaks, except that I monitored the memory usage and it is stable and quite small too. I have three other algorithms using the same SearchFunctors and the behavior is as expected and no memory leaks. As for the complication that my code appears to be to you, how would you simplify it? You argued before that you would do it diferently and avoid for sure the segmentation fault.
SearchFunctor(){ memh = MemHandler(); generator1 = base_generator_type(MASTER_SEED+13); uni_dist1 = boost::uniform_real<>(0,1); uniEmp = new GeneratorI(generator1, uni_dist1); generator2 = base_generator_type(MASTER_SEED+17); uni_dist2 = boost::uniform_real<>(0,1); uniRes = new GeneratorI(generator2, uni_dist2); } protected: virtual ~SearchFunctor(){}
Just look at this code fragment: you allocate memory in the constructor using new and never release it using delete
I probably don't see this leak in the memory usage because only a limited
amount of SearchFunctors are created at the beginning and they live for as
long as the program runs. (I think this makes sense)
Anyhow, writing the proper destructors doesn't solve my problem, but now gdb
points to immediatly before the creation of any of the SearchFunctors. So,
to remember, I have three SearchFunctors (SFs). In three different
applications the three of them work as expected. In this particular app, the
SFs were successfully created, then two ran well, and one would give a seg
fault. Now, with the proper destructor in class SearchFunctor, the fault
comes at the time of creation. gdb points to the line where the following
functions is called:
functors = vector<SearchF>();
TL2FunV