在不支持无符号的语言中使用不符合 CLS 的类型会导致问题吗？
我的情况是：
我正在使用一个 .net 库，它包装了现有的 C++ 库。 C++ 中的一种方法返回一个无符号整数，我还想使用 System.Uint32 返回 .net 相应的方法。
对于不支持无符号数据类型的语言，这会导致一些问题吗？
My case is:
I'm working a .net library which wraps an existing C++ library. One method in C++ returns an unsigned int and I also want to return the .net corresponding method with an System.Uint32.
Will this cause some issue for languages which don't support unsigned data types?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最有可能会出现问题（特别是当您返回大于 2^31 的数字时），但根据这篇 SO post
是否有与 .NET 兼容但不支持无符号类型的语言？
似乎 .NET 语言并不多（或者，没有重要的那些，尽管很重要可能是主观的）不支持无符号数据类型。
Most probably there will be issues (especially when you return numbers which are greater than 2^31), but according to this SO post
Are there languages compatible with .NET that don't support unsigned types?
it seems there are not many .NET languages (or, no important ones, though importance may be subjective) which don't support unsigned data types.
如果一个类合法地符合 CLS，那么唯一应该要求语言支持超出 CLS 最低要求的功能是那些在没有这些功能的情况下毫无意义的功能。例如，如果这些方法提供的任何功能可以通过其他方式获得，则符合 CLS 的方法组可以包括无符号整数类型的重载。
如果一个类应该执行类似提供从某些外部数据集中读取和写入无符号 32 位值的方法之类的操作，则 CLS 合规性不会禁止该类型提供读取和写入 UInt32 类型数据的方法。 code>，但要求可以通过此类方法读取或写入的任何数据必须可由不需要该类型的其他方法读取[例如，它们可以使用
Int64代替]。使用Int64的客户端代码可能比使用UInt32的代码效率低，但语言不支持UInt32并不会阻止客户端代码不做它需要做的事情——它只会稍微减慢它的速度。If a class is legitimately CLS compliant, the only features one should require languages to support things beyond the CLS minimum requirements would be those which would be meaningless in the absence of such features. For example, a CLS-compliant method group may include overloads for unsigned integer types if any functionality provided by those methods would be available via other means.
If a class is supposed to do something like provide a means of reading and writing unsigned 32-bit values from some external data set, CLS compliance would not forbid the type from providing methods that read and write data of type
UInt32, but would require that any data which could be read or written via such methods must be readable by other methods that do not require that type [e.g. they could useInt64instead]. Client code which usesInt64might less efficient than would be code usingUInt32, but the failure of a language to supportUInt32wouldn't prevent the client code from doing what it needs to do--it would merely slow it down slightly.