What is the significance of a flag value of -33?

Question

1.00/5 (1 vote)

See more:

VB

'Example of usage:

	If Me.EditingComboBox IsNot Nothing AndAlso (Me._flags And 32) <> 0 Then
		RemoveHandler Me.EditingComboBox.DropDown, _ 
                    New EventHandler(AddressOf Me.ComboBox_DropDown)
		Me._flags = CByte((CInt(Me._flags) And -33))
	End If

Posted 29-Dec-14 10:27am

reeselmiller2

Add a Solution

Comments

Philippe Mori 29-Dec-14 16:48pm

Without context, it does not have any meaning.

Sergey Alexandrovich Kryukov 29-Dec-14 22:15pm

Pure gibberish, and unacceptably poor programming style, even if it works correctly. Such questions are counter-productive. Instead, you should write code yourself, according to your goals, excluding any guesswork.
—SA

reeselmiller2 29-Dec-14 22:27pm

It was written by Microsoft, but if you have any REAL input that would be helpful.

Sergey Alexandrovich Kryukov 29-Dec-14 22:34pm

Ask a real question, and I'll give a real answer. Or define "significance". And do follow my advice, this is for your own good, not mine.
—SA

reeselmiller2 29-Dec-14 22:46pm

Thanks Sergey, I forgot that you know it all. I'll make sure that I learn everything before I ask my next question. Maybe this is why most beginners have so much trouble asking questions. Because there's always someone like you ready to ridicule them instead of HELP them.

Sergey Alexandrovich Kryukov 29-Dec-14 23:59pm

You are very welcome. Perhaps if you understand that no one here is an enemy for you, it will really help you.
—SA

reeselmiller2 30-Dec-14 0:15am

Sergey, everyone knows how smart you are and your answers are quite helpful to me. But I felt like you were just in a bad mood. All I wanted was some insight into how the flag value was being used in those lines of code. It seemed like a "magic number" at the time.

Sergey Alexandrovich Kryukov 30-Dec-14 0:39am

Not even close. I really wanted to help you to bring your attention to different ways of learning things. If you learn things from scratch, by writing your own code and using only fundamental facts, everything comes much better. After all, this is all about very elementary and important thing: bitwise operations.
Most sophisticated thing here (which one could easily avoid by avoiding using negative numbers in bitwise arithmetic) is this: http://en.wikipedia.org/wiki/Two%27s_complement.

And please don't try to be so aggressive: no one will probably take it seriously, get offended or compete in acuteness or pick the fight. If you want to get help, you will get help.

—SA

reeselmiller2 30-Dec-14 1:17am

Thanks for the reference. This is part of my confusion. The flag is a ulong and can have a value like 18446744073709551583 which converts to a decimal -33, works fine in C#. But in VB if you try "i As Integer = CInt(18446744073709551583UL) you get an overflow error. So you have to use something like Decimal.GetBits(18446744073709551583D)(0) which gives you the low 32bits of the 96 bit Integer. I agree the code is horrible, just trying to understand why it is written this way.

Philippe Mori 31-Dec-14 11:25am

Where have you found this code?

reeselmiller2 31-Dec-14 13:40pm

I have actually lost the original source of this code. I copied it along time ago from a tutorial written from Microsoft on how to write a specialized combobox. It had both C# and VB examples. I now believe the VB was converted from the C# with out much thought and the conversion was not actually tested.

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

PIEBALDconsult · Accepted Answer · 2014-12-29T10:39:00

Solution 1

Edit:
Decimal -33 is binary 11111111111111111111111111011111 so that code will clear the bit represented by the zero. What that bit means is not evident from the code; this is a why we prefer not to hard-code magic numbers in these enlightened times.

Posted 29-Dec-14 10:39am

PIEBALDconsult

Updated 29-Dec-14 11:18am

v3

Comments

RedDk 29-Dec-14 16:59pm

11111111111111111111111111100001 is -31

PIEBALDconsult 29-Dec-14 17:07pm

Hmmm, odd, I get different representations from different sources, I suspect you're correct -- updated.

reeselmiller2 29-Dec-14 22:54pm

Thanks for your solution PIEBALDconsult. This pointed me in the right direction and I understand how that section of code is used now.

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-12-29T21:06:00

reeselmiller2 wrote:

Thanks for the reference. This is part of my confusion. The flag is a ulong and can have a value like 18446744073709551583 which converts to a decimal -33, works fine in C#. But in VB if you try "i As Integer = CInt(18446744073709551583UL) you get an overflow error. So you have to use something like Decimal.GetBits(18446744073709551583D)(0) which gives you the low 32bits of the 96 bit Integer. I agree the code is horrible, just trying to understand why it is written this way.

First of all, I believe you cannot understand why some horrible code is horrible; well, someone acted in a sloppy way, so what? :-)

Maybe I can explain the confusing part. Consider these facts: the flag is ulong, but still, bitwise operations in .NET are done on enumeration and integer types converted to a widest type in binary sense of it; in particular, the signed semantic is completely ignored. I advised you to read about two's complement not just for general education, but more for understanding of its main idea: it allows the CPU to remain agnostic about the type of the operands of the arithmetic operations (not just logical, but even +, -, *, /): the CPU instruction operates on bits in the same exact way, no matter if one or both operands are signed or not. Are you getting the idea? The signed vs unsigned is the matter of interpretation of the arithmetic result in semantic way (in this case, from the standpoint of the integer value in mathematical sense of this notion) while the actual bits remain the same. Of course, same goes for the bitwise arithmetic. For example, for 16-bit integers ushort 0xFFFF is the same object as short -1, and so one; in terms of bits, and CPU cannot "see" any difference.

Now, overflow error comes from the attempt of type case from a wider type to a narrower type, when a value is beyond the range of the wider type. This kind of cast is semantic and not bitwise. That is, the signed nature of the number and its mathematical semantics is taken into account. ("Bitwise cast", in C++, is called reinterpret_cast. In .NET, it is done via the class System.BitConverter: http://msdn.microsoft.com/en-us/library/system.bitconverter%28v=vs.110%29.aspx[^].)

As to the method, System.Decimal.GetBits, it just does what it does. Actually, it returns not 32-bit value, but an array of 4 32-bit integers, as described here: http://msdn.microsoft.com/en-us/library/system.decimal.getbits%28v=vs.110%29.aspx[^].

(I don't know why would you concern about this method. :-))

—SA