Question

During debug, why is it when you look at a GUID object, there are strange variables inside the non-public members? This is what is shown in my debug for:

guid={7b15cd1-69f3-e2111-bd64-001dd8b82a4f}

_a  = 2065026481
_b = 27123
_c = -7663
_d = 189
_e = 100
_f = 0
_g = 29
_h = 216
_i = 184
_j = 42
_k = 79
Was it helpful?

Solution

guid={7b15cd1-69f3-e2111-bd64-001dd8b82a4f}

_a  = 2065026481 // = 7b15cd1
_b = 27123 // = 69f3
_c = -7663 // = e2111
_d = 189 // = bd
_e = 100 // = 64
_f = 0 // = 00
_g = 29 // = 1d
_h = 216 // = d8
_i = 184 // = b8
_j = 42 // = 2a
_k = 79 // = 4f

OTHER TIPS

It is not that strange. Fire up the Windows calculator by running Calc.exe. Click View + Programmer to select the built-in StackOverflow User Mode. Type '2065026481' and click the Hex radio button. Notice the similarity to the first part of the {guid} value.

Repeat for the other parts, you'll see the match.

Hexadecimal is the programmer's way to count with 16 fingers instead of 10. Having 16 fingers is a much better match for the way computers are built. They use a power of 2, not 10. Just ones and zeros, one hex digit covers 4 bits.

The bigger conclusion to draw from this is that a Guid is not just a random number. It is made up from parts. Those parts have a meaning, you can read RFC 4122 if you want to get to the bottom of it. Which is a good idea if you want to learn the way the machine works. Every carpenter should know how a hammer works. But they have to understand the nail first, I recommend this book to know what the nail looks like.

I don't know the entire mapping of the GUID, but those internal variables are just representing the parts of the entire GUID. The difference is that the debugger is showing _a, _b, etc in base 10, whereas the GUID is showing in hexadecimal.

In your example, if we look at the last two parts, they map to the last 4 digits of the guid.

_j = 42 (Dec) 2a (Hex)
_k = 79 (Dec) 4f (Hex)
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top