[geos-devel] Re: Memory leak in RelateComputer?
mateusz at loskot.net
Wed May 7 23:37:19 EDT 2008
> It work very well, but I don't think that idea is good
> enough to solve this problem. For example, if I create a
> RelateComputer pointer and delete it immediately.
> RelateComputer* rc = new (RelateComputer);
> delete rc;
> rc = NULL;
> Does Memory leak ocurr?
Yes, it does, unfortunately.
> need I do this before the pointer destroyed?
> delete rc->computeIM(); // destroy the pointer im.
Yes, it needs to be destroyed explicitly.
> I don't think that codes are graceful.
I don't think either.
> So I still consider deallocate the matrix in its destructor is a betty way.
> "Who created, who destroyed"
> How do you think?
First, you should know that modifying a single class in GEOS is not that
easy as it seems. There are rich and complex relations between GEOS
types. I've not analysed this particular issue deeply, so I can't answer
how to solve it better.
However, there are a few solutions potentially possible:
1. Use lazy allocation of matrix, means to not allocate the matrix in
the RelateComputer ctor but to allocate it on request, when the computer
is asked for it.
2. Make RelateComputer an exclusive owner of the matrix, and destroy it
in the dctor. Then, RelateComputer could give access to immutable matrix
by reference to const (not pointer!).
3. Introduce shared ownership by wrapping the matrix object with smart
pointer implementing shared resource semantic (ie. boost::shared_ptr).
The 3rd option *seems* to fit best in this case.
I'm not eager to alter any patterns and semantics currently implemented
without a wider discussion. I think changes of that kind are serious and
should follow submission of Request For Comments (RFC) document,
discussed and voted by the GEOS PSC.
The PSC has just formed and we have not started up yet.
For now, we have to remember how to properly use RelateComputer to avoid
More information about the geos-devel