On Fri, 10 Oct 2003 00:18:23 +0200 (Romance Daylight Time) Vadim Zeitlin <[EMAIL PROTECTED]> wrote:
> is not necessary to use RefCounter at all, you don't [have to] do any > Inc/DecRef()s on mApplication->GetProfile() anyhow. But then this should be changed (someday). Otherwise somebody will write code like "RefCounter<Profile> profile(mApplication->GetProfile())", which is correct in other cases, but not for global profile. > A decent compiler should optimize passing such small object > (sizeof(RefCounter) == sizeof(void *)) by value but I doubt gcc does it... I am not sure what sort of waste are you referring to. I am talking about IncRef and DecRef calls that surround each function call that takes RefCounter as parameter. There is no way to optimize them out, because compiler doesn't know whether reference count will be used inside the function or not and it doesn't know whether reference count reaches zero or not after return. > So it could be a tiny bit wasteful but unless you call such function in an > inner loop I can't imagine it can be noticeable. It will be noticeable in code size though. > On Thu, 9 Oct 2003 19:07:40 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote: > > RV> Do you have any example when can such conversion be dangerous? > > Everywhere. This simply negates the gains from the smart pointers. When > you use the smart pointers, whatever you do, the obejcts are deleted (or > not) correctly. When you implicitly convert them to raw pointers and pass > them to a function which may take ownership of its parameter, you break the > smart pointer invariant -- the object may be deleted while the smart > pointer still exists. It is possible to use different types for members, locals, parameters, and return values. We can differentiate them later, of course. > RV> > I'd also like to remove > RV> > AttachAndIncRef() because IMHO it is confusing and thus dangerous to have > RV> > ctor which takes ownership of the pointer and a function which doesn't (if > RV> > we decide to keep it I think to something like CopyFrom() makes more sense > RV> > as a name for it, but this is a minor issue). > RV> > RV> Name CopyFrom doesn't tell you who is supposed to call IncRef. I thought > RV> about complementary AttachIncRefed that would make naming logical, but I > RV> didn't need it yet. Any name is acceptable as far as it is too long to > RV> write easily and it is clear who should call IncRef. > > As I said, the best would be to remove it entirely... Are we going to need > it often? One can always work it around with constructor like this: T * source; RefCounter<T> destination; // exists already source = (copy from somewhere); source->IncRef(); RefCounter<T> temporary(pointer); destination = temporary; But it's a bit ugly and lenghty. It will be unnecessary when all pointers are in RefCounter, but that will never really happen. ------------------------------------------------------- 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
