On Thu, 2 Oct 2003 11:44:04 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
RV> > In fact, we do have smart pointers :-) Look at MObject.h and RV> > DECLARE_AUTOPTR_XXX() macros. RV> RV> These macros cannot be used in headers, Sorry, why? I do use them in the headers (just do grep...), what's the problem? RV> This is because X_obj is class and it must be defined only once. As long as you do it in one header only, it's not a problem because all headers already have include guards. And it's logical to define Foo_obj together with Foo. RV> Plus it would be necessary to DEFINE_AUTOPTR in one file to work around RV> forward declarations. Indeed, these macros don't support fwd declarations (just as std::auto_ptr). Only boost::shared_ptr<> (or equivalent) would allow this RV> > True, not all the code uses them and we don't RV> > have a clear convention for the functions returning a pointer (they should RV> > return an auto ptr instead...). RV> RV> Simplest solution is to make return values the same type as members and RV> locals. Separate type could transfer ownership to save some IncRef/DecRef RV> pairs. Parameters can be bare pointers, because there is no way to destroy RV> source smart pointer without recursion. This is why I like shared_ptr<> so much. Then you can have some very simple rules: just replace "Foo *" everywhere with shared_ptr<Foo>. RV> So changes that I would want to make are (a) use templates, (b) allow RV> forward declarations, and (c) use separate type for return values. Only (b) RV> is essential to make smart pointers useful, but (a) and (c) make it better. Sorry, what do you mean by (c)? I agree that (b) would be nice (although not essential: you can use raw pointers as members as you don't risk to leak them -- there is just one DecRef() in dtor to add -- the smart pointers arem ore useful elsewhere, i.e. for the stack pointers) but I'm still worried about (a). We can try it but I think it would still be more prudent to start by rewriting DEFINE_AUTOPTR() using templates first and comparing the compile times. Also, please don't forget that I'm using VC6 which is not the best compiler from the point of view of template support... For example, I have written my own shared_ptr<> for it and I had to insert quite a few hacks to make it compile and a few more to make it work (it compiled ok but silently worked incorrectly...). Using templates is not unfortunately always simple. Anyhow, I surely don't have anything against trying to use them -- just please make sure that the changes cab be rolled back (i.e. tag the sources before your changes). RV> Gcc eats 100-1000 cycles per byte of code, including headers. I think it RV> has different performance problems than template instantiation. It can have both (or more...) problems at once :-/ Regards, VZ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
