Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Assignment operator self-assignment check

Reply
Thread Tools

Assignment operator self-assignment check

 
 
Jerry Coffin
Guest
Posts: n/a
 
      09-22-2006
In article <(E-Mail Removed). com>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...

[ ... ]

> With this context in mind "specified" means exactly which value will be
> returned by the operation and gives us some pretty clear rules about
> the layout of classes and arrays. Because the locations of a and b are
> not defined, in our case, the comparison of their address cannot be
> specified as has been clearly done with other cases. "Unspecified" in
> this case simply means that there is no way of knowing before hand what
> the return of that operation will be as there are no rules governing
> the relative locations of a and b; it doesn't mean it won't be a valid
> comparison which is what your interpretation is.


While the comparison is _valid_ (at least to the extent that it's
required not to crash the machine or something like that, like UB would
allow) it's not required to produce meaningful results. For example, it
could be unstable -- comparing the same pointers two different times
might produce different results.

As noted elsethread, however, std::less gives a total ordering even when
the native comparison operators don't.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
 
 
 
Jerry Coffin
Guest
Posts: n/a
 
      09-22-2006
In article <(E-Mail Removed) .com>,
(E-Mail Removed) says...

[ ... ]

> So does the equality operator. If two pointers represent the same
> address they compare equal. This of course will be governed by any
> necissary conversions to come up with the "composite pointer type."
>
> See 5.10.1


Quite true -- actually, I haven't followed the thread closely enough to
be sure how < entered it at all. OTOH, I can see situations where you're
writing a template that might deal with a pointer or an object, and in
that case I can see situations where you might want to determine
equality (or lack of it) based only on less-than, since a fair number of
ordered types only support less-than. Offhand, I'm not sure how that'd
apply specifically to the case of self-assignment though...

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
 
 
 
Noah Roberts
Guest
Posts: n/a
 
      09-22-2006

Jerry Coffin wrote:
> In article <(E-Mail Removed) .com>,
> (E-Mail Removed) says...
>
> [ ... ]
>
> > So does the equality operator. If two pointers represent the same
> > address they compare equal. This of course will be governed by any
> > necissary conversions to come up with the "composite pointer type."
> >
> > See 5.10.1

>
> Quite true -- actually, I haven't followed the thread closely enough to
> be sure how < entered it at all.


Yes, you would have to go back a few messages to figure that out. It
was a side mention that became the major issue.

> OTOH, I can see situations where you're
> writing a template that might deal with a pointer or an object, and in
> that case I can see situations where you might want to determine
> equality (or lack of it) based only on less-than, since a fair number of
> ordered types only support less-than.


Well, in cases when comparison of two pointers would actually be useful
it is fully specified. Even with std::less you can't tell if the two
pointers are actually related in some way since if they aren't then
their relative location is meaningless. I personally can't think of
any situation in which std::less would return a more meaningful value
than < even if you ran into some obscure implementation that didn't use
the address value for comparison in both cases. I also don't think
you'll ever find such an implementation as the other requirements
surrounding comparison are so strict as to not allow for any other
method I can think of.

At any rate, unspecified and undefined are totally different and I
don't dispute the unspecified nature of comparing unrelated
pointers...in fact that was really my point to begin with.

> Offhand, I'm not sure how that'd
> apply specifically to the case of self-assignment though...


It doesn't. This conversation lost track a long time ago

 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      09-22-2006

Jerry Coffin wrote:
> In article <(E-Mail Removed) .com>,
> (E-Mail Removed) says...
>
> [ ... ]
>
> > So does the equality operator. If two pointers represent the same
> > address they compare equal. This of course will be governed by any
> > necissary conversions to come up with the "composite pointer type."
> >
> > See 5.10.1

>
> Quite true -- actually, I haven't followed the thread closely enough to
> be sure how < entered it at all.


Yes, you would have to go back a few messages to figure that out. It
was a side mention that became the major issue.

> OTOH, I can see situations where you're
> writing a template that might deal with a pointer or an object, and in
> that case I can see situations where you might want to determine
> equality (or lack of it) based only on less-than, since a fair number of
> ordered types only support less-than.


Well, in cases when comparison of two pointers would actually be useful
it is fully specified. Even with std::less you can't tell if the two
pointers are actually related in some way since if they aren't then
their relative location is meaningless. I personally can't think of
any situation in which std::less would return a more meaningful value
than < even if you ran into some obscure implementation that didn't use
the address value for comparison in both cases. I also don't think
you'll ever find such an implementation as the other requirements
surrounding comparison are so strict as to not allow for any other
method I can think of.

At any rate, unspecified and undefined are totally different and I
don't dispute the unspecified nature of comparing unrelated
pointers...in fact that was really my point to begin with.

