How do i make a Unsigned 32 Bit Integer?
I think it would be System.UInt32.
Visual Basic .NET does not support the use of unsigned data types. You can keep track of an instance of System.UInt32, but you cannot assign it an unsigned value (that is, a value greater than System.In32.MaxValue).
UInteger in .NET 2.0.
Public Overridable Overloads Sub InsertByte(ByVal b As Byte)
Stream.WriteByte(b)
End Sub
Public Overloads Sub InsertByte(ByVal b As SByte)
Stream.WriteByte(b)
End Sub
I am trying to Overload my InsertByte function depending on the value given.. it is not working -_-
Quote from: BaDDBLooD on February 06, 2005, 02:24 PM
Public Overridable Overloads Sub InsertByte(ByVal b As Byte)
Stream.WriteByte(b)
End Sub
Public Overloads Sub InsertByte(ByVal b As SByte)
Stream.WriteByte(b)
End Sub
I am trying to Overload my InsertByte function depending on the value given.. it is not working -_-
Okay, [edit]: Unsigned integral values 16 bits and larger are not supported in Visual Basic .NET. Signed 8-bit values are not supported in Visual Baisc. Therefore, the following types (which are not CLS-compliant) are not supported in Visual Basic .NET: SByte, UInt16, UInt32, UInt64.
Why do they exist? Are they "CLS Compliant" in framework 2.0?
Quote from: BaDDBLooD on February 07, 2005, 03:14 PM
Why do they exist? Are they "CLS Compliant" in framework 2.0?
Yes. UInteger, UShort, ULong.
Quote from: dxoigmn on February 07, 2005, 03:53 PM
Quote from: BaDDBLooD on February 07, 2005, 03:14 PM
Why do they exist? Are they "CLS Compliant" in framework 2.0?
Yes. UInteger, UShort, ULong.
I still don't think they're CLS-compliant; other things such as Generics, which will be available in 2.0 as well, are not CLS-compliant.
CLS-Compliant means that a particular language implements the very basic common components of the common language specification, which is the specification that allows the different languages to interoperate with one another. A C# library that uses System.UInt32 inside of functions will work inside a Visual Basic .NET application. However, if functions expose (such as a return value or accepted parameter) a non-CLS-compliant type, Visual Basic .NET will have trouble with it.
Quote from: MyndFyre on February 07, 2005, 04:57 PM
I still don't think they're CLS-compliant; other things such as Generics, which will be available in 2.0 as well, are not CLS-compliant.
CLS-Compliant means that a particular language implements the very basic common components of the common language specification, which is the specification that allows the different languages to interoperate with one another. A C# library that uses System.UInt32 inside of functions will work inside a Visual Basic .NET application. However, if functions expose (such as a return value or accepted parameter) a non-CLS-compliant type, Visual Basic .NET will have trouble with it.
Generics are CLS-compliant. So are those types I explained above in 2.0
Quote from: dxoigmn on February 07, 2005, 05:17 PM
Quote from: MyndFyre on February 07, 2005, 04:57 PM
I still don't think they're CLS-compliant; other things such as Generics, which will be available in 2.0 as well, are not CLS-compliant.
CLS-Compliant means that a particular language implements the very basic common components of the common language specification, which is the specification that allows the different languages to interoperate with one another. A C# library that uses System.UInt32 inside of functions will work inside a Visual Basic .NET application. However, if functions expose (such as a return value or accepted parameter) a non-CLS-compliant type, Visual Basic .NET will have trouble with it.
Generics are CLS-compliant. So are those types I explained above in 2.0
Generics are not CLS-compliant. See the namespace browser at http://www.dotnet2themax.com/dotNetBrowser/ShowType.aspx?asm=mscorlib&ns=System.Collections.Generic&type=Comparer{T}. Note that the System.CLSComplianAttribute attribute is applied to the type, with the property IsCompliant as false. For information on System.UInt32, see http://www.dotnet2themax.com/dotNetBrowser/ShowType.aspx?asm=mscorlib&ns=System&type=UInt32.
They are an extension to the Common Language Specification. They *can* be supported by multiple languages in a common way -- and they are in 2.0 -- but they are not required to be.
so if i switch to 2.0, my problem would lessen?
If you are using generics :P
Quote from: BaDDBLooD on February 07, 2005, 06:11 PM
so if i switch to 2.0, my problem would lessen?
You don't need to have those functions at all. You're converting things such as my packet buffer class, correct? Those functions wouldn't be available to you in VB.NET anyway; you can just skip over them.
Quote from: MyndFyre on February 07, 2005, 06:48 PM
Quote from: BaDDBLooD on February 07, 2005, 06:11 PM
so if i switch to 2.0, my problem would lessen?
You don't need to have those functions at all. You're converting things such as my packet buffer class, correct? Those functions wouldn't be available to you in VB.NET anyway; you can just skip over them.
Buffer.CS, which i converted to vb, which i then combined with my old PacketBuffer.vb to make my new PacketBuffer.vb.
I Just thought having those options would be beneficial... but if i can't get it to work than oh well.
I Would have just used your Buffer.CS class by.. iteself, but i wanted to experience with making inherited classes. I might add a C# project with some of your open source classes. I don't know as of yet. Having both C# and VB7 projects might be a good learning experience. Unfortunately, all your classes are sort of... vague and tied together; Which makes it EXTREMELY difficult to use one, or the other.
In Whidbey (which Visual Studio 2005 is) generics are CLS-compliant along with many other things.
http://blogs.msdn.com/bclteam/archive/2004/12/21/328585.aspx
http://geekswithblogs.net/khanna/archive/2005/01/07/19376.aspx
http://hyperthink.net/blog/PermaLink,guid,e4a5b50b-ccbc-48b6-82aa-78a8afa79677.aspx
mmm, then that's change from the most recent "official" release. My libraries still show it flagged for non-CLS-compliant.
Does this really matter?
Quote from: shout on February 08, 2005, 11:04 AM
Does this really matter?
Yes; if the types are CLS-compliant, that means that any language that supports .NET *must* support these features.
Ah.
SByte to Byte, Byte to SByte enjoy
Public Function ByteToSByte(ByVal bytAr As Byte) As SByte
Dim sbytOut As SByte
sbytOut = SByte.Parse((bytAr - 128).ToString)
Return sbytOut
End Function
Public Function SByteToByte(ByVal bytAr As SByte()) As Byte()
Dim i As Integer
Dim sbytOut(bytAr.Length - 1) As Byte
For i = 0 To (bytAr.Length - 1)
sbytOut(i) = Val(bytAr(i).ToString) + 128
Next
Return sbytOut
End Function
Public Function SByteToByte(ByVal bytAr As SByte) As Byte
Dim sbytOut As Byte
sbytOut = Val(bytAr.ToString) + 128
Return sbytOut
End Function
Public Function ByteToSByte(ByVal bytAr As Byte()) As SByte()
Dim i As Integer
Dim sbytOut(bytAr.Length - 1) As SByte
For i = 0 To (bytAr.Length - 1)
sbytOut(i) = SByte.Parse((bytAr(i) - 128).ToString)
Next
Return sbytOut
End FunctionNo idea why you want this however this is one way of doing the conversion.