By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,365 Members | 3,180 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,365 IT Pros & Developers. It's quick & easy.

Unconstrained Generic comparison should be allowed

P: n/a
Unlike C++, in Csharp you're only allowed to compare a generic type T
with null, if the method it's passed in not implementing
IComparable<Tor , IEquatable<T(still don't know why we need these
two radically similar interfaces). In other words, Csharp enforces
people to not make mistake, whereas C++ follows the philosophy "if you
make a stupid mistake, pay for it, and in the future you won't do it
again." In my opinion, comparing a type that doesn't support
comparison is a stupid mistake. All these checks and enforcements
introduced by C# is likely to burden compiler tremendously.

Seriously, why are comparisons are not allowed if mentioned interfaces
are not implemented, even if type supports the comparison?
Nov 4 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Mon, 03 Nov 2008 18:22:19 -0800, puzzlecracker <ir*********@gmail.com>
wrote:
Unlike C++, in Csharp you're only allowed to compare a generic type T
with null, if the method it's passed in not implementing
IComparable<Tor , IEquatable<T(still don't know why we need these
two radically similar interfaces).
What do you mean by "compare"? It's true that if you constrain a
parameter so that it has to implement those interfaces, you can call the
members of those interfaces. But in that context, there's nothing special
about the interfaces; they are just like any other constraint. The fact
that they happen to be useful for comparisons is really just

Conversely, there are other ways to compare objects, and just because an
object implements those interfaces, that doesn't mean you'd be able to use
those other ways to compare objects. In particular, you don't get
"operator<" and "operator>" overloads for free.
In other words, Csharp enforces
people to not make mistake, whereas C++ follows the philosophy "if you
make a stupid mistake, pay for it, and in the future you won't do it
again." In my opinion, comparing a type that doesn't support
comparison is a stupid mistake. All these checks and enforcements
introduced by C# is likely to burden compiler tremendously.
For better or worse, that is the trade-off the C# design group has
chosen. That is, C# is a much more strongly typed and strict language
than C++. And yes, it's more work for the compiler, but you don't get
something for nothing.

Note also that C++ doesn't have generics. It has templates which are
similar, but not exactly the same. In particular, a C# generic is a true
type unto itself. But a C++ template is really just a preprocessing
step. C++ doesn't do _any_ kind of error-checking on the template itself;
any error-checking winds up implicit as part of the use of the template.
Seriously, why are comparisons are not allowed if mentioned interfaces
are not implemented, even if type supports the comparison?
This part I don't really understand. By definition, the type doesn't
"support the comparison" unless it implements the relevant interface. And
if the type does implement the relevant interface, then comparisons _are_
allowed.

Generics don't have any way to represent a constraint involving operator
overloads, so in that case, comparisons in a generic aren't allowed even
if the type _does_ support the comparison. So however I look at your
question, it doesn't really make sense to me.

Pete
Nov 4 '08 #2

P: n/a
puzzlecracker wrote:

The simplest option here would be to use Comparer<T>.Default.Compare -
job done. C# generics do not support operators, but you can hack them
toegether if you want; I've done this in the past here (using .NET 3.5):

http://www.pobox.com/~skeet/csharp/m...operators.html

(includes the comparison operators)

Interestingly, C# 4.0 promises to support operators on the new "dynamic"
type, which would be a short-cut, but probably noticeably slower than
either of the above approaches. I can't tell yet, as it isn't in the CTP
build...

Marc
[C# MVP]
Nov 4 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.