Base prefix notation

First, let me start by saying I'm not intending to start a Holy War(tm) between coding styles. Just curious and think it might be a nice distracting conversation from dealing with brain-dead newb issues, (and us newbies might learn a thing or two).

I'm a rank beginner in C (let alone C++), so most of what I'm going on is from various examples strewn about the web. I've noticed two similar prefixes for Binary values, "Bnnnnnnnn" and "0bnnnnnnnn". Since both seem to work, so I suppose neither is specifically wrong. I was just wondering why someone would use one over the other. Is it mostly what was learned first, or is there a logical reason for the preference.

Personally, I think I prefer the "0bnnnnnnnn" notation because it mirrors the "0xnn" notation that I'm used to using for Hex. But I also see an argument that "B" is so significantly different from "0x" that it is easier to not confuse the two. I don't think that I've ever used (or had a reason to use) Octal, other than learning that it lends itself really well to 6bit processors much like Hex works well for 8 (and multiples thereof) processors. I'm not even sure how to notate octal in C/C++. Is there a prefix for decimal that no one uses (because, really, we are beings with 10 fingers so decimal is the natural default)?

(Side note about the "beings with 10 fingers" comment... Back when I used to wait tables I developed a finger counting method that, while is actually base 5 (1,2,3,4,10,11,12,13,14,20, etc...), I called "groups of 5" that I used for counting number of chairs or people in a room. Quickly move my fingers behind my back, and then when back in the safety of the waiter's station or kitchen count 25 for the left thumb, 5 for each left finger, and 1 for each right digit. To the customers it just looks like I'm standing there looking over the room with my hands behind my back. My short-term memory for numbers is so short, I needed to keep track on my fingers so I didn't loose count if someone asked me where the bathroom is... So much for base 10 being default...) :wink:

Bnnnnnnnn

Is an Arduino nicety, and only good for eight bits, I think, and not portable.

0bxxxxx is a supported C "standard" ( I confess, I do not know its true standing), so should be reasonably portable, and goes beyond eight bits.
Though why anyone would consider expressing a literal of more than four bits in binary is beyond me.

Personally, I think I prefer the "0bnnnnnnnn" notation because it mirrors the "0xnn" notation

But octal notation (leading zero) mirrors neither, and catches out many.

Edit:

Side note about the "beings with 10 fingers" comment

...but most people count on their fingers in unary. ( or up to 1023 for the binary-savvy)

'0b' denotes a binary litteral to the compiler. While the other is provided somewhere in the Arduino API support headers as per processor macros.

0bnnnnnnnn is C/C++

Bnnnnnnnn is a set of #defines in hardware/arduino/cores/arduino/binary.h:

#define B0 0
#define B00 0
#define B000 0
#define B0000 0
#define B00000 0
#define B000000 0
#define B0000000 0
#define B00000000 0
#define B1 1
#define B01 1
#define B001 1
...

If you want to be "proper", use 0bnnnnnnnn.

And base 5 is common in counting. I, II, III, IIII, IIII

AWOL:

Bnnnnnnnn

Is an Arduino nicety, and only good for eight bits, I think, and not portable.

0bxxxxx is a supported C "standard" ( I confess, I do not know its true standing), so should be reasonably portable, and goes beyond eight bits.
Though why anyone would consider expressing a literal of more than four bits in binary is beyond me.

Personally, I think I prefer the "0bnnnnnnnn" notation because it mirrors the "0xnn" notation

But octal notation (leading zero) mirrors neither, and catches out many.

Edit:

Side note about the "beings with 10 fingers" comment

...but most people count on their fingers in unary. ( or up to 1023 for the binary-savvy)

So... what is octal notation?

A 0 (zero) on the front.

unsigned char v = 0274;

So... what is octal notation?

But octal notation (leading zero)

0b is native to the compiler, much like 0x for hex, but it tends to be compiler specific whether that notation is actually supported and I don't believe it is part of the official c standard (gcc I believe does support it, which is the basis for many compilers). All of the Bnnn values are actually defined in a header file (binary.h in your Arduino core library folder). I imagine these were included for maximum compatibility between compilers (or maybe compatibility between programmers). It doesn't really matter which you use, as long as you have a compatible compiler or the right includes.
In terms of octal, C has a pretty stupid/confusing notation:

int x=035; <-- x is decimal 29!!!

It's particularly annoying as if you use 0's to try and align your numbers you get a nasty surprise e.g:

int c1=134;
int c2=120;
int c3=076; <--- This is troublesome
int c4=098; <--- Ahhhh!!!!!! (actually throws a compiler error!)
int c5=111;

EDIT: LOL, took a bit long typing that out :stuck_out_tongue:

majenko:
0bnnnnnnnn is C/C++

Bnnnnnnnn is a set of #defines in hardware/arduino/cores/arduino/binary.h:

#define B0 0

#define B00 0
#define B000 0
#define B0000 0
#define B00000 0
#define B000000 0
#define B0000000 0
#define B00000000 0
#define B1 1
#define B01 1
#define B001 1
...




If you want to be "proper", use 0bnnnnnnnn.

So (as AWOL says) the Arduino "nicety" is actually a kludge that one should probably avoid if one wants to develop good habits to use outside of ArduinoLand(tm). I'll keep my habit of converting "B" to "0b" when cleaning up examples that I'm learning from...

And base 5 is common in counting. I, II, III, IIII, IIII

Thinking back on it, that is probably where I got it from.

Edit: corrected quote tags... One of the few times I forget to preview my post, and I put a "/" in the wrong place...

AWOL:

So... what is octal notation?

But octal notation (leading zero)

D'oh! I should really read completely. All that slobber on my foot makes walking slippery. :wink:

AWOL:
Though why anyone would consider expressing a literal of more than four bits in binary is beyond me.

I've seen (and used) occasions where on a single byte the placement of the high bits is more important than the value. Particularly bit-masking for flags, it's easier (for me) to see the 6th, 4th, 2nd and 1st bits are high (counting 1-8 starting with LSb on the right) on 0b00101101 instead of 0x2D or 45 (let alone 055 (yes, I can learn)).

Sembazuru:
(Side note about the "beings with 10 fingers" comment... Back when I used to wait tables I developed a finger counting method that, while is actually base 5 (1,2,3,4,10,11,12,13,14,20, etc...), I called "groups of 5" that I used for counting number of chairs or people in a room. Quickly move my fingers behind my back, and then when back in the safety of the waiter's station or kitchen count 25 for the left thumb, 5 for each left finger, and 1 for each right digit. To the customers it just looks like I'm standing there looking over the room with my hands behind my back. My short-term memory for numbers is so short, I needed to keep track on my fingers so I didn't loose count if someone asked me where the bathroom is... So much for base 10 being default...) :wink:

There actually is a combination base-5 / base-10 method called "chisanbop".

Right fingers (except for thumb) = 1 unit per finger
Right thumb = 5 units
Left fingers (except for thumb) = 10 units per finger
Left thumb = 50 units

And as for losing track of numbers, I too am very distractable. Only for me it's not limited to numbers.
I wonder: why is it considered less socially acceptable to refuse to acknowledge someone who is interrupting you, than it is to interrupt someone? Why isn't the interrupter the "bad guy"?

int c3=076; <--- This is troublesome
int c4=098; <--- Ahhhh!!!!!! (actually throws a compiler error!)

I don't know why it always makes me crack up, but I love this comment in the 2nd edition of K&R:

Everyone's favorite trivial change: 8 and 9 are not octal digits

So pre-ANSI, your 098 might not have thrown an error, but I have no idea what it would do.

As for a leading zero for octal: I doubt that a worse piece of design in programming language syntax exists anywhere. Except maybe for those programming languages which number the months of the year from 0 to 11 (such as C and ECMAScript).

Let's see: I believe that the relevant rule in many programming languages (including the Arduino programming environment) goes like this:
Numbers with only decimal digits (0 through 9) are decimal.
Except if they begin with 0, in which case they are octal.
Except if they contain a decimal point, in which case they are decimal after all.
Please correct me if I am wrong.

Except maybe for those programming languages which number the months of the year from 0 to 11 (such as C and ECMAScript).

I believe if you read the C language standard, you will find not a single reference to months of the year, or how they should be subscripted.

The leading zero and 0x notation is only used for integers, so the presence of a decimal point changes the game so to speak.

While the months are not part of the language, they are part of the time.h suite of the standard library - which is defined byt he standard. K&R are very careful to point out that the months number represents the "months since January" (italics in original). Harbison and Steele point out the same distinction - which probably came from unix.

I guess I just don't get the hostility to zero-origin indexing.

AWOL:
I guess I just don't get the hostility to zero-origin indexing.

It is not hostility to zero-origin indexing so much as hostility to a gotcha. Programming is hard enough without gotchas.

As for zero-origin indexing: following your logic, why aren't the days within each month numbered starting from zero?

following your logic,

Read my sig :wink:

Because they are already numbered.

Note that the days of the week (tm_wday) are "days since sunday". (0-6)
Days of the year (tm_yday) are "days since Jan 1". (0-364/365)

Actually the day of the month one is the wired one since it is the only one not stated as x since y.