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

CLS complaint = Operators should not be overloaded

P: n/a
http://www.devarticles.com/c/a/C-Sha...CLS-Compliant/

Does anyone follow this? I know it's good to not have to deal with
unsigned types in the interface, so that's great. But CLS compliance
is quite strict:

"Only properties and methods may be overloaded, Operators should not
be overloaded."

Does that mean I can't make my own + operator for my own object? I
find this hard to believe. But, in general, it seems that CLS
compliant code is a very good idea. I wonder how widespread its usage
is? Do you guys use it?

Zytan

Mar 9 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Zytan wrote:
http://www.devarticles.com/c/a/C-Sha...CLS-Compliant/

Does anyone follow this? I know it's good to not have to deal with
unsigned types in the interface, so that's great. But CLS compliance
is quite strict:

"Only properties and methods may be overloaded, Operators should not
be overloaded."

Does that mean I can't make my own + operator for my own object? I
find this hard to believe. But, in general, it seems that CLS
compliant code is a very good idea. I wonder how widespread its usage
is? Do you guys use it?
The short answer is that not every .NET language supports operator
overloading so it is not part of the CLS. That doesn't mean you can't
overload operators in your code, but if you do you need to mark that section
as CLSComplaint(false) and give an alternate way of doing the same thing for
..NET languages that do not support operator overloading. For example, if
you overload + then also give your class an Add method that does the same
thing.

As far as CLS compliant code being a very good idea, that is only true if
you plan on making your objects available to any .NET language. If you know
your consumers are all going to be written in languages that support
operator overloading, and it makes sense in your class to do that, then you
shouldn't necessarily feel restricted by CLS compliance.
--
Tom Porterfield

Mar 9 '07 #2

P: n/a
Thus wrote Zytan,
http://www.devarticles.com/c/a/C-Sha...CLS-Compliant/

Does anyone follow this? I know it's good to not have to deal with
unsigned types in the interface, so that's great. But CLS compliance
is quite strict:

"Only properties and methods may be overloaded, Operators should not
be overloaded."
That is not correct. If you overload an operator, you *should* provide an
alternative method that fulfills the same purpose. This keeps your type fully
usable for .NET languages that don't support operator overloading (see System.DateTime
for example).

Cheers,
--
Joerg Jooss
ne********@joergjooss.de
Mar 9 '07 #3

P: n/a
The short answer is that not every .NET language supports operator
overloading so it is not part of the CLS. That doesn't mean you can't
overload operators in your code, but if you do you need to mark that section
as CLSComplaint(false) and give an alternate way of doing the same thing for
.NET languages that do not support operator overloading. For example, if
you overload + then also give your class an Add method that does the same
thing.
Oh, ok.
As far as CLS compliant code being a very good idea, that is only true if
you plan on making your objects available to any .NET language. If you know
your consumers are all going to be written in languages that support
operator overloading, and it makes sense in your class to do that, then you
shouldn't necessarily feel restricted by CLS compliance.
Wonderful explanation, Tom. Thanks!

Zytan

Mar 9 '07 #4

P: n/a
"Only properties and methods may be overloaded, Operators should not
be overloaded."

That is not correct. If you overload an operator, you *should* provide an
alternative method that fulfills the same purpose. This keeps your type fully
usable for .NET languages that don't support operator overloading (see System.DateTime
for example).
Great, and this totally makes sense. So, I can do it, and people who
use the more powerful languages can take advantage of it, but for
those without such features, they can still use my unit!

Thanks, Joerg!

Zytan

Mar 9 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.