> Offhand, I'm not sure how that'd
> apply specifically to the case of self-assignment though...


It doesn't. This conversation lost track a long time ago

 
Reply With Quote
 
S S
Guest
Posts: n/a
 
      09-26-2006

Kai-Uwe Bux wrote:
> S S wrote:
>
> >
> > Kai-Uwe Bux wrote:
> >> Chris wrote:
> >>
> >> > Is there ever a reason to declare this as
> >> >
> >> > if(*this == rhs)
> >> >
> >> > as opposed to what I normally see
> >> >
> >> > if(this == &rhs)
> >> >
> >> > ?
> >> >
> >> > Seems like the former version is going to be more expensive rather than
> >> > simply comparing addresses as in the latter (plus the former requires
> >> > the class to define operator== as well, no?). Wondering if that added
> >> > effort is ever justified.
> >>
> >> I think a reference counted non-intrusive smart pointer could benefit
> >> from the first version. Consider the following schematic implementation:
> >>
> >> template < typename T >
> >> class refcount_ptr;
> >>
> >> template < typename T >
> >> void swap ( refcount_ptr< T > &, refcount_ptr< T > & );
> >>
> >> template < typename T >
> >> class refcount_ptr {
> >>
> >> friend void swap<> ( refcount_ptr<T> &, refcount_ptr<T> & );
> >>
> >> struct T_count {
> >>
> >> T* t_ptr;
> >> unsigned long ref_count;
> >>
> >> T_count ( T * ptr )
> >> : t_ptr( ptr )
> >> , ref_count ( 1 )
> >> {}
> >>
> >> ~T_count ( void ) {
> >> delete ( t_ptr );
> >> }
> >>
> >> };
> >>
> >> T_count * c_ptr;
> >>
> >> public:
> >>
> >> refcount_ptr ( T * ptr = 0 )
> >> : c_ptr( new T_count ( ptr ) )
> >> {}
> >>
> >> refcount_ptr ( refcount_ptr const & other )
> >> : c_ptr ( other.c_ptr )
> >> {
> >> ++ c_ptr->ref_count;
> >> }
> >>
> >> ~refcount_ptr ( void ) {
> >> -- c_ptr->ref_count;
> >> if ( c_ptr->ref_count == 0 ) {
> >> delete( c_ptr );
> >> }
> >> }
> >>
> >> refcount_ptr & operator= ( refcount_ptr const & other ) {
> >> if ( c_ptr != other.c_ptr ) {
> >> this->~refcount_ptr();
> >> new ( this ) refcount_ptr( other );
> >> }
> >> return( *this );
> >> }
> >>
> >> T const * operator-> ( void ) const {
> >> return( c_ptr->t_ptr );
> >> }
> >>
> >> T * operator-> ( void ) {
> >> return( c_ptr->t_ptr );
> >> }
> >>
> >> // more stuff
> >>
> >> };
> >>
> >> In this case, the additional cost of the comparison could be zero: the
> >> refcount_ptr objects fit within registers. It might very well be that
> >> comparing the values of the c_ptr members is more efficient than
> >> comparing their addresses. On the other hand, the value comparison will
> >> safe on hidden self-assignments, which actually could be quite frequent
> >> depending on the application.
> >>
> >>
> >> Best
> >>
> >> Kai-Ue Bux

> >
> > You mean we have to inherit from this class?

>
> No. What made you think that?
>
> Note refcount_ptr<T> is just a watered down version of tr1::shared_ptr<T>
> for the sake of exposision: It does not feature a custom deleter and I left
> out the methods like operator<, operator==, ...; and I also did not support
> for making refcount_ptr<D> and refcount_ptr<T> assignment compatible it D*
> and T* are. However, the intended use is just like tr1::shared_ptr<T>, in
> particular, you are not meant to inherit from refcount_ptr<T>.
>
>
> > If yes, we can hung up with multiple inheritance!!! and this might not be
> > desirable solution at all.

>
> What would be wrong with multiple inheritance?


In industry practice, it is always recommended not to use multiple
inheritance at any cost. It will lead to ambiguous code (virtual
functions).

>
>
> Best
>
> Kai-Uwe Bux


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
POD and assignment operator and test operator Hicham Mouline C++ 2 09-01-2009 06:00 PM
conditions for automatic generation of default ctor, copy ctor,and default assignment operator (operator) puzzlecracker C++ 8 04-15-2008 09:56 PM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
comma operator and assignment operator G Patel C Programming 4 02-08-2005 02:53 AM
Beanshell - assignment operator not working? Wolfgang Groiss Java 0 11-19-2003 03:56 PM



Advertisments