473,327 Members | 2,074 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

regarding bit fields

Hi Everyone,

We all know that bit fields are to be used within a structure, like

struct sample
{
int i:4;
}

However, is there any reason as to why it can only be specified only
within a structure or a union and why not standalone as,

int i:4;

Dec 13 '06 #1
3 1435
In article <11**********************@16g2000cwy.googlegroups. com>
<sa*****@yahoo.co.inwrote:
We all know that bit fields are to be used within a structure, like

struct sample
{
int i:4;
}

However, is there any reason as to why it can only be specified only
within a structure or a union and why not standalone as,

int i:4;
"Because Dennis said so", more or less.

(In other words, there is no fundamental reason bitfields could not
be applied to ordinary variables. Note, however, that there is no
"pointer to bitfield" type in C, so there *is* a fundamental reason
they could not be applied to arrays, at least not without first
adding "pointer to bitfield" types.)

Dennis Ritchie also once said that C's bitfields are "a botch and
a blemish". I have to agree: they are not supported "correctly"
at a high level (no arrays of bitfields, no pointers to bitfields,
and so on), and at the same time, they do not map usefully to
hardware or protocol needs (no control over underlying machine
representations, cannot span machine words, and so on). In other
words, their sole function is to specify representation -- in
this case, "number of bits in machine storage" -- yet they fail
to let you specify the representation *enough*.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Dec 13 '06 #2
On 13 Dec 2006 19:21:19 GMT, Chris Torek <no****@torek.netwrote in
comp.lang.c:
In article <11**********************@16g2000cwy.googlegroups. com>
<sa*****@yahoo.co.inwrote:
We all know that bit fields are to be used within a structure, like

struct sample
{
int i:4;
}

However, is there any reason as to why it can only be specified only
within a structure or a union and why not standalone as,

int i:4;

"Because Dennis said so", more or less.

(In other words, there is no fundamental reason bitfields could not
be applied to ordinary variables. Note, however, that there is no
"pointer to bitfield" type in C, so there *is* a fundamental reason
they could not be applied to arrays, at least not without first
adding "pointer to bitfield" types.)

Dennis Ritchie also once said that C's bitfields are "a botch and
a blemish". I have to agree: they are not supported "correctly"
at a high level (no arrays of bitfields, no pointers to bitfields,
and so on), and at the same time,
Up to here, I agree with you...
they do not map usefully to
hardware or protocol needs (no control over underlying machine
representations, cannot span machine words, and so on). In other
words, their sole function is to specify representation -- in
this case, "number of bits in machine storage" -- yet they fail
to let you specify the representation *enough*.
....but I disagree with this last point. It may be true enough in
general, but there are specific implementations where it is done well
and extremely useful.

This is the case in many embedded microcontroller/DSP implementations
that I have used. It is quite common for the silicon vendor to supply
extensive header files defining all of the on-chip memory mapped
peripherals with unions overlaying bit fields and unsigned integer
types.

Of course, they make sure the bit ordering and other features of their
definitions compile properly with their compiler. They would not
necessarily be portable to any other compiler, but then neither would
the hardware peripherals they address.

So this may be a portability issue, especially on desktops and work
stations, but can be and is used well, despite its limitations, on
many embedded platforms.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Dec 14 '06 #3
"Jack Klein" <ja*******@spamcop.netwrote in message
news:d6********************************@4ax.com...
On 13 Dec 2006 19:21:19 GMT, Chris Torek <no****@torek.netwrote in
comp.lang.c:
>In article <11**********************@16g2000cwy.googlegroups. com>
<sa*****@yahoo.co.inwrote:
We all know that bit fields are to be used within a structure, like

struct sample
{
int i:4;
}

However, is there any reason as to why it can only be specified only
within a structure or a union and why not standalone as,

int i:4;

"Because Dennis said so", more or less.

(In other words, there is no fundamental reason bitfields could not
be applied to ordinary variables. Note, however, that there is no
"pointer to bitfield" type in C, so there *is* a fundamental reason
they could not be applied to arrays, at least not without first
adding "pointer to bitfield" types.)

Dennis Ritchie also once said that C's bitfields are "a botch and
a blemish". I have to agree: they are not supported "correctly"
at a high level (no arrays of bitfields, no pointers to bitfields,
and so on), and at the same time,

Up to here, I agree with you...
>they do not map usefully to
hardware or protocol needs (no control over underlying machine
representations, cannot span machine words, and so on). In other
words, their sole function is to specify representation -- in
this case, "number of bits in machine storage" -- yet they fail
to let you specify the representation *enough*.

...but I disagree with this last point. It may be true enough in
general, but there are specific implementations where it is done well
and extremely useful.

This is the case in many embedded microcontroller/DSP implementations
that I have used. It is quite common for the silicon vendor to supply
extensive header files defining all of the on-chip memory mapped
peripherals with unions overlaying bit fields and unsigned integer
types.

Of course, they make sure the bit ordering and other features of their
definitions compile properly with their compiler. They would not
necessarily be portable to any other compiler, but then neither would
the hardware peripherals they address.
Actually, it seems in your last paragraph that you are agreeing with Chris.
Of course, they make sure the bit ordering and other features of their
definitions compile properly with their compiler. They would not
necessarily be portable to any other compiler ...
But they _would_ be portable to any other compiler, if they:
>let you specify the representation *enough*.
There is definite room for improvement with 'C'. Not only is there the
portability issue, but there is a learning and training cost. I've worked
with compilers that pack bitfields MSB first and LSB first, and when I look
at memory dumps and so on I need to refamiliarize myself with how the
compiler packs each time ... it would be easier if they all packed the same
way.

And I also wish there were a way to give the compiler _MORE_ freedom in what
it did in some cases. When one has bitfields that are being used for
compact storage only (and not for ill-advised type conversions and so on),
one should be able to tell the compiler to rearrange fields as it pleases.
Two examples come to mind:

a)A processor I've used in the past had a neat instruction for swapping
nibbles of a byte. The compiler did a really good job if one just happened
to place a bitfield of size 4 as the upper nibble ... the compiler should
have the freedom in some cases for force this alignment by rearranging
bitfields.

b)In general, shifting and masking to extract bitfields is an expensive
operation (for embedded systems). The compiler should have the freedom in
some cases to align frequently-used bitfields against the LSB to eliminate
the shifting.

The *enough* is a problem. One should be able to give the compiler less
freedom in some cases and more freedom in others.

Dec 14 '06 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: chris | last post by:
What is a class ?? is it like a function ?? this has allways confused me as i am a newby to programming (since Basic in the 80's) thanks for any insight you can give
8
by: Mike | last post by:
Hello, I have a few rather urgent questions that I hope someone can help with (I need to figure this out prior to a meeting tomorrow.) First, a bit of background: The company I work for is...
1
by: Reno Raines | last post by:
I'm working with MS Access 2003. I've created a table and the fields I want. For some of these fields I've created a drop-down menu (list box). The data type of the fields are "Text". How do I...
0
by: NWx | last post by:
Hi, I discovered a strange (?!?!) issue related objects saved to cache. Let's explain my situation. I have a webform for user registration. Users enter username, password and other info...
4
by: Bill Moran | last post by:
I hadn't really looked at this until I started having problems with it. For those who haven't been following along, I'm converting an application originally written in MSSQL to Postgres. I'm a...
0
by: Zlatko Matić | last post by:
Hello. I use MS Graphs nested in reports, extensively. They show subset of report's recordset by linking master/child fields. While reports are based on pass-through queries (PostgreSQL), my...
2
by: alagan | last post by:
Hai,, I am mathiyalagan. Working in a small s/w in my home town.. We are doing some database related windows applications.. Actually we had problem with the datagridview that is we had...
3
by: mahaveer | last post by:
Hi , I am facing a strange problem with STL maps ,I am using gdb to debug my debug my code. Upto one point the number of entries in the map is shown as follows , $79 = {_M_t = { _M_impl...
4
omerbutt
by: omerbutt | last post by:
hi there i am amking an inventory application with php,ajax,javascript,html,dhtml,sql the problem is that i have hidden the input fields regarding the replace no's of the parts with this line of...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.