Colon initialiser?

A

alan.larkin

Is anyone familiar with the following syntax?

<type> <id>:<expression>;

e.g.

double d:2+3;

Ive found it in a "standard C" grammar. gcc wont accept it.

Thanks.
 
C

Chris Dollin

Is anyone familiar with the following syntax?

<type> <id>:<expression>;

e.g.

double d:2+3;

Ive found it in a "standard C" grammar. gcc wont accept it.

I expect you'll find that piece of the grammar is there for
bitfields /inside structs/ eg:

struct example
{
unsigned c: 1;
unsigned v: 1;
unsigned z: 1;
unsigned p: 1;
};

The bitfield rule of thumb is: don't use them, unless you /know/
you need to use them.
 
A

alan.larkin

bitfields /inside structs/ eg:

struct example
{
unsigned c: 1;
unsigned v: 1;
unsigned z: 1;
unsigned p: 1;
};

The bitfield rule of thumb is: don't use them, unless you /know/
you need to use them.

Ah, good thinking. Thanks.
 
S

santosh

Is anyone familiar with the following syntax?

<type> <id>:<expression>;

e.g.

double d:2+3;

Ive found it in a "standard C" grammar. gcc wont accept it.

Thanks.

Thats to specify the width of a bitfield. Outside of a structure or
union, it's a syntax error.
Moreover, bitfields are always of type unsigned int. Particularly, they
cannot be a floating point type.
 
B

Ben Pfaff

santosh said:
Moreover, bitfields are always of type unsigned int.

No. From C99 6.7.2.1:

A bit-field shall have a type that is a qualified or
unqualified version of _Bool, signed int, unsigned int, or
some other implementation-defined type.
Particularly, they cannot be a floating point type.

This is true (for portable programs).
 
W

Walter Roberson

santosh said:
Moreover, bitfields are always of type unsigned int. Particularly, they
cannot be a floating point type.

"A bit-field shall have a type that is a qualified or unqualified
version of one of int, unsigned int, or signed int. Whether the
high-order bit position of a (possibly qualified) "plain" int bit-field
is treated as a sign bit is implementation-defined. A bit-field is
interpreted as an integral type consisting of the specified number
of bits."

So there you have it: bitfields can be signed int, and if the
qualifier "signed" is used explicitly, one of the bits is a sign
bit (whereas if "signed" is omitted, the field might be treated
as unsigned.)
 
S

santosh

A bit-field shall have a type that is a qualified or
unqualified version of _Bool, signed int, unsigned int, or
some other implementation-defined type.

Thanks to both you and Walter Roberson for the correction.

Incidentally, does the C standard define the size of the _Bool type,
and what would be the purpose of a bitfield of type _Bool, when _Bool
itself behaves like a single bit?
 
G

Guest

santosh said:
Thanks to both you and Walter Roberson for the correction.

Incidentally, does the C standard define the size of the _Bool type,

I don't believe it does.
and what would be the purpose of a bitfield of type _Bool, when _Bool
itself behaves like a single bit?

struct { unsigned i : 1; _Bool j : 1 } s = { 2, 2 };

s.i is zero, but s.j is one.
 
C

Clark S. Cox III

santosh said:
Thanks to both you and Walter Roberson for the correction.

Incidentally, does the C standard define the size of the _Bool type,

No, it doesn't.
and what would be the purpose of a bitfield of type _Bool, when _Bool
itself behaves like a single bit?

It doesn't just behave like a single bit when it comes to converting
values from other types. When a value is converted to _Bool *any*
non-zero value is interpreted as 1 (i.e. true):

struct
{
unsigned u:1;
_Bool b:1;
} foo;

foo.u = 42;
foo.b = 42;

//foo.u == 0
//foo.b == 1
 
S

Stephen Sprunk

santosh said:
Incidentally, does the C standard define the size of the _Bool type,
and what would be the purpose of a bitfield of type _Bool, when _Bool
itself behaves like a single bit?

A typical implementation will give _Bool the same representation as an
(unsigned?) int, which wastes a lot of space. Packing a bunch of 1-bit
_Bools into a structure means less space used, though usually at the
expense of performance. You'd need a _lot_ of _Bools before it made
sense to to that on modern machines, though one can argue that applies
to just about any use of bitfields.

S
 
K

Keith Thompson

Stephen Sprunk said:
A typical implementation will give _Bool the same representation as an
(unsigned?) int, which wastes a lot of space. Packing a bunch of
1-bit _Bools into a structure means less space used, though usually at
the expense of performance. You'd need a _lot_ of _Bools before it
made sense to to that on modern machines, though one can argue that
applies to just about any use of bitfields.

gcc, IBM's xlc, and Intel's icc all have sizeof(_Bool)==1. (Of
course, that's 1 byte, which happens to be 8 bits on all those
compilers.)
 
S

Stephen Sprunk

Keith Thompson said:
gcc, IBM's xlc, and Intel's icc all have sizeof(_Bool)==1. (Of
course, that's 1 byte, which happens to be 8 bits on all those
compilers.)

Hmm. I thought when I'd tested mine it was 4, but it's showing 1 now.
Still, a struct with 1-bit bool bitfields should still give you a
_minimum_ of a factor of eight improvement in storage space (i.e.
whatever CHAR_BIT is). And, as I said, that's unlikely to ever matter.

S
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top