I'm writing a framework, and we want it to be available from C#,C++, VB. We are not stricted to any other languages for now. But we have some problems in using CLS (we have to use unsign's etc.). Can you give some real problems that appear if we are not using CLS here?
3
- 1CLS compliant tag in the code, forcing to use CTS, like using int, but not uint in the public interface. Am I wrong?Archeg– Archeg2012-09-25 07:39:53 +00:00Commented Sep 25, 2012 at 7:39
- "we have to use unsign's etc.". If you have to, then obviously you can't be CLS Compliant. If you want to, that's a different issue.Damien_The_Unbeliever– Damien_The_Unbeliever2012-09-25 07:52:17 +00:00Commented Sep 25, 2012 at 7:52
- Yes, and I want to know, what are the problems that I need to pay attention to, when I'm using unsigns (and possibly something else), if I plan to use our framework with different .Net languagesArcheg– Archeg2012-09-25 08:00:50 +00:00Commented Sep 25, 2012 at 8:00
Add a comment |
3 Answers
Well, there are a lot of rules about CLS Compliance, not just ones regarding signed/unsigned types. One simple one which you'll have to follow or you already have problems is:
For two identifiers to be considered distinct, they must differ by more than just their case.
You don't need that for C# or C++, but Visual Basic requires that to be so. You also used the words "any other languages for now". If there's any possibility the list will expand in the future, you'll save yourself a lot of issues if you force yourself down the CLS Compliant road now.
answered Sep 25, 2012 at 7:46
Damien_The_Unbeliever
241k28 gold badges358 silver badges470 bronze badges
1 Comment
Archeg
Thanks. What if we consider this problem when we design our framework, but ignore the rule about unsigned types (as they are supported in VB and C++). Of course in that case we won't use CLSCompliant tag. Will that work?
It's generally considered good practice to mark the assembly as CLSCompliant, then use the CLSCompliant(false) attribute on Types and Members that are not CLS-compliant.
Of course if the majority of types in your assembly are not CLS-compliant, it probably makes more sense to mark the assembly as non-compliant.
One way to minimize problems with other languages is to mark only individual members with CLSCompliant(false), and provide CLS-compliant alternatives for each such member.
Comments
The CLS defines a subset of features that are available in any language that is CLS compliant. Some exotic features, like unsigned primitive types, are excluded to make it easier for a language to meat the CLS.
As long as the languages that you are going to use supports the data types that you want to use, the code doesn't really need to be CLS compliant. If you want to be able to mark the code as CLS compliant anyway, you simply can't use the types that are not supported.
In some cases you can use a larger data type to handle unsigned values, for example use an Int64 to hold any value that an UInt32 could.
