|
 |
Warp wrote:
> Exactly how is this situation different from your example?
Or, to phrase it a different way, compiling *your* C code can wind up
depending on the quality of the source code provided by every "pre-compiled"
library author whose code you're using. Not only does their library object
code have to work as advertised, but you have to recompile vital pieces of
it every time you compile your code.
I find this to be a disturbingly problematic lack of modularity in large
projects taking advantage of lots of pre-built code. And most other
languages don't really make you care what some third party's coding standard
is, as long as the library runs, because you don't get their source code.
Does that clarify the fundamental problem?
Or, look at it a different way, if you're *really* interested in pursuing
understanding what I'm saying: Why do you #include stdio in your program?
As you said, it's part of the standard. You can't change it without breaking
lots of programs. Also, you can't pick a different function to be called
"printf" without breaking any library that expects "printf" to mean the one
from stdio. (I.e., C's linker has a flat namespace, so if *anyone* includes
stdio, then the symbols from stdio will preclude using that name anywhere
else to mean something different.) So why does one have to recompile
stdio.h every time you compile a program?
I know the *technical* reason, as in "because that's how C works." I'm
asking you to try to understand why working that way is not as good as
simply telling the compiler you're using the standard library and symbols
come from there. You see the fact that you're recompiling bits and pieces of
the standard-mandated standard libraries (that you correctly acknowledge
can't be changed anyway) every single time you compile your program, yes?
And that doesn't sound like a strange idea?
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
 |