Longer Bit Contants, Please

What you’re asking to be changed is part of the C/C++ language specification, which is (far) outside of the ability of Arduino to do anything about.

No. In no way did I ask for the C/C++ Specification to be changed.

What I have asked, amounts to adding a few lines of Arduino IDE pre-processor code, so that users can more-easily conserve precious microctontroller memory.

If that threaten everything your know about programming, I am sorry.

What the code would do during compiling is: remove the spaces between the binary constant operator, and the first semicolon it sees.

Also, you may notice that Arduino’s language deviates greatly from C/C++, with many additions pertaining to hardware, but in other ways such not requiring pointers, and the use of Const over the preprocessors DEFINE, as used for the Arduino’s semi-Harvard optimization.

None of those are “deviations” from C/C++. Allowing spaces in numeric constants would be…

remove the spaces between the binary constant operator, and the first semicolon it sees.

It’d be a lot more complicated than that.
output = (flags & 0b1000 1000) ? "bits 7;3 are set" : "not set";

If I were programming the preprocessor…when saw the binary operator, I would seek the next semicolon delimiter, and loop back, cascading, and shifting the characters to the left, eliminated the spaces–until the semicolon delimiter is seen again, and then update the line’s character delimiter.

It’s only complicated if you need it to be. Thepointtothisthreadwasinincreasecodereadability.

[This may or may not be correct that 0b might only take 8-bits.
Arduino - IntegerConstants]

0b is a gcc (and many others) extension of C, and should work up through 64bit constants.

Bxxxxxxx are a set of macros provided by the Arduino team (before they noticed 0b, I think), and they only go up through 8 bits.

I am getting some bus transceivers, and thought about parallel buses.

I am not the only person who separates their nibbles.

JohnWasser suggested a function, and I posted a macro that does something, but you haven’t really weighed in on whether those are acceptable or not…

With C++14 (which Arduino is currently NOT using, you could use a constexpr function that would allow:

         B("0000 1000 0100 0010"),
         B("1100 1010 0101 1111"),
         B("1111 1000 1111 0010"),
void Bad_Binary_Constant(void) __attribute__ (( error("") ));

constexpr uint32_t B (const char *s) {
  uint32_t n = 0;
  while (*s) {
    if (*s == '1') {
      n = (n<<1) + 1;
    } else if (*s == '0') {
      n = n<<1;
    } else if (!(*s == ' ' || *s == '_')) {
  return n;

Well, in a way, I appreciate the code, but that's not the solution I am asking for.

I asked for a small improvement the the Arduino pre-processor , which might only be 15 lines, if done similarly as the code above--in the interest of good code legibility and memory savings.

I don't think it's a valid argument to hide behind which version of C/C++ Arduino is using, because I seriously doubt that those standard libraries and syntax include: pinMode, digitalWrite, and so-forth.

Sometimes people use certain bits for certain things. These things are micro-controllers. We also make masks, and it's easier to see your binary mask if it is in binary--than hex.

Has anyone seen a CRC explanation done entirely in Hex?

Unfortunately, without optimizations (-O0), this code fails to compile. In C++20, you could use consteval instead of constexpr, which would work in this case (because it's always evaluated at compile time, it doesn't have to generate a version of the function that could be called at runtime).

Instead of calling the function B it could be nice to use a user-defined literal:

consteval uint32_t operator""_2 (const char *s, unsigned long len) {
  uint32_t n = 0;
  while (len --> 0) {
    if (*s == '1') {
      n = (n<<1) + 1;
    } else if (*s == '0') {
      n = n<<1;
    } else {
      assert(*s == ' ' || *s == '_');
  return n;

This allows you to write:

"0101 1100 1010 0011"_2

Run this code online: Compiler Explorer

How would it save any memory?

This is completely different from functions like pinMode, these are just ordinary C++ functions, not special keywords defined by the C++ standard. The “Arduino Core” is simply a collection of standard C++ functions and classes.
What you're asking for is a much more fundamental change to the actual C++ syntax.

Arduino uses a standard C++ compiler, so you have to work with the version of C++ that is used by the Arduino configuration.
A further diversion from standard C++ by changing the Arduino preprocessor would be a terrible idea and would only cause confusion.
In hindsight I think even the basic function prototype generation it does right now was a mistake. It's not that hard to teach beginners to declare their functions before using them, just like for variables, and the slight advantage in beginner-friendliness is annulled by the fact that it completely breaks down as soon as you start defining types that are used in these function definitions.

If you're interested in the reason why the C++ committee decided to use apostrophes instead of spaces, see c++ - Why was the space character not chosen for C++14 digit separators? - Stack Overflow.

Personally, I prefer the look of apostrophes over spaces, but even if it were the other way around, I would prefer Arduino stuck to the standard, the tiny change in readability wouldn't make up for the inconvenience of creating a new non-standard C++ dialect.

Sure, that's why GCC and C++14 support the 0b prefix for integer literals. If you want a separator between nibbles, use apostrophes and C++14.

If any Arduino devs are reading this: Please add this to the list of reasons for updating the platform files to C++17 (or at least C++14). C++14 removed many restrictions on constexpr functions, which is really useful, especially in an embedded context. And the binary literals with digit separators are a nice feature as well.

My understanding was that, at the time the macros were created, GCC did not have binary literals.

The note here indicates they were added in GCC 4.3. I don't know what is the history of GCC versions used by the Arduino IDE in the olden times though.

As you can see here, there has been a concerted effort to deprecate those macros and to replace their use in the documentation:

The preprocessor currently only does two things to the code:

  • Generate function prototypes
  • Add #include <Arduino.h>

So adding one more is actually a very significant increase in the scope, and also opens the door to further deviations from real C++. The things that might seem simple at a glance can turn out to be very complex once you start taking into account all the corner cases. A huge amount of work has gone into the function prototype generation system, with at least three complete reworkings, yet it still fails in some cases.

Once again, I am asking for a small change in the compilers.

The current situation is not that dissimilar that the poorly made Internet forms which cannot parse your credit card number if it has spaces.

Like it or not, Arduino's non-standard language became its own language. Either it will remain a living language--or become a dead one.

The Arduino "language" is not non standard, rather it provides extension to standard C++ to suit it's use case. As such it will not die

I doubt there is such a thing as a small compiler change. This will affect all developers in the Arduino community. It will allow them to write code that will be incompatible with compilers without that change. It might also break something else and therefore will likely require some serious testing.

If you do not like the way the compiler works, I suspect you could create your own version of the compiler or some pre-processor/ code generator.

I would vote against anything like this

You could do what generation of developers did with old versions of the compiler and just type in the readable format as a comment…

We don’t need to depart from the standard language and compiler. When Arduino will move to a more recent C++ version then you’ll get what the standard allows for.

This requires explanations… care to explain ?

.... somewhere during runtime;

myByte = myDeCipher( "my formatted text" );

and yeah -- been there, done that for user-IO.

Now that the functions and macros have been provided, I'll cast black magic.
Not highly recommended. :crazy_face:

unsigned long operator"" _isBin(const char* c,size_t s){unsigned long x=1,y=0,z=0;
while(y++<=s){switch ((char)(*(c+s-y))-0x30){case 1:z+=x;case 0:x<<=1;}}return z;}

void setup()
  Serial.println("1010 1011 1100 1101 1110 1111"_isBin, HEX);
  Serial.println("  11 0000 0011 1001"_isBin, DEC);

void loop() {}

EDIT: It's a joke. :roll_eyes:

chrisknightley, I guess you didn't read what I wanted.

I wanted the ability to separate binary numbers by either the byte or nibble, when setting variables and constants--as a means of increasing readability.

Arduino's syntax and usage is not all the standard. Arduino doesn't require pointers, which deviates from C. Also, looking at the documentation, there is very little information on Struct's, likely because the powers that be (you) want people to fall into OOP, which is not always best for the bit twiddling that happens on micro-controllers.

Syntactically, many of the methods visible to the Arduino programmer could have been naturalized to C syntax. Arduino as a language, feels like it was intended to be C-like, but then people took it over, and tried to make it something else.

I am just a lowly person who asked for a small change in the compilers to remove spaces from bitfield byte constants and variables.