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
I said "header files shall contain no executable code" He said otherwise.
Can you guess which side of that particular fence I live on?
Let me check on that 'rudeness' factor now... "chucking bits of Latin for effect..."
Did you think that was rude? I apologise. It was a bit off the cuff.
I think it had its intended effect.
I assumed it was intended to add a little gravitas to your apparent wish that I should not reply to your post.
Misspelling occurs all of the time on forums, and most of us will excuse it.
Yes, I ignore English misspellings unless I cannot make sense of what the poster is trying to say.
Are you absolutely sure I misspelled it? Do your research, and get back to me.
Is this a serious question, or ar you herring me on?
We wouldn't want our readers to think that you haven't done your homework before making a jab at my spelling in an attempt to "one-up" me on a 'spelling error.'
Given the context it seemed fair game.
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)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
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?
I know I should just ignore the smoked sardine and the bratwurst but it is darn tough when they attack my abilities/professionalism.
You can't expect to post whatever you like in a public forum and have it quietly ignored.
if they would move ther personal attacks to e-mail, this would be a much more peaceful place.
Why do you view any disagreement as a 'personal attack'? If you're prepared to expose yourself in public you really must expect responses in public.
comments like have no merit in the forum and should be relegated to e-mail
have no merit in the forum and should be relegated to e-mail
Based on what you post that quote seems an accurate reflection of your working practices. Have you ever read the 'C' standard? Would you use a chip without reading the datasheet?
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!
Why do you view any disagreement as a 'personal attack'? If you're prepared to expose yourself in public you really must expect responses in public. I do not wiev disagreements as 'personal attacks' by no means; however phrases like "I am sure your code is not mainatainable" are very personal attacks for two reasons a) you can not possibly know if it is and b) that has nothing to do with the subject of the thread. Thus, since it has nothing to do with the thread it can not be anything but a personal attack.
Based on what you post that quote seems an accurate reflection of your working practices. The very point showing that what you post is personal.
An impersonal attack would be based on facts, not what something seems to be to you.
Erik
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.
Ok, let's establish some facts:
Have you ever read the 'C' standard?
Would you use a chip without reading the datasheet?
yes (I have a K&R somewhere) and no, of course not (it would be impossible)
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. If, in Keil C, a 'for' was called a 'because' I would not have a problem, (you would have cow, I'm sure) that to me would just be "Keil '51 C" and that it was not "real C" would be no concern of mine. I work with the tool I have, and know that tool, I could not care less what other similar tools do.
PS I do not give a hoot about portability, that would come under the heading "real C", not "Keil '51 C"
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 :)
"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.