Lack of Unsigned CLS-Compliant Types in .NET

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

Michael
Fri Aug 29 12:41:39 CDT 2003

"Tim Rogers" <trogersREMOVETHIS@tga.com> wrote in
news:vkutc453su2kd7@corp.supernews.com:
>
> Not making unsigned types CLS-compliant seems somewhat short-sighted
> to me, but maybe I'm wrong. Any thoughts?
>
> Thanks,
>
> Tim Rogers

CLS compliant just means that ALL languages and platforms must support it.
If something is not CLS compliant, it was probably forseen as impossible to
implement on another target platform or language. Or as just to difficult
of a concept to implement in some language (VB7).

C# does support unsigned types. If you don't mind only C# as a viable user
of your component, just leave the types as unsigned.

You could also re-write your C++ component to use a signed type.

--
Michael Lang, MCSD
See my .NET open source projects
http://sourceforge.net/projects/dbobjecter (code generator)
http://sourceforge.net/projects/genadonet ("generic" ADO.NET)

Thomas
Sat Aug 30 08:35:13 CDT 2003

> The C++ API has a lot of paramters that are U8, U16,
> and U32 types.

yes, but many/most of the API calls don't depend on the sign.
So just use the signed .NET types.



--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/

Conrad
Wed Sep 03 02:39:20 CDT 2003

http://blogs.gotdotnet.com/brada/commentview.aspx/9506c739-f2ed-421c-8a61-bf43412796a0

"Tim Rogers" <trogersREMOVETHIS@tga.com> wrote in message
news:vkutc453su2kd7@corp.supernews.com...
> 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
>
>

Richard
Thu Sep 04 15:14:19 CDT 2003

As a C++ programmer I also find it odd that other languages don't support
unsigned types, but its just a fact of life and you have to accept it :-(

However, to make your C# and MC++ developers happy you can use overloading
to provide a non-CLS compliant version of your methods that use unsigned
parameters - just make sure that they are marked with [ClsCompliant(false)]
so that signed-challenged languages don't call them (and call the version
with signed parameters instead).

Richard
--
my email evpuneqt@zicf.bet is encrypted with ROT13 (www.rot13.org)

Tim Rogers wrote:
> 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