We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Let me tell you a story about a guy named Jed...
A long long time ago (pre-ANSI C), in a galaxy far far away I had worked for a company that had to develop internal "C" coding standards and "Jed" worked on one aspect of the standard while I worked on another. We would hold weekly meetings to reconcile our differences. In attendance, we had other professionals for simple sanity checking and to gain insights from different points of view.
Chris was one of our attendees and was a very experienced software veteran who had plenty of code in various satellite systems orbiting our planet today. By then, Chris was in upper management and graced us with his wisdom when he could.
Well during one of our weekly meetings, "Jed" and I got into a simple disagreement on a Rule about header files. We were at an impasse, so we waited for Chris to arrive and have him make the final decision: about five of us professional engineers were in the room.
When Chris arrived, he heard the arguments, and quickly announced that I was right. (Hence, Jed was wrong).
Well, Jed freaked out and wanted to take the guy outside and teach him a lesson! ... Jed was red-faced, quickly stood up, even took a step towards Chris, and said "Chris, lets just step outside and settle this! I am right and you don't know what you're talking about!" etc etc.
The other attendees and I were duly impressed over Jed's technique of handling technical disagreements. Especially with upper management.
Instead of Jed trying to learn that he *might* be wrong, Jed leaped into the confrontation method of getting his way. Bullies do this because they lack the brain-power to reason through a disagreement. It is a childish trait.
Children are at a huge disadvantage when arguing with "an adult" (or somebody who is much smarter than they are) and they will become very frustrated over their strong desire to assert themselves and their inability to win the mental sparring. They will get physical and/or verbally abusive. Some people out grow this, and some don't.
I think Jed showed his 'abilities' quite well. I find that this is true with so many people on so many subjects. I've seen this behavior many times over. I've seen it here on this forum.
When an "Original Poster", asks a question and people try to answer it (after much refinement of the OP's question) you get these side-bar posts where somebody will start attacking another poster's efforts. And I mean 'attack' and not augment or refine.
I don't have a problem with correcting or clarifying others, or even the occasional sprinkling of sarcasm, but when it is ALWAYS devolves into some vindictive vitriol between a brisling poster and the rest of 'us,' I wonder if it is out of ignorance, malice, or some twisted form of self-entertainment. All three of which are adolescent behaviors. (en.wikipedia.org/.../Adolescence)
Since the regular players here are detail oriented and thus they are savvy enough to know who I'm talking about, I don't think I have to name names.
He is critical enough to figure it out himself, so I would expect that the offender would read this and ask himself if he is demonstrating Ignorance, Malice, Entertainment, or is he being an adult and providing a constructive post before he does so.
And, I hope his "Mea Clupea" (en.wikipedia.org/.../Mea_culpa) will be a silent one, because I'm kind of tired of reading his Hostile Postings (HP).
</rant> --Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
and I did not come up with that monniker (Sprat)
erik,
Nice catch there.
When you browse through the "*** fishy" communications, you come away with a slimey feeling that Sprats are hostile when they are not in their native environment. Must be a defense mechanism.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
"[...] because all ARM registers are 32 bit, 2 instructions are required to test a bit: a shift to right, then a separate instruction to test the value.
it is much faster to use a 32 bit integer as a container for your bit fields."
Tamir: bit fields did not enter the standard because of ultimate speed - they are not intended to overlap bits in SFR - but because they allow you to trade data size for code size when you have many state variables that each requires a very limited numeric range.
I can have 256 alarm type definitions, where each definition contains a bit-field with flags for 'speech-connecting', 'requires acknowledge','number of repeats', ... Having 5 one-bit fields and one 3-bit field would save 5 bytes / alarm type definition compared to using an unsigned char for each info.
Using bit fields instead of manually performing bit operations makes the code easier to read, as you can see from the following examples. And it make it easy to change the size of the fields depending on changed requirements, without having to look into a number of helping constants or looking into the individual source lines.
The bit field will generate the same code as if I manually perform bit operations but the code will look nicer if I write:
if (alarmtype->speech_connecting) enable_speech();
than if I write:
if (alarmtype->flags & SPEECH_CONNECTING) enable_speech();
And the readability will improve even more when having bit fields of size larger than one, i.e.:
if (dial_count >= alarmtype->max_dial_count) fail_alarm();
than if I have to write:
if (dial_count >= ((alarmtype->flags >> DIAL_COUNT_SHIFT) & DIAL_COUNT_MASK)) fail_alarm();
If I really have room to store all state variables in 8, 16 or 32 bits, then I don't need bit variables.
On a PC, I might have plenty of memory. But the reduced data size from using bit fields (or manually perform the bit operations) may allow the data to fit in the data cache, resulting in faster code. And the concurrent processing of multiple instructions may hide the extra code needed for extracting the bit field.
Erik: "please define 'raw'".
My definition of raw memory structures, is to transmit or store data in the exact format that the compiler puts the data in memory. Such data will have much of it's format defined by the compiler vendor, not by you or the person responsible for the other side of a communication link. And since the compiler vendor has the full right to change that definition, you can not be in ownership of a document that correctly document the data format used.
Me: "Transmitted or stored data should be described by a 100% complete document" Erik: "it is, of course, how else could i use it?"
It can't be 100% documented if it relies on mechanisms that the compiler vendor may change between different releases of the compiler, or that are likely to fail if the source code is built with another vendors compiler.
To be 100% documented, the document must specify the actual bit location of every single bit. And the source code must make sure that the information is really placed at that bit position and doesn't just get placed there by chance because the current compiler because of some private design decision chooses that location.
There is no problem using any kind of byte order for a transmission, as long as you have a document that says that little-endian is always used, or that bit 0x40 of the third transmitted byte (before any endian byte-swappings have been performed) in message xx specifies which - of two possible - endian alternatives that is used. Just relying on memcpy() will not enforce the required endian. If you know that your processor has correct byte order memcpy() when writing may do the job, but what happens if the code is run on a different processor?
Transmitting bit fields (as oposed to manually handled flags) will always be borked since you can't write a documentation that takes into account possible future changes of a compiler.
If the other side is transmitting a raw bit-field, then you have to try to deduce the current location of these fields, while living with the knowledge that a changed compiler on the other end may require you to require your side of the communication. If the coder (or technical lead) on the other side of the communication link was a fool, you will have to suffer, since both sides will - by implication - be non-portable.
Using bit fields inside code gives cleaner code. But a lot of developers intentionally selects to manually assign the bits, just to avoid the extra work of having to write conversion functions "flags_to_native" and "native_to_flags" when they need to share information, or store he information on a medium where it may later be read by an application built with another compiler or built for another architecture.
and I doubt the endianness will change there.
and there are no bitfields, just #defines of 'masks'
Erik