I'm familiar with this requirement for a while now. In cl_test, we indeed always call close on Reader and Writer objects before deleting them.
On one hand, we should be following the Java behavior. If they always call close, we should always do as well. When having a reader object on the stack this is definitely how that should work. On the other hand, if calling close from the destructor is not a big deal (concurrency is the biggest impact I can think of right now) I guess it is better doing so than relying on a GC we don't have. Opinions anyone? Either way, it is definitely a good practice to always call close(). I'll check in this update now, thanks. Itamar. On 1/7/2010 4:21 PM, Kostka Bořivoj wrote: > I used VLD to trace the leaks. I found four real leaks, all related to > search. All caused by missing > reader->close() call in SearchFiles function. If I add > > reader->close(); > > just before > > _CLLDELETE(reader); > > all leaks disapears. > > I'm not sure if it should be considered as a bug in core or just bug in > cl_demo that close() should > be called before deleteing IndexReader. > > There is another strange set of leaks reported by crtdbg in MSVC debugging > environment, but > I think they are not real leaks (e.g. one of them contains "Time taken..." > string constant used > in final message) > > Borek > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > CLucene-developers mailing list > CLucene-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/clucene-developers > > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ CLucene-developers mailing list CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers
