Proposal: use hex numbers in bitwise operations

[greenozon]

ILSpy version 6.0.0.5369-alpha1

Right now it looks a bit funny, despite it is OK from compiler point of view
but having hex numbers the readablity will be much bigger I guess

ref to class BaseTypes.ChannelID for example

public ushort Position
	{
		get
		{
			return (ushort)((ulong)((long)m_TransponderID & -281474976710656L) >> 48);
		}
		set
		{
			m_TransponderID = ((m_TransponderID & 0xFFFFFFFFFFFF) | ((ulong)value << 48));
		}
	}

		public int Frequency
		{
			get
			{
				return (int)(m_TransponderID & int.MaxValue);
			}
			set
			{
				m_TransponderID = (ulong)(((long)m_TransponderID & -2147483648L) | value);
			}
		}

Proposal is to use hex at least in bitwise &, | and ^ operations..

etc

https://www.sendspace.com/file/4obei6

[siegfriedpammer]

Sorry, I did not download the binary you are refering to. As far as I know, we already use hex numbers in combination with bitwise operators. Would be interested in seeing the concrete examples, where our algorithm does not work properly. Thanks!

[greenozon]

Well, I tried it on the version ILSpy version 6.2.0.6084-preview1

still see same output..
Also "& int.MaxValue" might look better if using hex numbers...

ref to public class Test_bitwise_ops inside
ILSPY_testa.zip

[siegfriedpammer]

Also "& int.MaxValue" might look better if using hex numbers...

I have made some modifications:

// ILSPY_testa.Test_bitwise_ops
public int Frequency
{
	get
	{
		return (int)(m_TransponderID & 0x7FFFFFFF);
	}
	set
	{
		m_TransponderID = (ulong)(((long)m_TransponderID & 0xFFFFFFFF80000000L) | value);
	}
}

I agree that 0x7FFFFFFF looks better than int.MaxValue in the context of bit-masking. However I am unsure in the case of negative values... is 0xFFFFFFFF80000000L better than -2147483648L, which is int.MinValue? My bad, it turns out that using hexadecimal notation for values < 0 turns them into unsigned literals, which leads to compile errors.

[greenozon]

well, I guess for each and every bit operation hex would work the best (as it shows a kind of bit but decimal would be definitely not fine :)
IMHO

[siegfriedpammer]

@dgrunwald Would it be possible to prefer unsigned types over signed types in the case bit and, bit or and xor? This would allow to use hexadecimal notation in every case.

[dgrunwald]

I don't think bit operations should cast to unsigned types in general.
But the assignment to m_TransponderID of type ulong should already pass in TypeHint = ulong into the translation; so I'd expect that type to be used.