Unsigned integer problem?

  • Thread starter Thread starter barbara
  • Start date Start date
B

barbara

Hi, all

I have to read a binary data which is four bytes and I need to use the
following function to deal with data:

Private Function BIT(ByVal Val As UInt32, ByVal BitNum As UInt32) As
UInt32
Dim displayMask As UInt32 = Convert.ToUInt32(1)

If (BitNum = Convert.ToUInt32(0)) Then
If ((Val And displayMask) = 1) Then
Return Convert.ToUInt32(1)
Else
Return Convert.ToUInt32(0)
End If
Else
Val = shiftRight(Val, BitNum)
If ((Val And displayMask) = 1) Then
Return Convert.ToUInt32(1)
Else
Return Convert.ToUInt32(0)
End If
End If
End Function

but I got error like "Operator 'And' or '=' is not defined for types
'System.uint32".

How to make it work?


Thanks!
 
The current version of VB.Net will allow you to declare unsigned integers, but
really doesn't support them.
There are basically no operators defined for working with them. You can't add,
subtract, compare, etc.
My solution was to temporarily write all functions must deal with unsigned
integers in C# and reference that into VB.
If that isn't an option for you, then depending upon your needs, you might be
able to use BitFields, or an array of Bytes, or cast the UInt32 to an Int64
(taking some care about making sure the result is signed positive and ignoring
the wasted additional 32 bits).
I have read rumors that the upcoming version of VB.Net will support Unsigned
Integers. I truly hope this is the case.

Gerald
 
* "Cablewizard said:
I have read rumors that the upcoming version of VB.Net will support Unsigned
Integers. I truly hope this is the case.

They will be supported, but that doesn't make them more CLS compliant.
 
It means 'I echo you' ( Agree )

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
 
True, would not be compliant. One thing that really got me excited about the
announcement of the CLR was unified variable handling. I saw a list at that time
which included UInt's. Like many VB programmers, I frequently have need to
interoperate with C. And we all know what a mess passing variables can be. That,
and I frequently need to work with files and such that use UInt's extensively.
When VB.Net was finally released, I jumped in with both feet to try to convert
all my stuff over so I could use them. Had a rude awakening. I understand that
maybe UInt's "should" be phased out. However, I personally think that part of
the standard was shortsighted. There is a whole lot of data out there that uses
them. And when you just need that extra bit, sure is a big waste to double your
file and memory size.

Besides, would this be the first time that MS tried to set down a standard, then
violate their own standard, then provide a way around the standard? heh, just
poking fun.

Gerald
 
* "Cablewizard said:
True, would not be compliant. One thing that really got me excited about the
announcement of the CLR was unified variable handling. I saw a list at that time
which included UInt's. Like many VB programmers, I frequently have need to
interoperate with C. And we all know what a mess passing variables can be. That,
and I frequently need to work with files and such that use UInt's extensively.
When VB.Net was finally released, I jumped in with both feet to try to convert
all my stuff over so I could use them. Had a rude awakening. I understand that
maybe UInt's "should" be phased out. However, I personally think that part of
the standard was shortsighted. There is a whole lot of data out there that uses
them. And when you just need that extra bit, sure is a big waste to double your
file and memory size.

Mhm... I do not see many reasons for not adding them to the CLS too.
Nevertheless, it's the /Common/ Language Specification. Currently
unsigned integers are mostly used in p/invoke and interop scenarios that
are hardly ever CLS compliant.
Besides, would this be the first time that MS tried to set down a standard, then
violate their own standard, then provide a way around the standard? heh, just
poking fun.

It's a specification, no law ;-).
 
Agreed. Bring on the next release. Can't wait for this and operator overloading
in VB.
Wahoo! :D

Gerald
 
Hi Terry,

As far as I know, there are no mountains in the Thames Valley, echos comes
here in this newsgroups mostly from Austria, (for non Europeans who read
this, one of the EU countries with the most and highest mountains)

:-)

Cor
 
Yes, but I think the UKIP ( UK Independent Party ) will remove us from
Europe soon, so when I said that I was talking into a bucket.

;-)
 
Hi, Gerald,

I'd like to take the option which is writing all functions deal with
unsigned integers in C# and reference them into VB. But I am new to
vb.net and C#. Could you please give me some detail instructions about
how to make functions in C# and reference to VB.net?

Thank you so much in advance!

Barbara
 
Create a C# Class Library and add a class to it which contains your member
function. The Syntax is of course different to VB for example

Dim A as Int32 would be something like

Int32 A

To test the functionality. Add a reference to the Dll and then import the
namespace into the VB project, then you can reference the Function.
 
* "One Handed Man \( OHM - Terry Burns \) said:
Create a C# Class Library and add a class to it which contains your member
function. The Syntax is of course different to VB for example

Dim A as Int32 would be something like

Int32 A

To test the functionality. Add a reference to the Dll and then import the
namespace into the VB project, then you can reference the Function.

ACK. Nevertheless, I would not use UInts if possible.
 
I completely agree. Where possible avoid it, however, some hardware uses
UInts in its registers, so it is a requirement from time to time.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
 
Hmmm....
If you are not familiar with C#, then I might recommend one of the other methods
of dealing with these.
While UInts certainly have their place, I agree with Herfried, IF possible don't
keep them as UInts.
Even if you implement certain functionality in C# to deal with them, you are
better off not passing UInts back to VB.
Since I really do not know what your requirements are, there is limited
additional info I can provide.

Gerald
 
* "One Handed Man \( OHM - Terry Burns \) said:
I completely agree. Where possible avoid it, however, some hardware uses
UInts in its registers, so it is a requirement from time to time.

My post was a little bit unclear. I wanted to say: Don't use unsigned
integers in interfaces/methods/... that are visible to the "consumer" of
a component. Using them inside the implementation is IMO no problem and
sometimes there is no way around that.
 
Currently unsigned integers are mostly used in p/invoke and interop
scenarios that
are hardly ever CLS compliant.

Huh? Unsigned integers are also frequently used when talking to HARDWARE,
both in terms of simple bit manipulation as well as data acquisition.
Several times I've been frustrated that my "modern" computer language of
choice can't do simple things like count, add, and subtract without enormous
amount extra work on my part.

PLEASE add full unsigned integer support EVERYWHERE!

Sigh...

--George
 
Back
Top