# binary format of the number.

Discussion in 'C++' started by J.W., Nov 27, 2008.

1. ### J.W.Guest

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.

J.W., Nov 27, 2008

2. ### Erik WikstrÃ¶mGuest

On 2008-11-27 19:03, J.W. wrote:
> 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.

--
Erik WikstrÃ¶m

Erik WikstrÃ¶m, Nov 27, 2008

3. ### Sherm PendleyGuest

"J.W." <> writes:

> 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--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

Sherm Pendley, Nov 27, 2008
4. ### BillGuest

"J.W." <> wrote in message
news:492ee0d4\$0\$90269\$...
> 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

Bill, Nov 27, 2008
5. ### Stefan RamGuest

Sherm Pendley <> writes:
>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, Nov 27, 2008
6. ### Stefan RamGuest

=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?= <> writes:
>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.)

Stefan Ram, Nov 27, 2008
7. ### Tarmo KuuseGuest

Bill wrote:
> 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...

--
Tarmo

Tarmo Kuuse, Nov 28, 2008
8. ### BillGuest

"Tarmo Kuuse" <> wrote in message
> Bill wrote:
>> 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...
>
> --
> Tarmo

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

Bill, Nov 28, 2008
9. ### Kai-Uwe BuxGuest

Bill wrote:

>
> "Tarmo Kuuse" <> wrote in message
>> Bill wrote:
>>> 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...
>>
>> --
>> Tarmo

>
> 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

Kai-Uwe Bux, Nov 28, 2008
10. ### James KanzeGuest

On Nov 29, 12:09 am, Kai-Uwe Bux <> wrote:
> Bill wrote:
> > "Tarmo Kuuse" <> wrote in message
> >> Bill wrote:
> >>> 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....

> > 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.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze, Nov 29, 2008
11. ### Gennaro ProtaGuest

James Kanze wrote:
> 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

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.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

Gennaro Prota, Nov 29, 2008
12. ### James KanzeGuest

On Nov 29, 4:53 pm, Gennaro Prota <gennaro/> wrote:
> James Kanze wrote:
> > 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,

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.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze, Nov 29, 2008
13. ### George KettleboroughGuest

On 28/11/08 09:19, Tarmo Kuuse wrote:
> Bill wrote:
>> 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...

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

--
George Kettleborough

George Kettleborough, Nov 29, 2008
14. ### BillGuest

"George Kettleborough" <> wrote in message
news:7riYk.16560\$2...
> On 28/11/08 09:19, Tarmo Kuuse wrote:
>> Bill wrote:
>>> 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...

>
> 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

>
> --
> George Kettleborough

Bill, Nov 30, 2008
15. ### Triple-DESGuest

On 30 Nov, 12:50, Hendrik Schober <> wrote:
> James Kanze wrote:
> > On Nov 29, 4:53 pm, Gennaro Prota <gennaro/> wrote:
> > [...] 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.

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

They are in the latest WP (n2798).

Triple-DES, Dec 1, 2008
16. ### Michael DOUBEZGuest

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.
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 ).

--
Michael

Michael DOUBEZ, Dec 1, 2008
17. ### Nick KeighleyGuest

On 27 Nov, 18:03, "J.W." <> wrote:

> 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";

obviously you could suger the syntax a bit more

--
Nick Keighley

Nick Keighley, Dec 1, 2008
18. ### Tarmo KuuseGuest

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

>
> 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.

>
> (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.

--
Kind regards,
Tarmo

Tarmo Kuuse, Dec 1, 2008
19. ### Michael DOUBEZGuest

Tarmo Kuuse a écrit :
> blargg wrote:
>> 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.

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.

--
Michael

Michael DOUBEZ, Dec 1, 2008
20. ### Guest

On Nov 27, 11:03 am, "J.W." <> wrote:
>
> 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

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
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
{
...
}