T
Tim Rogers
I'm wrapping a native C++ API with MC++. One of the things that I have
found frustrating is the fact that most (if not all) unsigned types in .NET
are not CLS-Compliant. So, to me, that means you can't use them, say, as
arguments in a method because a particular .NET language is not required to
support those types. The C++ API has a lot of paramters that are U8, U16,
and U32 types. Since the equivalent types in .NET are not CLS-compliant, I
find my self using a larger signed type to hold the possible non-negative
values of the corresponding unsigned type. For instance, for a U32 in the
C++ API, I have to use an Int64 in .NET. While, this works, it's just sort
of messy. For example, it forces you to do runtime checks on numbers that
are larger than can fit in a U32 in case someone passes in a really large
number in a method call (e.g. someone calling a method that takes an Int64
could pass in 4,294,967,306 - this is too large for a U32).
I was just curious if there is a better way to handle this? Not making
unsigned types CLS-compliant seems somewhat short-sighted to me, but maybe
I'm wrong. Any thoughts?
Thanks,
Tim Rogers
found frustrating is the fact that most (if not all) unsigned types in .NET
are not CLS-Compliant. So, to me, that means you can't use them, say, as
arguments in a method because a particular .NET language is not required to
support those types. The C++ API has a lot of paramters that are U8, U16,
and U32 types. Since the equivalent types in .NET are not CLS-compliant, I
find my self using a larger signed type to hold the possible non-negative
values of the corresponding unsigned type. For instance, for a U32 in the
C++ API, I have to use an Int64 in .NET. While, this works, it's just sort
of messy. For example, it forces you to do runtime checks on numbers that
are larger than can fit in a U32 in case someone passes in a really large
number in a method call (e.g. someone calling a method that takes an Int64
could pass in 4,294,967,306 - this is too large for a U32).
I was just curious if there is a better way to handle this? Not making
unsigned types CLS-compliant seems somewhat short-sighted to me, but maybe
I'm wrong. Any thoughts?
Thanks,
Tim Rogers