Dim
u64HiBit As UInt64u64HiBit += &H8000000000000000
or
u64HiBit = u64HiBit or &H8000000000000000
In my understanding this is simply setting the hi-bit in an unsigned integer. It certainly shouldn't cause an overflow unless it's not really a 64-bit entity.
There is a worse possibility which is that it truly isn't supported with the CLR.
But this behavior is really sort of strange.
Overflow???
the user
Try initializing the u64HiBit to 0 first.
Makler
u64HiBit = 1 << 63
Is not legal
Constant expression not representable in type 'ULong'
Also:
GetString = unravel(9705974862591203240) ' Generates an over flow error on the procedure call while in the editor
However Unravel is defined thusly:
Private Function Unravel(ByVal Number As UInt64) As String
9705974862591203240. = &H86B28CB68B9E97A8*
(86|B2|8C|B6|8B|9E|97|A8)
This is a legal 64-bit number and should not over flow in a procedure call.
Also when I do this:
GetString = unravel(9705974862591203240) ' Generates an over flow error on the procedure call while in the editor
However Unravel is defined thusly:
Private Function Unravel(ByVal Number As UInt64) As String
9705974862591203240. = &H86B28CB68B9E97A8*
(86|B2|8C|B6|8B|9E|97|A8)
This is a legal 64-bit number and should not over flow in a procedure call.
Also when I do this:
GetString = unravel(&H86B28CB68B9E97A8)
The compilers response is
Constants not allowed for datype Ulong
mshafiq
Vishva
Anyway, what's going on is operator precedence - boolean and bitwise operators have lower precedence than comparison operators.
Basically the code as you have it is the equivalent of:
If Num And (&H8000000000000000UL <> 0UL) Then bHibit = True
If I remember correctly, the compiler will try to cast both arguments to And to a long, so depending on the value of Num you can get an overflow.
Meanwhile, I'm not sure what you mean by displacement of UI
VasudevaKumarAtukuri
u64HiBit += &H8000000000000000UL
Thank you. I know those designators for other datatypes and I know when to use them - however, I don't know what they are called and when you don't know what they are called, you can't look them up.
I would have been really embarassed had i asked, "What do you call those descriptors that go on the end of constants that describe their actual displacement " Few people would have know what i was talking about. I just went back and looked and noticed that you didn't name them either.
Ack... I think I just deleted the program that I was having so much trouble with... let me check and see if it's still on disk....
Hooray!!!!!! I had wiped it out in the editor but hadn't saved it. So I still have the program and will go play this. Thank you!!!!!!!!!!
Ghost Assasin
They helped with subroutine arguments but I am still get an overflow...
Private
Function Unravel(ByVal Number As UInt64) As StringUnravel =
"" Dim Num As UInt64 = Number Dim bHibit As Boolean If Num And &H8000000000000000UL <> 0UL Then bHibit = True <-OverflowThe interesting thing is that I not setting any bits here, I am just reading and everything in the statement is a UL.....
That still doesn't seem that it show be overflowing....
Btw... I never need luck in programming. ;)
WHat is the displacement for UI
binarysins
Good luck with your coding
MickRivers.
If you change your UInt64 to Double and debug, you'll see what is happening behind the scenes. The hex you pass the unsigned long is actually evaluated as a signed value (Int64), and the Overflow happens when you try to assign a negative to the UInt64.
Why do you need UInt64's If you're just storing bits and bytes in positions (e.g. as flags), it doesn't really matter if the integer is signed or not, right The hex representation of the value is the same either way.
Hope this helps,
Josh Lindenmuth
nt2008
Best of luck,
Josh Lindenmuth
Richard Latham
Hi Josh,
I'm enjoying this conversation. I was an engineer for Digital just as it was converting to Alpha. I used to write drivers in Assembler and I really miss that instruction set. It was so cool.
For a "higher level" language I used Bliss 32 and was accomplished in it. But I've never liked the C-world.
I've done some C++ programming in VS6. I do like that you can do assembly in C++, the bad news is that it's with the pentium instruction set. It used to drive me crazy that I used to have to designate subroutines and functions in header files.
I found C++ really frustrating. There was all this ceremony and dance around pointer variables etc. On a Vax anything could be a pointer and why C made pointer such a ceremony I'll never know. Also in C++ I found that I always had to pay and incredible amount of attention to the language itself, so much so that it was a big distraction from what I was programming. I never enjoyed C++ although I really could do what I wanted to with a byte. There were multiple set of primitives like for doing file I/O and when you wanted to change what you were doing with a particular kind of file, suddenly I'd find that the class of primitives I was using wouldn't handle the new requirements. Bliss had it semi colons I have to admit. Sometimes I'd lose a semi colon or and identation level and had no choice but to print out a lot of pages and lay it out on a the floor because it would never fit on a desk. I think i was laying on the floor with a print out when we learned that Hinkley shot Reagan. So there are things that I love about VB. The high level stuff is wonderful, it's when you want to bit twiddle that it becomes really cumbersome. Things like arraylists and dictionaries are unbelievably wonderful it's just that I'm a lot more of a systems programmer.
I was reflecting today that on the vax there was just a few datatypes. Bits, Bytes, words, longwords and quadwords and floating point numbers that systems people never thought about much. There was just code and "memory". Strings were sort of neat in bliss. There was a string descriptor and you'd allocate some memory. One long word of the descriptor was a pointer to the buffer. I there was a word for string length and a word for descriptor flags and you'd just go to town and yes I really do miss that. Bliss was so barebones that it had no native I/O primitives which were analogous to classes these days. If you wanted to do I/O to your terminal, you have to write it and I don't see that as a particularly bad thing. Early on I developed a template and used it for everything and I could write prodigious amounts of code. I've never been able to be that productive in VB and it's not because I don't know VB paradoxically everything takes a lot longer and I've tried to figure out why that is.
It sounds like I am describing a primitive machine and architecture but actually it had 400 of the most elegant instructions I've ever seen and one of the best operating systems ever done. Some people talk the similarity of pentiums and vaxes but I don't see it except architectual similarites.
Yes, I feel much more "managed" in VB.net but I can also pay a lot more attention to a given application. The down side is that I run into these managed bottle necks. Data structures that you can put data into but can't get data into them or conversely, data structures that you can get data from in them and then can't get to it.
Anonymous4200
Dim u64HiBit As UInt64
u64HiBit = &H8000000000000000
You're trying to assign long.minvalue to a ulong - the compiler errors out.
if you do:
Dim u64HiBit As UInt64
u64HiBit += &H8000000000000000
then you're adding an unsigned long with a literal of value long.minvalue - the result is a decimal, and since the compiler doesn't know of the value in u64HiBit (and it seems you're using option strict off) it won't give you an error until runtime (in this case in the form of an overflow exception)
I think what you want to do is this:
Dim
u64HiBit As UInt64u64HiBit += &H8000000000000000UL
You can also append US and UI to literals to make them have the type of UShort and UInteger respectively.
kumarsv
I tried this:
Dim
u64HiBit As UInt64 = 0u64HiBit += &H8000000000000000
It didn't work as I still receive an over flow and I'm having some other strange errors. I have to use that format because the compiler was not allowing this:
Dim
u64HiBit As UInt64u64HiBit = &H8000000000000000
The abililty to manipulate the high bit in the uint64 datatype seems very limited and of course.... that's the bit that is going to get the most attention.The compiler was telling me that 64 bit constants were not allowed. Things seem very flaky with this datatype even in RC1 and they shouldn't be, it's an important datatype whether other languages support it or not.
Nigel A Banks
Yes, I noticed how it was acting very early on which is why i was speculating that it wasn't behaving like an unsigned sixty-four bit entitiy.
***Sigh***
The 'why' has really changed since all of this came up. This is just a little side program for obscuring data not encrypting it and you're right... it is simply a way to pack ascii.
But originally it was more ambitious. I started to do what on Vaxes was a Rotate instruction. Here I was just looking at bit zero and I'd store it and shift everything down a bit and then set the high bit if indicated which I found was impossible. What I'm actually finding that dealing with this datatype in VB is really punishing and it does not behave like an unsigned number behaves. I see over flows and I can't use the datatype as input argument to a function.
I think I can illustrate I can't use the datatype. Earlier I was storing the ascii string "Whatismy" in it. I also tried to just the Long datatype which is not as resitictive. With unint64 I could get that entire string in there. With a signed 64 bit entity, I don't know why but that "W" in the low byte sets bit 63, thus there is no control over that bit, to some extent and almost randomly the same seems to be true for the Unint64 bit data type. If you can't control that bit, you can't use te byte, but furthermore right now it doesn't look like a long is even useable.
I love the features of OOL there's not doubt about that, but at the same time, it's really become restrictive. I used to love the byte datatype because you could do whatever you wanted to do to a byte. These days with strings, you really can't manipulate them. I really miss being able to do these things.
I agree with you, this probably is by design and if that is the case, the datatype shouldn't be there at all because it's close to unuseabe in VB.
I've always has access to an unsigned 64 bit entity. This is a very unusual application for me and thankfully, it's not important and not a barnburner. But I'd certainly use them if I had them.
I am appreciative that you seemed to see the problems instantly. I am very saddened by the way this is supported in VB. Also in playing with bytes last night, these days, getting anything into and out bytes these days is like pulling chicken teeth. It's painful. It would be so nice to be able to use ascii. To be honest, I have no need for sixteen bit characters. Ascii has been just fine. I really miss soe of the old components.
But I knew what was going without using a double. I could see it and feel it. How many times over the years have I been bitten by sign bits This entity was such a pleasure because it promised not to have any.
Litey
This assignment is not allowed...
u64HiBit =
&H8000000000000000The error is : "constant expression is not representable with type Ulong"
However this is legal:
u64HiBit += &H8000000000000000
and so is this:
u64HiBit = u64HiBit or &H8000000000000000
However...even though the compiler sees them as legal, they result in an overflow exception at run time.
This is legal and works at run time:
Dim
u64HiBit As UInt64 = 0u64HiBit =
Not u64HiBit The result is a proper FFFFFFFFFFFFFFFFBut this always generates an overflow and I don't believe it should:
Mask1 = Mask1
Or &H8000000000000000 where mask1 is declared as a uint64