O'Reilly Forums: The Iequatable<T> Interface - O'Reilly Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

The Iequatable<T> Interface Rate Topic: -----

#1 User is offline   AlCarn 

  • New Member
  • Pip
  • Group: Members
  • Posts: 2
  • Joined: 15-February 12

Posted 15 February 2012 - 12:34 PM

On page 264 while discussing IEquatable<T>, the following line appears:

"If we remove the generic constraint, the class would still compile, but a.Equals(B) would bind to the slower object.Equals (slower assuming T was a value type)."

Is this true? Doesn't the constraint just limit the types you can use with the generic to types that implement IEquatable<T>? If you remove the constraint, you could create the generic with either types that implement the interface or do not and wouldn't the binding just depend on what type you used?

Al
0

#2 User is offline   JoeAlbahari 

  • Super Veteran Member
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Members
  • Posts: 529
  • Joined: 15-February 08
  • Gender:Male
  • Location:Perth, Australia

Posted 15 February 2012 - 06:35 PM

Unless you use the dynamic keyword, binding decisions in C# are made at compile-time rather than runtime.

The situation with a type constraint is no different to what happens in the following two methods:

void Foo1 (object x) { x.Equals (x); }

void Foo2<T> (IEquatable<T> x) { x.Equals(x); }

The call to Equals in Foo1 binds to object's Equals method, whereas the Equals in Foo2 binds to IEquatable<T>'s Equals method. The latter avoids boxing overhead and so is faster.

Bear in mind, though, that avoiding boxing is a micro-optimization. It's worth doing if either:
(1) It can be done effortlessly (IEquatable<T> might be included in this category)
(2) You're trying to make code that's called millions of times in a loop run faster

Joe

This post has been edited by JoeAlbahari: 15 February 2012 - 06:35 PM

0

#3 User is offline   AlCarn 

  • New Member
  • Pip
  • Group: Members
  • Posts: 2
  • Joined: 15-February 12

Posted 16 February 2012 - 04:07 AM

Makes sense. Thanks.

View PostJoeAlbahari, on 15 February 2012 - 06:35 PM, said:

Unless you use the dynamic keyword, binding decisions in C# are made at compile-time rather than runtime.

The situation with a type constraint is no different to what happens in the following two methods:

void Foo1 (object x) { x.Equals (x); }

void Foo2<T> (IEquatable<T> x) { x.Equals(x); }

The call to Equals in Foo1 binds to object's Equals method, whereas the Equals in Foo2 binds to IEquatable<T>'s Equals method. The latter avoids boxing overhead and so is faster.

Bear in mind, though, that avoiding boxing is a micro-optimization. It's worth doing if either:
(1) It can be done effortlessly (IEquatable<T> might be included in this category)
(2) You're trying to make code that's called millions of times in a loop run faster

Joe

0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users