Thank you guys. This doesn't have to change any class interface, or interfere with inheritance. If you keep the way classes are currently implemented, and add another h file with those typedefs for all major classes in CLucene, people using previous versions can choose if and when to adopt the new way of doing things, and derived, custom-coded classes would not suffer from it. If their author would like to use a similar implementation, it's only 3 typedefs ahead (in most cases even less). Obviously, those typedefs can also reside within the original classes, but I'd consider it more intrusive. Perhaps only for classes where we will use smartpointers for them also internally.
I agree a strong transition to smartpointers will dramatically improve many things in CLucene, and I'm a real fan of the idea. However, recognizing the man-power required for the job, I would really like to limit this to only places where it is needed. That means building a good basis (hence this RFC), and then refactoring only several parts of the core. I guess the only remaining question now is who's willing to contribute some time for it? As it seems now, this isn't a big task, but definitely one that is capable of making a huge difference for everyone. -- Henning - we are using std::string within the core. We only use C-Strings on places where the string operations are being done repeatedly or are really simple and do not require the overhead of std::string. Indeed, that's mostly for historic reasons, but I think it does worth to keep it this way, we just need to make sure all fail-safes are in place (the cl_snprintf macros etc). --- Itamar. -----Original Message----- From: Veit Jahns [mailto:nuncupa...@googlemail.com] Sent: Monday, December 14, 2009 1:02 PM To: clucene-developers@lists.sourceforge.net Subject: Re: [CLucene-dev] [RFC] Memory management in CLucene Hi all! 2009/12/11 Henning Meyer <tutm...@gmail.com>: > Q1: As general suggestion I'd propose an approach I've learned from > ITK (www.itk.org). There they provide a typedef: SomeITKClass::Pointer > with each class. So I'd propose to define types like Term::ScopedPtr, > Term::AutoPtr, Term::SharedPtr and Term::WeakPtr for each major Object > in CLucene. These types can then be used internally as well as externally. In my point of view a sound approach. But this will change the class interfaces as well as method signatures (Or do I miss something?). Users with own implementations of CLucene parts, e.g. query parser, have to adapt their code. In this case some wrappers or guidance to support the migration from raw pointer code to smart pointer code will be useful. > Q2: Overall I'd recommend to get rid of all raw pointers in the long > run. With boost::scoped_ptr and std::auto_ptr C++ offers two Pointer > types with almost no performace issues. You might think there is > little gain from using these, but at a closer look you'll recognize > you get various syntactic checks and proper resource handling in case > of exceptions for free. > When it comes to reference counts I agree with Itamar and go for > boost::shared_ptr and boost::weak_ptr. I prefer smart pointers too. Managing pointers fault-prone task and "atomization" with smart pointers can reduce error frequency of the code. But on the other side, I agree with Itamar, that for a transitional time smart pointers should be only used where problems occur or new functions are implemented. Moving all raw pointers to smart pointers will is in my opinion a complete new task (and should be considered in an new release cycle?). Kind regards, Veit ---------------------------------------------------------------------------- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ CLucene-developers mailing list CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ CLucene-developers mailing list CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers
