binary format of the number.

[J.W.]

In c++, we can use hex format to represent a number, for example, for number
70, we can use 0x46, but is there a way to represent a number using the
binary format, something similar to 0x.

Thanks,
J.W.

 

[Erik Wikström]

In c++, we can use hex format to represent a number, for example, for number
70, we can use 0x46, but is there a way to represent a number using the
binary format, something similar to 0x.

No, but you can use octal if you like, all numbers starting with 0 are
considered to be in octal form.

 

[Sherm Pendley]

In c++, we can use hex format to represent a number, for example, for
number 70, we can use 0x46, but is there a way to represent a number
using the binary format, something similar to 0x.

Oddly enough, no there isn't. We can declare hex-format literals with a
leading 0x, and octal-format with a leading 0, but there's no standard
way to declare a binary-format literal.

That's always seemed to me a strange thing to omit from the language.

sherm--

 

[Bill]

In c++, we can use hex format to represent a number, for example, for
number 70, we can use 0x46, but is there a way to represent a number using
the binary format, something similar to 0x.

Thanks,
J.W.

0x is designed as a shortcut--so that you don't have to do that, sort of
like specifiying C-style character strings with double-quotes. "Octal" is
also provided, as you may know, by omitting the x in 0x.

Why would you prefer to write down strings of 0s and 1s anyway? Seems like
it would increase your chance of error. If you really wanted to, you could
write your own function which translates binary character strings to an
integral data type. For instance, int binary2Int(const char *).

Bill

 

[Stefan Ram]

We can declare hex-format literals with a leading 0x

The verb »declare« already has a specific meaning in ISO/IEC
14882:2003(E), but this meaning does not apply in this case.

 

[Stefan Ram]

all numbers starting with 0 are
considered to be in octal form.

Numbers like »0.24« or »0x24«?

(Actually, numbers never start
with »0«, but literals might.)

 

[Tarmo Kuuse]

Why would you prefer to write down strings of 0s and 1s anyway? Seems like
it would increase your chance of error. If you really wanted to, you could
write your own function which translates binary character strings to an
integral data type. For instance, int binary2Int(const char *).

When working at low level (embedded, device drivers, ...), bit fields
are scattered throughout code. It is quite annoying to convert binary to
hexadecimal and vice versa for 32-bit values.

Let's see now, is bit 22 set in mask 0x03C00000? OK, give me a minute...

 

[Bill]

When working at low level (embedded, device drivers, ...), bit fields are
scattered throughout code. It is quite annoying to convert binary to
hexadecimal and vice versa for 32-bit values.

Let's see now, is bit 22 set in mask 0x03C00000? OK, give me a minute...

I think I would be MUCH less likely to make an error typing in hexadecimal
strings. The idea of typing in a string with a single 1 in the 22nd place
gives me a headache just thinking about it. I would need to
quadruple-check it. In hex, I would only need to double-check it.
Depending on the storage requirements I might prefer an array whose members
of type bool---then there is no ambiguity about what is meant by the 22nd
bit.

Bill

 

[Kai-Uwe Bux]

I think I would be MUCH less likely to make an error typing in hexadecimal
strings. The idea of typing in a string with a single 1 in the 22nd
place
gives me a headache just thinking about it. I would need to
quadruple-check it. In hex, I would only need to double-check it.

[snip]

I agree, but that is only because we are dealing with 32bit numbers. With
8bit numbers, things are different. I can see which bits are set in

01001110

right away. With a hex number such as

d3

I have to think, which is a BadThing(tm).


Best

Kai-Uwe Bux

 

[James Kanze]

I think I would be MUCH less likely to make an error typing
in hexadecimal strings.   The idea of typing in a string
with a single 1 in the 22nd place gives me a headache just
thinking about it.   I would need to quadruple-check it.  In
hex, I would only need to double-check it.

[snip]

I agree, but that is only because we are dealing with 32bit
numbers. With 8bit numbers, things are different. I can see
which bits are set in

  01001110

right away. With a hex number such as

  d3

I have to think, which is a BadThing(tm).

Does it really matter? Depending on use, sometimes one, and
sometimes the other, may be easier. If C++ were to add binary
literals, it certainly wouldn't require their use; you'd use
whichever one seemed appropriate to the context.

I suspect that the main reason C++ doesn't support binary
literals is because C doesn't, and the main reason C doesn't is
because no one has proposed them to the committee.

 

[Gennaro Prota]

I suspect that the main reason C++ doesn't support binary
literals is because C doesn't, and the main reason C doesn't is
because no one has proposed them to the committee.

They were proposed for C++, as early as in 1993, together with
other lexical-related improvements (n0259). I don't know why
they were rejected, but the general committee attitude seems to
be way less conservative now: in fact, the current draft allows
defining a "literal operator" (which is not an operator; very
bad naming), such as:

unsigned long operator "" b( char const * ) ;

or a "literal operator template":

template< class ... Types >
unsigned long operator "" b() ;

and have whichever of them you define called for literals with
the b suffix:

11000111b

Hmm.

 

[James Kanze]

They were proposed for C++, as early as in 1993, together with
other lexical-related improvements (n0259). I don't know why
they were rejected,

Probably because it's not in C. Pretty much everything
regarding integral types is the responsibility of C, and C++
just adopts whatever C decides. (At least, that's the way it
should be.)

but the general committee attitude seems to be way less
conservative now: in fact, the current draft allows defining a
"literal operator" (which is not an operator; very bad
naming), such as:

   unsigned long operator "" b( char const * ) ;

or a "literal operator template":

   template< class ... Types >
   unsigned long operator "" b() ;

and have whichever of them you define called for literals with
the b suffix:

   11000111b

