Colon initialiser?

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

[Chris Dollin]

al*********@gmail.com wrote:

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.

--
Chris "electric hedgehog" Dollin
Scoring, bah. If I want scoring I'll go play /Age of Steam/.

[alan.larkin]

On Jan 24, 2:48 pm, Chris Dollin <[e-mail]:

[e-mail] wrote:

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.

Ah, good thinking. Thanks.

[santosh]

al*********@gmail.com wrote:

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.

[Walter Roberson]

In article <11**********************@s48g2000cws.googlegroups .com>,
santosh <sa*********@gmail.comwrote:

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

--
Prototypes are supertypes of their clones. -- maplesoft

[Ben Pfaff]

"santosh" <sa*********@gmail.comwrites:

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).
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

[santosh]

On Jan 24, 10:23 pm, Ben Pfaff <[e-mail]:

"santosh" <[e-mail]:

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.

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?

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

santosh wrote:

On Jan 24, 10:23 pm, Ben Pfaff <[e-mail]:

"santosh" <[e-mail]:

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.

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.

[Clark S. Cox III]

santosh wrote:

>
On Jan 24, 10:23 pm, Ben Pfaff <[e-mail]:

>"santosh" <[e-mail]:

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

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
--
Clark S. Cox III
cl*******@gmail.com

[Stephen Sprunk]

"santosh" <sa*********@gmail.comwrote in message
news:11**********************@h3g2000cwc.googlegro ups.com...

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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

"Stephen Sprunk" <st*****@sprunk.orgwrites:

"santosh" <sa*********@gmail.comwrote in message
news:11**********************@h3g2000cwc.googlegro ups.com...

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Stephen Sprunk]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Stephen Sprunk" <st*****@sprunk.orgwrites:

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

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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com