Coding Style Question - Is there any sane reason for doing this?

[Bill Davy]

Are you saying that 040 is more difficult to read than 0x20? Just
checking...

V

O40 loks like a number, but is not.

 

[none]

Only two small quibbles... it was not at all clear to me what this was
supposed to indicate. Now that I know the secret handshake, it makes
more sense. And doing it in HEX is no problem at all, at least for me.
Maybe it is the dinosaur in me.

0x0002 or 0x0008 is rather trivial and does not cause me to stop.
However, when the bitmask becomes used for multiple things, then I
would say that the following reads trivially while a pure hex based
implementation would force me to stop and start to very carefully
count bits:

const unsigned wakeupBit = 1;
const unsigned someOtherBit = 2;
....
const unsigned superBit = 13;
....
const unsigned hyperBit = 23;
const unsigned gigaBit = 24;
....
const unsigned ultraBit = 29;

const uint32_t theMask = (1u<< wakeupBit)
& (1u<< someOtherBit)
& (1u<< superBit)
& (1u<< hyperBit)
& (1u<< gigaBit)
& (1u<< utraBit) ;

followed elsewhere by:

if( theMask & superBit ) ...


Yannick

 

[none]

0x0002 or 0x0008 is rather trivial and does not cause me to stop.
However, when the bitmask becomes used for multiple things, then I
would say that the following reads trivially while a pure hex based
implementation would force me to stop and start to very carefully
count bits:

const unsigned wakeupBit = 1;
const unsigned someOtherBit = 2;
...
const unsigned superBit = 13;
...
const unsigned hyperBit = 23;
const unsigned gigaBit = 24;
...
const unsigned ultraBit = 29;

Arggh!!! Obviously | not &

 

[hanukas]

"Bill Davy"  wrote in message


Ox20 looks like a number, but it is not. l00 looks like a number, but it is
not. What is your point?

I guess he meant base-10 decimal number? The leading zero is the tip-
off for C/C++ programmers that it's octal.

 

[Juha Nieminen]

I suspect others write 'unsigned int' because they believe verbosity
increases readability. I remember I did that very early in my career.

I have the exact opposite experience: Most noobs believe that verbosity
decreases readability, and thus proceed to write what effectively is
obfuscated C++.

Unfortunately, even some experienced professionals have this
misconception.

 

[Victor Bazarov]

I have the exact opposite experience: Most noobs believe that verbosity
decreases readability, and thus proceed to write what effectively is
obfuscated C++.

Unfortunately, even some experienced professionals have this
misconception.

<shrug>

Read quickly: Raedablity is a mtater of ahbit and is'nt guiedd by eaxct
precpetpion; itis fzuzy.

You managed to read the line above, didn't you? It's the same way with
the source. 'unsigned int' or 'unsigned' doesn't really matter for
readability. A quick glance gives all the information one needs.
However, when it comes to bits and their positions, it's different. I
guess, it all comes down to the degree of complexity and one's knack to
read (comprehend) what others might consider obscure, like hexadecimals
or octals.

Here is another example. In our codebase we have tons of flags, most of
which have symbolic representation. That representation hasn't changed
in years. Yet, I can't read the value 0x29020 (only four bits, mind
you) and quickly figure out what bits are set. So, for debugging (and
only for debugging) I wrote a decoder function that displays the value
in the symbolic form... And in the code the value is never written as a
number. It's the debugging that presents a problem, AFAIC.

V

 

[Joe keane]

Why not use octal? Saves you typing an "x". After all, the creators of C
were quite happy with octal for expressing low level bit patterns.

'we don't do that'

Virtually all computers now have eight-bit bytes. It is a common data
type, what the other data types are made of, and probably the unit of
address. It's so much nicer when the radix bits are a fraction of this.

Dump sone memory in words then interpret it in bytes, or vice versa.

 

[David Dyer-Bennet]

No, I'm saying that I can look at 0x12345678 and visually determine which
bits are set in which bytes. It's much more complicated for 02215053170.

Whereas for me it's the opposite.

But wait -- what you have memorized, to decode the hex, is a superset of
what I know to decode the octal. How, then, can it be "much more
complicated" to decode the octal? It involves decoding more digits, so
I can't argue against "slightly more work" or something like that. But
the principles are identical, and the tables needed in memory are a
subset of the hex tables.

On the other hand, when I was writing PAL-D code for the pdp8, 4 digit octal
numbers worked just fine due to the 12-bit word.

Yep, that's where I learned to do octal. Actually toggling in the RIM
loader is where I learned to do octal.

 

[Nick Keighley]

On 10.01.2012 09:30, Nick Keighley wrote:

Why not use octal? Saves you typing an "x". After all, the creators of C
were quite happy with octal for expressing low level bit patterns.

I've used both in the past. Hex is more compact and fits better to 8,
16 and 32 bit quantities. But i suspect you know this.

 

[BCFD36]

I've used both in the past. Hex is more compact and fits better to 8,
16 and 32 bit quantities. But i suspect you know this.

Never try to play Blackjack when you have been working in octal for 3
years. It can mess with the math. Balancing a checkbook can get a little
dicey too.