Re: compare two structs via ==

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote:
On Thu, 07 Jun 2007 11:37:47 -0700, Jon Skeet [C# MVP] <skeet@xxxxxxxxx>
wrote:

but you *overload* the == operator by providing different signatures,
eg
bool operator ==(string x, string y)
bool operator ==(DateTime x, DateTime y)

You seem to be in agreement with me. Mark's claim was that it's only
"overloading" when the types are different. However, both of your
examples show using the == operator on identical types. This is the way
I'm using the phrase "overload" as well.

It's not that the types are different to each other within the
signature - it's that the *signatures* are different.

Basically, if the string type didn't overload the == operator with

bool operator ==(string x, string y)

then there wouldn't be any such operator. There's be the implicit

bool operator ==(object x, object y)

but that's got a different signature, so isn't overridden by the string
one. (And wouldn't be anyway, as they're always static... which I
realise I haven't included above.)

Is there anything in the article which goes against that? I could see
anything in a brief skim, but I'm happy to look at any particular bits
more closely.

Look at the text in the section named "Overriding Operator ==":

By default, the operator == tests for reference equality by determining
if two references indicate the same object, so reference types do not
need to implement operator == in order to gain this functionality. When
a type is immutable, meaning the data contained in the instance cannot
be
changed, overloading operator == to compare value equality instead of
reference equality can be useful because, as immutable objects, they
can
be considered the same as long as they have the same value. Overriding
operator == in non-immutable types is not recommended.

Overloaded operator == implementations should not throw exceptions. Any
type that overloads operator == should also overload operator !=. For
example:

I do not read that text as talking about anything other than changing the
behavior of the == operator in a specific case. But within two
paragraphs, the word "override" is used only once (twice, if you count the
heading), while the word "overload" is used four times. As near as I can
tell, the words are used interchangeably.

"Overriding" there is a mistake. As operators are implemented as static
methods, they can't be overridden. Apologies for not finding it before
- I looked for "override" which of course misses "overriding".

I haven't been following the conversation closely enough, but overload
and override are pretty well defined in the C# and .NET world.

I certainly understand the distinction (even if I've confused the two on
occasion in the past :) ). However, I have only ever called the act of
changing an operator's beahvior "overloading", even when I haven't changed
the types involved in the comparison. Nor have I ever seen documentation
that makes a clear distinction between the two in that case.

There's no such thing as operator overriding, basically - could you
given an example where you think you *have* been doing what you'd call
operator overriding?

Even in the
context of C#, where the two terms are clearly distinct as applied to
methods, when talking about operators, the same care is not taken to
distinguish the two.

It is by some - just not by all :)

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Method.property string
    ... GetData.Col.RowOverload Col to set or get the ... Then would I instantiate the Col class from within the GetData Class to call ... private string name; ... public string GetName() ...
    (microsoft.public.dotnet.framework)
  • Re: Operator Overloading (was: Hashtable)
    ... >>colour + for addition and concatenation to make errors stand out. ... > I a sense, there is another overload. ... > - conversion to string. ... concatenation can lead to surprising behaviour. ...
    (comp.lang.java.programmer)
  • Re: ostream, istream, and String^
    ... > Would you care to explain which error you see? ... both of which are something like 'no overload of '<<' ... This takes the output stream given as a parameter, ... So my problem is because String^ does not have a natural overload of '<<' ...
    (microsoft.public.dotnet.languages.vc)
  • console.writeline overload question
    ... Console.WriteLine (string format, params object[] arg) ... object) overload is not CLS ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: The Opposite of IFormattable
    ... If you build a new class, should the ToString method always be declared ... builder of the class has used the overriding and possible the overloading. ... some source and re-fit it with its value that's represented as a string. ...
    (microsoft.public.dotnet.general)