Re: AutoPtr::operator == : Is it defined the correct way ??


Not Exactly. How about the comparision operator over strings (which are
nothing but wrappers around char* pointers) ? Do we compare the internal
char* pointers or their content?

Well, no. Strings are strings, pointers are pointers, value types are value
types. Regardless their wrapper object. That's how I think about them and
the needed operation of comparing.

Or what would you suggest for a CComPtr<...>::operator == (const
CComPtr<...>& ptr) to do? CAutoPtr is basically CComPtr with only one
reference allowed at the same time. They could have been implemented as one
single class even, with some const int template argument for the refcount.
Would you not implement a value equality check (say we have a common
ICompare interface what every comparable object implements) just because it
allows multiple references to the same pointer, and in this case it is
meaningful to do the comparision of the addresses? I think what you are
suggesting is use the otherwise meaningless operator == to something else
because it comes handy in some way.

MyClass::UnSubscribe(CAutoPtr<IEventFunctor>& spFunc)
{
POSITION pos = m_List.Find(spFunc);
if(pos)
m_List.RemoveAt(pos);
}

There is nothing wrong with the above code semantically - but it simply

I think there is!

Let's say you cannot afford the luxury to use CAutoPtr and have to use good
old pointers and m_List is just a CAtlList<IEventFunctor*>.

MyClass::UnSubscribe(IEventFunctor* spFunc)
{
POSITION pos = m_List.Find(spFunc);
if(pos)
{
delete m_List.GetAt(pos);
m_List.RemoveAt(pos);
}
}

Will this code work? No. For the same reason.

To my opinion such rewrite of any code which uses CAutoPtr must be possible
vica-versa. Redefining operator == destroys this symmetry between pointers
and auto pointers.

if CAutoPtr never defined its operator==. Becuase, that would force the
developers not to use Find() on the CAutoPtrList. Being unaware, I used
it -

Maybe CAutoPtrList shouldn't have an public Find function in the first place
:)

and the system went wrong, and it took to me somewhile to realize what is
going on.

Sure because you thought it compares the value, but this would have never
occured to me and I might got tricked by the opposite if it was working like
that.


.

Relevant Pages

  • Re: AutoPtr::operator == : Is it defined the correct way ??
    ... nothing but wrappers around char* pointers)? ... Do we compare the internal ... Let's say you cannot afford the luxury to use CAutoPtr and have to use good ... Here is some a snippet from that file for your reference. ...
    (microsoft.public.vc.atl)
  • Re: String Comparision
    ... code which would compare two strings using pointers. ... On tracing the program i noticed that the strings "s" and "t" get modified somehow in the comp function and as a result i am getting incorrect results. ... He needs to test for at least one of the pointers being 0 in the loop ... And he should change the subtraction, if only for pedagogical reasons, ...
    (comp.lang.c)
  • Re: AutoPtr::operator == : Is it defined the correct way ??
    ... Simply don't use CAutoPtr and everybody will ... nothing but wrappers around char* pointers)? ... Do we compare the ... May be that was the reason you were asking my suggestion of what would I ...
    (microsoft.public.vc.atl)
  • Re: Array comparison
    ... pointers are only going to compare their object pointers ... pointers and not the contents of the strings. ... things like array of Char, bytes, words, dword, int64's etc.. ...
    (alt.comp.lang.borland-delphi)
  • Re: storage for temporaries
    ... >> Netocrat wrote: ... >> allegedly have no pointers to ojbects!). ... I suppose it is unclear how to compare ... pointers on a system that doesn't have a flat memory model. ...
    (comp.lang.c)