On Thu, 9 Oct 2003 19:07:40 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
RV> On Thu, 9 Oct 2003 16:22:11 +0200 (Romance Daylight Time) Vadim Zeitlin
RV> <[EMAIL PROTECTED]> wrote:
RV>
RV> > as I couldn't build M after updating from the cvs today using VC6 I had to
RV> > look at pointers.h and, as you might have noticed, this resulted in some
RV> > changes.
RV>
RV> Damnit, I have been just doing significant changes.
Sorry, I thought you were done with RefCounter.
RV> > Second, I removed implicit conversions of RefCounter<T> to "T *" and to
RV>
RV> This breaks build (in wxSpamOptions.
Sorry again, I forgot to check it in (done now).
RV> The implicit conversion is used to pass RefCounter as parameter to
RV> function that expects bare pointer. Do you mean that we should use
RV> RefCounter in function parameters?
For new code I think this is the best solution. For the old code we should
be using Get() in the meantime. In the particular case of wxSpamOptions, it
is not necessary to use RefCounter at all, you don't [have to] do any
Inc/DecRef()s on mApplication->GetProfile() anyhow.
RV> That's no problem for me, but I thought it's a bit wasteful.
A decent compiler should optimize passing such small object
(sizeof(RefCounter) == sizeof(void *)) by value but I doubt gcc does it...
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.
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.
Of course, you can also call smartPtr->DecRef() too and I'd like to find a
way to forbid this. But at least forcing you to write Get() before passing
the pointer to a function will hopefully make you think of whether you're
doing the correct thing while doing it implicitely will surely never do
that.
There are also weird arithmetic operations on pointers (similar to the
example below) which become allowed if you authorize the implicit
conversions. I'm sorry but I really don't have time to invent realistic
examples, please look in any C++ book (Sutter for example, Alexnadrescu
also has a nice discussion of this).
It is surely more convenient to have the implicit conversions and I used
to love them but not having them makes the code more solid and now I think
it is well worth it.
RV> > "bool". This is by far too dangerous and, especially with the bool one,
RV> > quite unnecessary -- there is a nice trick to avoid having it without
RV> > losing the ability to write code as if it were there, have a look at
RV> > unspecified_bool_type definition (shamelessly stolen from boost).
RV>
RV> Do you have any example of such dangerous conversion?
You'd be able to write for any T1 and T2:
RefCounter<T1> p1;
RefCounter<T2> p2;
if ( p1 == p2 )
...
without any warnings, let alone errors, from the compiler. It's dangerous
that the code compilers but doesn't do at all what you can expect it to do.
You can try to work around this by defining operator==() as well but there
are obviously many other places where implicit conversion to bool (and
hence to int via promotion) gets into way.
RV> > Fourth, I've inlined all the functions you had because they were not
RV> > inlined before (you'd have to define them before hte point of use for this
RV> > to happen
RV>
RV> Good to know that such rule exists.
I'm not sure I understand this but such rule (that inlined function must
be visible at the point of use in order to be effectivaly inlined)
definitely exists, both in theory and practice.
RV> > but in this particular case I really don't see any point in
RV> > having them at all).
RV>
RV> I wrote it that way because gdb cannot place breakpoint into operator and
RV> sometimes not even constructor. :-( Sure it's silly and gdb should be
RV> fixed. They are working on it AFAIK.
gdb is quite bad with C++ in general, indeed... But I think you still can
place breakpoints even in those places by explicitly specifying the line
number and the file name. Doesn't it work?
RV> > I'd also like to inline RefCounterIncrement/...()
RV> > functions, I see no reason for hiding them in MObject.cpp, everybody
RV> > includes MObject.h anyhow.
RV>
RV> There are two sets of RefCounter* functions: one is for MObjectRC and the
RV> other is defined for each class using DEFINE_REF_COUNTER. Which one do you
RV> mean? Inlining the latter doesn't make sense, because their point is to
RV> hide upcasting that requires complete type. Inlining the former is of
RV> questionable value, because functions from DEFINE_REF_COUNTER will have
RV> precedence. Inlining the former into the latter would just cause code
RV> bloat. Currently (I hope that) the latter functions get compiled into
RV> simple jump to the former functions.
RV>
RV> > I'd like to ask you to do the same changes for AutoPtr which I didn't have
RV> > time to fix
RV>
RV> I'll look at it.
Thanks!
RV> > Also, I'd like to rename it to ScopedPtr because this is what it is
RV> > and calling it AutoPtr is just too confusing.
RV>
RV> That's OK, although I selected that name because it is mostly
RV> std::auto_ptr.
But it is not auto_ptr in the most crucial aspect -- that of copying
semantics. When I see something called AutoPtr I know, almost at
subconscious level, that I should take care when passing them around to not
invalidate the existing objects and so on. Here I don't have to worry about
this.
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?
Thanks,
VZ
-------------------------------------------------------
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
