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
Both 'brisling' vs 'bristling' and 'clupea' vs 'culpa' were non-accidents. I was going out of my way in not directly naming the poster.
I figured that the savvy regulars would see it as you did Per. And that this particular person would get it too, and silently take heed, or possibly admit fault (hence, mea culpa)... but I was hoping for both.
This way I would not be in a position to do what he often does, and start some flame-war. Uhm, about spelling I guess. Oh, the irony! (note the difference between humorous and bits of Latin... git it?)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Both 'brisling' vs 'bristling' and 'clupea' vs 'culpa' were non-accidents.
I didn't credit you with that level of subtlety. Mostly I find myself struggling to read the lines round here rather than read between them.
I was going out of my way in not directly naming the poster.
I think any regular reader, savvy or not, would know who you were talking about without spotting the fishy references.
This way I would not be in a position to do what he often does, and start some flame-war.
Throwing out bait like that is a pretty standard way of trying to start a flame war...
Right, right my little droog. Sounds like its a wrap then.
(and BTW, I enjoyed your last two posts)
This is an open forum, which bared a certain cost. People can and do occasionally post mistakes (me included) and personal opinions are sometimes introduced as facts. These can be attributed to the shortcomings of people in general and software developers in particular. So, I am big supporter of the freedom of expression here, even by trolls (excluding really annoying people that hijack posts and the like). So I don't think that Jack Sprat is a troll. Not at all. The fact that he posts contentions opinions certainly contributes to the level of the technical debates here, as far as I can judge!
"I said 'header files shall contain no executable code'"
Before C++ templates, I would (almost) have agreed with this one. But the C++ standard have more or less forced this issue - any template function must have the implementation visible to the compiler by at least one source file that is making use of the function with the specific template parameters.
The end result is that STL has huge amounts of code in the header files. Not nice, but needed.
Besides the C++ template functions, there could still be advantageous to declare a number of small inline functions in a header file. I prefer inline functions instead of #defined code expansions.
If often create an inline_<target>.h file with a number of tiny helper functions to make my code less bound to the hardware.
Right, right my little droog.
Dream on.
--Cpt. Vince Foster
Why the military affectation, I wonder? Ego trouble?
Whatever y'all do... please don't stop. It's always refreshing to find these lengthy discourses, and to take the time to read them. I often email my peers with links to these threads, and we relish reading them. If nothing else, they're often a great source of entertainment. So easy to find too... just look for the huge number of replies.
Of course, I sometimes learn things from them too, or am prompted to do some relevant independant study.
Whoever said engineers were boring...? Flame on!
I often create an inline_<target>.h file
Per, you wanna step outside and settle this?!
The catch-all escape-clause for all of those rules was to have the Project Manager sign off on any waivers to The Standard. So in your case, it would have required you to fill out forms MS-1781, SE-0112, and then of course ECR-100.
After a review of your peers, an ECO may have been signed and then it would have generated an ECN. Only then could you include your in_line.h file. And after that, an NCAR form would have been written to satisfy the team of 'inspectors.' (Basically, I made it hard to deviate from the standard... most likely due to my huge ego troubles)
Dream on
*sniff* You are a meanie. (Ref: http://www.keil.com/forum/docs/thread12822.asp)
Ego trouble?
Yes.
But at least I have a computer - you can't catch me at a late stage of my application process by noting that my triplicates are not enough. Life must have been a real *** when you had to fight with huge sets of carbon paper duplicates ;)
Somewhere in the process there might be a bean counter that I can swing over on my side by claiming 'saved money', 'unchanged code run on multiple hardware platforms (possibly the next that hasn't had the money granted yet)', 'faster time-to-market by testing substantial parts of the code on off-the-shelf hw'.
If I can't produce selling (and hopefully believable) arguments, then I can't have spent enough time pondering the need/advantages of an inline_<target>.h file, and should obviously have my application rejected. This world has already seen enough code produced "just because", with no real thought behind.
When we know that well-designed software regularly fail, it's a wonder that we survive all the crappy code out there. Space avionics may seem like the ultimate challenge but a single little bad line of code in an ABS system may quickly destroy an otherwise perfect day. Or my mobile phone, that managed to move a meating to an earlier date, but kept the alarm reminder...
meating Not critisizing you, just found it funny :)
Erik
"That I am much more concerned with "Keil '51 C" than the utterly stupid concept of insisting on "Real C" on a '51 is another thing."
That is a bit dangerous. Keil has made some deviations (because of puny stack and no real 16-bit support in the chip) and some extensions (because of need for different processor instructions to address different blocks of memory and because of bit variables etc).
But besides that, Keil is a C compiler, which means that Keil to the best of their knowledge tries to follow the C standard. If you have grown used to how it works, and a bug is found where the compiler unintentionally deviates from the standard, then it is likely that a new version of the compiler will correct this bug.
If you assumed that the previous version of the compiler was "the reference" and continues to write software based on how you learned that the Keil compiler worked, then your new and old code can suddenly fail.
If you knew the language standard by heart, you would not have been caught off-guard, because you would be able to notice if the compiler did deviate from the standard in a way that Keil hasn't explicitly documented. Before coding for this behaviour, you would be able to contact Keil and ask them why the compiler does something unexpected.
Right now, you think that your C51 is wonderful. But if there is suddenly a need to create a product with a different processor architecture, your knowledge about the specific Keil C51 deviations would be worth zero. If you are not aware about exactly how the standard requires signed and unsigned variables to be treated, you may create the nastiest of bugs if/when you have to develop for a general-purpose 16-bit or 32-bit chip.
When mixing signed and unsigned variables and working with sub-int variable types, it is absolutely vital to know the difference between what the compiler does and what the standard required.
No, luckily for me I noticed the missing alarm, but even if I would have missed the meeting I think I would have survived with just a brief comment from the CEO about the value of meeting discipline. Threatening with "meating" me would probably not help me meat my deadlines ;)
But if there is suddenly a need to create a product with a different processor architecture, your knowledge about the specific Keil C51 deviations would be worth zero. different tools, different rules. the point is that if Keil had a 'because' instead of a 'for' (deliberately chosen ridiculous difference) then when you work with Keil, you use 'because' whatever the standard states. If you use a different compiler, you work with the rules for that compiler. all the wunnerful stuff about "the C standard" is fine and dandy, the point is that what you should work with is how your tool behaves, not with some 'standard' that might and might not apply.
An I saying that knowing the standard is worthless, by no means, just that whining about nonstandard 'features' or 'differences' implemented to match the processor you happen to use is ridiculous. Also, ignoring an extermely useful feature (e.g. Keil '51 BIT) for the sake of "the standard" is going around designing the project the wrong way.
PS I have worked (succesfully) with, at least, 5 different compilers and, at least 4 different processor architectures, and, in all cases, applied the "it is better to work with your tool than some 'standard' that might and might not apply.
Life must have been a real *** when you had to fight with huge sets of carbon paper duplicates ;)
The real problem was that this "Jed" guy wrote such horrendous code that I had refused to work with him until we had standards. Management agreed, and in an effort to corral him until the project was done, we implemented the draconian policies. As soon as the project was done, "Jed" no longer reported to work... for some reason. (He made it past his 'outburst' by a few months)
This world has already seen enough code produced "just because", with no real thought behind.
Human Safety Factors are always paramount, and once you have gone down that road (either from military, aerospace, medical, automotive, or industrial equipment projects), those habits might help you when you code-up that "My Little Notes" iPhone application. Hopefully that code won't lose the medical records that customers like to carry around with them to their trip to Mozambique ... and hence, that non-Human Safety Factored project became life-saving app. Or not.
And yes, we are now way off topic. We must think of Dave Sudolcan and his Keil Thread Worshipers. They might become irritated and become a whole school of smoked sardines. And we all know how those sprats like to communicate:
www.newscientist.com/article.ns
Erik,
Don't you think that if tool vendors would have had this slogan ticking in their head...
the point is that what you should work with is how your tool behaves, not with some 'standard' that might and might not apply.
our industry would have never reach ANY coding standards whatsoever?
our industry would have never reach ANY coding standards whatsoever? of course, any tool should adhere to existing stndards as far as possible/practical but here are a couple of examples of what I mean: For the benefit of "PC programmers" Keil '51 can do malloc() ARGH, have you seen how it works in the little resource starved '51? To make use of the unique facilities of the '51 Keil has introduced the BIT variable type.
fully adhering to the standard you would use malloc() and never use BIT which would be plain unadulterated stupidity.