[VB] VB Maakt rekenfout met AND operatie

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 31-10-2023 22:43 ]

[klinz]

De oorzaak van dit probleem ligt in het feit dat VB blijkbaar probeert om de waarden in een ander datatype te passen. &ff00 past immers ook in een shortint.

Je kunt dit oplossen door de waarden te 'casten' met een & erachter.

&H112233& and &H00FF00&

Dit levert wel de juiste waarde op.

[Sjaaky]

Jaja, en omdat &HFF00 negatief is wordt er later weer &HFFFF00 van gemaakt. Vind ik toch wel een bug van vb.

edit: hmm, extra nullen hebben nooit betekenis voor een getal. Ik vraag me af hoe andere losse/niet getypeerde talen dit op lossen.

[ Voor 40% gewijzigd door Sjaaky op 27-09-2004 22:58 ]

[Verwijderd]

.

[ Voor 96% gewijzigd door Verwijderd op 31-10-2023 22:43 ]

[klinz]

Heb je de methode met de ampersand geprobeerd?

[bigbeng]

klinz schreef op 27 september 2004 @ 22:50:
De oorzaak van dit probleem ligt in het feit dat VB blijkbaar probeert om de waarden in een ander datatype te passen. &ff00 past immers ook in een shortint.

Je kunt dit oplossen door de waarden te 'casten' met een & erachter.

&H112233& and &H00FF00&

Dit levert wel de juiste waarde op.

Even ter verificatie, ik heb dit net uitgeprobeerd en dit werkt inderdaad. Ik heb dit met VBA getest, waar het probleem van de TS ook optreedt.

[Verwijderd]

VB 6.0 cast constantes altijd zo klein mogelijk. Omdat integers als 2-complement gecodeerd zijn kunnen vervolgens de hoogste bits flippen. De officiele (MS) remedie is de constanten zelf te casten, zoals hierboven beschreven.

MS ziet dit niet als bug, zo klein mogelijk casten heet een "memory saving feature".

[RobIII]

Verwijderd schreef op 30 september 2004 @ 10:49:
MS ziet dit niet als bug, zo klein mogelijk casten heet een "memory saving feature".

Dit is dan ook geen bug, maar gewoon goed en duidelijk gedocumenteerd. Ik vind het niet eens zo raar. Verder vind ik het een goede gewoonte altijd alles expliciet te casten naar wat je wil hebben. Wen er maar vast aan, want iedere nieuwe generatie talen dwingt het steeds meer af

[MrSleeves]

RobIII schreef op 01 oktober 2004 @ 02:10:
[...]

Dit is dan ook geen bug, maar gewoon goed en duidelijk gedocumenteerd. Ik vind het niet eens zo raar. Verder vind ik het een goede gewoonte altijd alles expliciet te casten naar wat je wil hebben. Wen er maar vast aan, want iedere nieuwe generatie talen dwingt het steeds meer af

Ik heb het idee dat VB.NET anders automatisch juist zo groot mogelijk cast. In VB.NET werkt de vergelijking ook gewoon. Volgens mij wordt er standaard Long, Double, etc. gekozen.

"It's not a bug; it's a feature" is een bekende uitspraak onder programmeurs. Volgens mij heeft Microsoft VB-programmeur dat ooit eens geroepen tegen z'n baas; en is dat vervolgens ook naar de klant doorgespeeld

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 31-10-2023 22:43 ]

[PrinsEdje80]

Verwijderd schreef op 05 oktober 2004 @ 12:55:
Wat mij betreft 100% een vette bug!

Niet dat ik VB of iets dergelijks ken, maar wel C/C++, SuperMongo (plotting package) en IDL. Vooral in de laatste is het extreem belangrijk hoe je je getal (lees: constante) definieert. Als ik daar bijvoorbeeld doe:

code:

a=1.5
b=1.5d
c=a+b

dan is a een float (sorry, IDL heeft geen type declaraties... en dus is het zelfs nog belangrijker dat je goed boekhoudt wat welk type is), b een double en c als het goed is ook een double.
Ik ben het dan ook zeker met bloog eens, dat dit een feature is (besparen van geheugen) en geen bug.

In andere woorden:
Goed boekhouden!

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 31-10-2023 22:43 ]

[farlane]

Verwijderd schreef op 05 oktober 2004 @ 12:55:
Met het '&' teken er achter werkt het inderdaad. Maar met CLng() werkt het niet. Daarmee zou het toch ook moeten werken?
Wat mij betreft 100% een vette bug!

Nee, CLng zet het getal om in two's complement, iets wat jij hier niet wil, jij wil puur het bitmask dat je geeft.

Bekijk de decimale waarde maar es van CLng( <Bitmask> ) en <Bitmask>&, dat verschilt gewoon van elkaar.