On Thu, 9 Oct 2003 16:22:11 +0200 (Romance Daylight Time) Vadim Zeitlin <[EMAIL PROTECTED]> wrote:
> as I couldn't build M after updating from the cvs today using VC6 I had to > look at pointers.h and, as you might have noticed, this resulted in some > changes. Damnit, I have been just doing significant changes. I resolved conflicts and checked in WeakRef, which will get into usable state later. > First of all, I documented the class. I know that we don't generate > doxygen docs regularly right now but this is really not an excuse to not > write comments for the new code. Yes, RefCounter deserves more attention. > Second, I removed implicit conversions of RefCounter<T> to "T *" and to This breaks build (in wxSpamOptions.cpp). The implicit conversion is used to pass RefCounter as parameter to function that expects bare pointer. Do you mean that we should use RefCounter in function parameters? That's no problem for me, but I thought it's a bit wasteful. Do you have any example when can such conversion be dangerous? > "bool". This is by far too dangerous and, especially with the bool one, > quite unnecessary -- there is a nice trick to avoid having it without > losing the ability to write code as if it were there, have a look at > unspecified_bool_type definition (shamelessly stolen from boost). Do you have any example of such dangerous conversion? > Fourth, I've inlined all the functions you had because they were not > inlined before (you'd have to define them before hte point of use for this > to happen Good to know that such rule exists. > but in this particular case I really don't see any point in > having them at all). I wrote it that way because gdb cannot place breakpoint into operator and sometimes not even constructor. :-( Sure it's silly and gdb should be fixed. They are working on it AFAIK. > I'd also like to inline RefCounterIncrement/...() > functions, I see no reason for hiding them in MObject.cpp, everybody > includes MObject.h anyhow. There are two sets of RefCounter* functions: one is for MObjectRC and the other is defined for each class using DEFINE_REF_COUNTER. Which one do you mean? Inlining the latter doesn't make sense, because their point is to hide upcasting that requires complete type. Inlining the former is of questionable value, because functions from DEFINE_REF_COUNTER will have precedence. Inlining the former into the latter would just cause code bloat. Currently (I hope that) the latter functions get compiled into simple jump to the former functions. > I'd like to ask you to do the same changes for AutoPtr which I didn't have > time to fix I'll look at it. > Also, I'd like to rename it to ScopedPtr because this is what it is > and calling it AutoPtr is just too confusing. That's OK, although I selected that name because it is mostly std::auto_ptr. > I'd also like to remove > AttachAndIncRef() because IMHO it is confusing and thus dangerous to have > ctor which takes ownership of the pointer and a function which doesn't (if > we decide to keep it I think to something like CopyFrom() makes more sense > as a name for it, but this is a minor issue). Name CopyFrom doesn't tell you who is supposed to call IncRef. I thought about complementary AttachIncRefed that would make naming logical, but I didn't need it yet. Any name is acceptable as far as it is too long to write easily and it is clear who should call IncRef. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