This has to be a joke, right.

 

[George Kettleborough]

When working at low level (embedded, device drivers, ...), bit fields
are scattered throughout code. It is quite annoying to convert binary to
hexadecimal and vice versa for 32-bit values.

Let's see now, is bit 22 set in mask 0x03C00000? OK, give me a minute...

For bit fields wouldn't it be a lot easier to use vector<bool>?

 

[Bill]

For bit fields wouldn't it be a lot easier to use vector<bool>?

Easier for the programmer or the processor? I suspect that people who write
software for embedded devices avoid such data strucutres. I could be wrong.

Bill

 

[Triple-DES]

  Google found me n1511 and n1892. I haven't look what status
  they have, though.

They are in the latest WP (n2798).

 

[Michael DOUBEZ]

J.W. a écrit :

In c++, we can use hex format to represent a number, for example, for
number 70, we can use 0x46, but is there a way to represent a number
using the binary format, something similar to 0x.

There is not but you can make one.
This not a trivial task ; have a look at this article:
http://accu.org/index.php/journals/350

It shows how to implement it.
I guess you can copy/paste the relevant code (with credit to the author
perhaps ).

 

[Nick Keighley]

In c++, we can use hex format to represent a number, for example, for number
70, we can use 0x46, but is there a way to represent a number using the
binary format, something similar to 0x.

no.

I've sometimes used string constants for readability
and converted them to unsigned int for use.

const char* io_mask_string = "0101 1111";
unsigned char io_mask = load_from_string (io_mask_string);

obviously you could suger the syntax a bit more

 

[Tarmo Kuuse]

Is bit 22 set in this mask? OK, give me a minute...

00000011110000000000000000000000

Point not valid. Small things - such as grouping - make a big difference.

Yes, slowly the brain rewires itself to natively process the hexadecimal
system. Until it does, however, bugs run rampant.

How about this one? Simple, yes.

(1L << 25) | (1L << 24) | (1L << 23) | (1L << 22)

This is a workaround, not provided by the language.

Many intelligent programmers (eventually) use it. And many do not. It's
a mess out there.

If you really want binary, you can write a macro (or template) that
accepts four 8-bit chunks, something like
BIN(00000011,11000000,00000000,00000000).

Can you point to a sound compile time implementation of such
macro/template? I'd be interested.

 

[Michael DOUBEZ]

Tarmo Kuuse a écrit :

Can you point to a sound compile time implementation of such
macro/template? I'd be interested.

Sorry, ignore my previous post. I thought you wanted to output it in a
stream in bin format.

With binary defined as follow:

template<typename T=unsigned,int nbbit=8>
struct binary
{
//initialize octet with binary form long
binary(long v)
{
T exp=1;
val=0;
//ensure v in range 0 11111111
v%=11111112;
//build value
while(v)
{
ldiv_t d=ldiv(v,10); //ldiv from stdlib.h C99
v=d.quot;
if(d.rem)val|=exp;
exp*=2;
}
}

//initialize octet with pre-computed value
struct value
{
T val;
value(T v):val(v){}
};
explicit binary(const value& v):val(v.val){}

operator T()const{return val;}

T val;
};

//concatenate binaries
template<typename T,int nbbit_lhs,int nbbit_rhs>
binary<T,nbbit_lhs+nbbit_rhs> operator<<(
const binary<T,nbbit_lhs>& lhs,
const binary<T,nbbit_rhs>& rhs)
{
typedef binary<T,nbbit_lhs+nbbit_rhs> binary_type;
return binary_type(
typename binary_type::value(
(lhs.val<<nbbit_rhs)|rhs.val
)
);
}

Example:
std::cout<<(binary<>(1)<<binary<>(101))<<std::endl;
int cons=binary<int>(10000000)binary<int>(0);

You can improve of the template expression such as:
* binary(int val,int number) to build representation of number with
only 0s or 1s in a given number at given position.
* using fills fill<int,24>(1) -> 111...11 24 bits

And so on.

 

[jl_post]

In c++, we can use hex format to represent a number, for example, for number
70, we can use 0x46, but is there a way to represent a number using the
binary format, something similar to 0x.

No way that I know of in C/C++, but for the record, it can be done
in Perl this way:

0b1000110

or even:

0b0100_0110

(I know this is slightly off-topic, but I thought it worth
mentioning.)

(In case you're wondering, Perl allows the '_' character to be
interspersed in a number, much like we use commas/periods to make big
numbers more readable.)

This has been useful for me several times, as in the past I've had
to check if a byte-value has its second (or third, or fourth...) bit
set. So my code would look like:

if ($byteValue & 0b0100_0000) # check if the second bit is set
{
...
}

Unfortunately, C++ does not support this syntax, so until it does,
I would port the above code from Perl to C++ using hexadecimal values,
like this:

if (byteValue & 0x40) // check if the second bit is set
{
...
}

(Notice that I still keep the comment. Otherwise, the maintainer
who comes after me will have no easy way of knowing if 0x40 has the
bits I intended to check, or if I accidentally created a bug in the
code.)

Of course, you could port that code using octal (by saying
"byteValue & 0100") which isn't really any better or worse than using
hexadecimal. The only difference is that you may have an easier time
with one than the other.

If converting to octal or hexadecimal still leaves a sour taste in
your mouth, your best bet would probably be to write your own function
that takes an input string of 1s and 0s and returns an unsigned long
integer (like some other posters in this thread have suggested). Then
you can write code like this:

if (byteValue & fromBinary("0100 0000")) // check if the second
bit is set
{
...
}

So using hexadecimal, octal, or your own function are three
different "work-arounds" to specifying a binary literal.

I hope this helps, J.W.

-- Jean-Luc