Hello,
See here:
www.open-std.org/.../C99RationaleV5.10.pdf
Is it possible that "Jack Sprat", the staunch defender of the C standard as the ultimate reference when writing programs, missed the following statement?
C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler”: the ability to write machine- 35 specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§4).
this is precisely what Per Westermark has been saying. Exactly what Erik Malund has been saying. Remember: Jack Sprat claims often that writing a program that complies with the C standard is a GUARANTEE for its correct functioning.
because being unmaintainable, large and inefficient is how you define something to be too generic
Well well, this is a rather artistic license to define "too generic". Why "unmaintainable" ? Why "inefficient" ? And why "large"?
None of the above _necessarily_ true.
"A too general solution gets unmaintainable, large and inefficient."
I am not sure what a too "general" solution is: I thought we were talking about code being too "generic" (not "general").
if you object to my approach, then what do you mean by "too generic"?
Remember: Jack Sprat claims often that writing a program that complies with the C standard is a GUARANTEE for its correct functioning.
Go on then... where did I say that?
Welcome back Jack.
What about this one?
http://www.keil.com/forum/11711/
Jack never said such a thing.
As I said in my first reply, "That depends on what you mean by 'correct'. It will be correct in accordance with the 'C' standard - the problem is usually that this is not the behaviour that the programmer wanted."
"What about this one? http://www.keil.com/forum/11711/ "
No.
The closest I could see was:
"If you write code that is guaranteed by the standard to work then you don't have to worry about or rely on the compiler to issue a warning. Simple"
Which is very different from,
"writing a program that complies with the C standard is a GUARANTEE for its correct functioning"
See the example in my first reply.
Andy,
There is no need to be sorry!
Are you referring to the "work" vs. "correct functioning"?
Again, that depends on what you mean by, "work" and, "correct functioning".
The terms should be equivalent.
Again, what Jack actually said was,
"If you write code that is guaranteed by the standard to work..."
Note that very important "if"!
The problem arises when the code that people write is not guaranteed to work by the standard; eg, because it relies upon things that are undefined, or implementation defined.
Or, as in my example, when people write code that the standard defines to do something other than what they wanted. ie, the programmer wrote the wrong code.
"Which is very different from,"
I wouldn't worry too much about it: michael's inability to comprehend even rudimentary things is legendary and well documented.
asking her to understand such refined topics does sound too much.
"Note that very important "if"!"
well, what "standard"? what compiler? and what hardware? I think there are plenty of cases in the real world that even if you wrote a piece of code that's guaranteed by a particular standard, the resulting code may not behave exactly as the standard would suggest, due to bugs in the standard / compilers / hardware / etc.
"Or, as in my example, when people write code that the standard defines to do something other than what they wanted. ie, the programmer wrote the wrong code."
yes, that's a far bigger issue I think.
notmyedgar1.blogspot.com/.../ashley-madisoncom-is-homewrecker.html
ashley madison is a homewrecker
The 'C' language standard - although the spcific version/release of that standard has not been specified.
"what compiler? and what hardware?"
Irrelevant.
The Standard (specify your choice of version) clearly states what things are implementation dependent, and what are undefined.
"bugs in the standard / compilers / hardware"
Well, yes - that will obviously mess things up!
Erik,
Very entertaining indeed. I tend to ignore him/her - look, I am already alleviated to a level of "legend"!
I'll be honest, when hear the name Ashley Madison the words "dirty, cheating, home-wrecking, ***-creating, pieces of *** that ruin the holiness of Marriage."
No matter what I get slammed at me, it won't equal this :-)
To achieve the modularizing, someone proposed an idea/rule for C programming, where fileA.c are not allowed to include fileA.h,
That means you desperately need of a source of better "someones".
he claims this is for reducing the cohesion and data coupling
That claim is pure and utter nonsense. The module's own interface header is exactly the single header file whose inclusion will not have any effect on cohesion or cross-coupling. Every other include is what does that.
["what compiler? and what hardware?"
Well, yes - that will obviously mess things up!]
so "irrelevant" things will obviously mess things up.
how do you define "irrelevant" again?
no answer needed, btw.
Indeed.
It has been said that an Engineer is someone who can make for £1 what any fool could make for £10.