1

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?

HostileFork says dont trust SE
  • 32,904
  • 11
  • 98
  • 167
softempire
  • 135
  • 7

2 Answers2

1

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.

Community
  • 1
  • 1
Doc Brown
  • 19,739
  • 7
  • 52
  • 88
  • Currently, I don't know which language doesn't support unsigned. For unsigned data like 2^31, can we consume it like System.Int64 intData = getUnsignedData() ? – softempire Sep 06 '11 at 07:48
  • @softempire: I would not expect that working, you will probably get a negative return value (but I cannot verify this since I don't have a .NET language at hand with no unsigned types). But isn't that discussion purely theoretical? – Doc Brown Sep 06 '11 at 09:10
0

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 use Int64 instead]. Client code which uses Int64 might less efficient than would be code using UInt32, but the failure of a language to support UInt32 wouldn't prevent the client code from doing what it needs to do--it would merely slow it down slightly.

supercat
  • 77,689
  • 9
  • 166
  • 211