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
As much as I would thoroughly enjoy a real trial, my remarks were just intended as houmour.
I do believe you when it comes to such minor things as 'not safe' within source code as being a liability.
Hopefully you told your team leader that the function name gets changed once it is in fact safe. But I doubt it. And even then the ambulance chasers (and all of those attorneys are) would convince a jury that the 'old' code that had the words 'not safe' buried in a comment was somehow responsible for the collapse of the Roman empire.
When we discuss the US Market, attorneys and lawsuits, we start getting into politics, and I can warn you right now, I'd win that one. (I will also not respond to any political stuff, so don't start. I pointed it out because I would LOVE to say so much about that but it is inappropriate here. But, sadly, the US Market does have that problem though)
So, no trial.
Also, I am primarily an electrical engineer and then a software engineer. (Thats what we called them back then, not "CE/CS/??"). Most of my work as been in the R&D missile & aerospace industries, so 'we' don't get sued when we put in things like:
char Totally_Unsafe_And_Known_To_Kill( short victims ) { ... }
We just get shot in a firing squad. (No, Tamir, I we don't really get shot... it was a joke).
But when it comes to Human Safety Factors, it is unsettling when you know it is your stuff that can indeed kill an innocent victim if you screw up with your electronics/software engineering. You pay 'extra' attention to those 'little details.' But that is why we have these safety review boards! Oh, and that thing people call "STANDARDS" too.
(Note: Accidental Deaths/Injuries = 0)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Vince, Don't misunderstand me, but I'd never be able to do what you do. I am convinced that the systems you work(ed) on are probably some of the most fascinating devices we can imagine from a pure technical point of view, but I would simply not be able to contribute to killing people as part of my daily job. I didn't make a fuss of that function name; hell, I changed it. Of course, that would not change the fact that the subsystem is as deadly as a guided missile if you stick a hand or a head into it...
it out because I would LOVE to say so much about that but it is inappropriate here
Vince please, you have people here hurtling at each other stuff like "blabbering idiot", "smoked sardine", "liar", "crawl back into your can" etc. and you make a fuss out of a little politics :)
"...and you make a fuss out of a little politics..."
Okay, fine. I'll keep it short, but I think this isn't exactly the correct forum or for that matter the correct thread either. This will kill two posts with one reply (and I guess I like that)...
I would simply not be able to contribute to killing people as part of my daily job.
I understand. I get that all the time. "How can you do that?"
I usually point out that the systems, at one time not too long ago, used to kill many innocent people as collateral, but now they only kill a few... the right few.
A 100 rounds/bombs/missiles to take out 'the bad guy' now takes 1. Those missed 99 rounds hit 'other stuff' which can include 'the good guys'. Also those 100 rounds cost a bundle not only in material costs but also the logistics in getting them there, so the cost of that 1 is well worth it from the bean-counter perspective. In human life, the cost savings is incalculable.
So believe it or not, I view it as saving lives. "Those bad guys are killed but they planned to suicide-bomb a playground at high-noon anyway."
The objection most people have is misplaced. The *need* to use the weapons is really at issue.
Even so, I don't have a problem with killing the enemy. I even enjoy the YouTube videos of my stuff, in action. Makes me proud.
I do believe that I am on the correct side of the war (and any war the US engages in), and with justification. I'm not building the Chest-Belt Detonator 2000 for the next hospital or marketplace suicide bombing: ONLY bad guys do that.
But Tamir, I do respect your opinion. And the many others out there who also can't/won't do this kind of work.
Well, like I just said, writing them to files is exactly what C structs are not for. Don't blame programmer's silly decisions on their tools.
Hans-Bernhard, I did not have control over this, it was so, long before I joined the company. Anyhow, without going into non-disclosure requirements, I think it is the most effective form for transferring this which hold about 75 groups of totally varying information.
Anyhow, if you have a better idea for how to transfer in one transmission about 75 groups of totally varying types of information I would love to hear it since gen 4 of this is about to be defined.
Erik
Vince please, you have people here hurtling at each other stuff like "smoked sardine" please note query.nytimes.com/.../abstract.html defines 'sprat' as a *** fishy thing.
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.
Experienced developers packs/unpacks all data themselves when sending the data on communication links or keeping non-volatile data.
This isn't a limitation of bit fields. But it is always a stupid idea to transmit raw memory structures or to to permanently store raw memory structures.
It doesn't matter if we talk about bit fields or if we talk about unions or even just an array of integers. The data should have a known format. Either pre-defined or containing flags that tells the load code which byte order to expect.
Transmitted or stored data should be described by a 100% complete document and the load/save code should make sure that the document and the reality matches.
By taking care of these issues, I don't have to worry about the next compiler changing the algorithm for packing structures or allocating bit fields from high or low bit. And if I did store the data in an internal flash sector of my ARM, I can modify the code a bit and instead write the same data to a SD memory and move that SD memory to a PC and correctly read the data. Or I can add XMODEM and transmit the saved data to a different unit using whatever processor and it will be able to process the XMODEM data and use the same code to restore the original information.
"[...] 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.
Really? Which ones? a) above for example.
You seem to be saying that my statement:
"I care about efficiency <snip>"
Contricts my other statement:
"Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable"
You are very confused.
I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is.
translated "if cost is an issue, do not involve the person hiding behind "Jack Sprat", he cares more about his fanciful ideas"
Sensible design isn't a fanciful idea.
Oh, have you decided yet whether my assertion that you haven't read the 'C' standard remains baseless?
I'd be unlikely to have designed my way into a situation where a bit operation rather than a byte operation would make the difference between project success and project failure.
so would I. Confound it, can you not understand what an example is, www.merriam-webster.com/.../example see 3)
Gosh, I had 5 definitions to choose from! Ok, but you think number 3 might suit your purpose:
"one (as an item or incident) that is representative of all of a group or type"
Here we go:
I'd be unlikely to have designed my way into a situation where anything of the group or type represented by a bit operation rather than a byte operation would make the difference between project success and project failure.
"Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable" if you do not "Wrap code in preprocessor directives" it can never be portable by the "sardine standard" and efficient. e.g. if you do not have a preprocessor directive for using 'bit' when running on a '51 your code is not efficient. Did that bend it in neon so you can see it? One one hand you claim the efficiency is not important, on the other you calim that the "sardine standard code" is not inefficient
You are very confused. here you go again making statements about me that you have no background for making.
I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is. so, "sensible design" makes effciency irrelevant. I have always thought that "sensible design" was efficient desitgn.
Sensible design isn't a fanciful idea. by most peoples definition no, by yours yes
OH BOY, after posting that 'bit' is but an example, you write: I'd be unlikely to have designed my way into a situation where anything of the group or type represented by a bit operation rather than a byte operation would make the difference between project success and project failure. I stated (clearly to all but you) that using 'bit' was an example of where adapting code to a particular processor/compiler would affect efficiency. I am not going to waste my time on listing other examples if you do not know what they (or, at least, most of them) are, you will be lost anyhow. Then on the other hand since you state that efficiency is unimportant what would you care. I am sure the processor makers love you for buying a more expensive (faster, bigger) derivative than anyone else would need, just to make the code fit the "sardine standard"
PS do you do CAN
Experienced developers packs/unpacks all data themselves when sending the data on communication links or keeping non-volatile data. easy when you control both ends, I do not. This isn't a limitation of bit fields. But it is always a stupid idea to transmit raw memory structures or to to permanently store raw memory structures. please define 'raw' ? Transmitted or stored data should be described by a 100% complete document it is, of course, how else could i use it?
erik