|
![](/i/fill.gif) |
Warp wrote:
> The issue was the #include scheme, which you seem to hate and I really
> can't understand why.
Let's see if I can express it simply and clearly enough:
1) Every source file should generate object code when compiled. In other
words, declarations should generate output when you pass them to the
compiler. Not necessarily *executable* statements, mind, but some sort of .o
file.
2) It should be possible to deduce from object code what types that object
code implements, without reference to the source code, well enough to
determine if two object files can inter-operate (i.e., can be correctly
linked together). This implies that linking incompatible compilations of the
same type can also be noticed - i.e., if the caller passes packed structures
to a callee that expects unpacked structures, this should be caught.
When you're lacking property #1, there's no clear and obvious "type" in your
system. All you have is declarations which may or may not have been changed
and which may or may not match your definitions. (Otherwise, people would
not need to be encouraged to include xyz.h in their xyz.c file.)
C lacks property #1, which leads to #include files because manually
repeating the code is too error-prone. This leads to the need to track
dependencies between source files that come from different authors.
Without property #1, a consumer of a C-enabled library has to track
dependencies on *source* code written by the provider of the library, and
that *source* code is (by the time it's on the consumer's machine) unrelated
in any way to the library code the consumer is trying to consume. I.e.,
there's no practical way for the consumer to use the library without a .h
file, but that .h file is not part of the actual library code that gets
deployed. It's entirely possible that the .h source code doesn't match the
.o/.lib code you wind up linking against.
When you're lacking property #2, you not only need to have the object code
library, but you need to know how to compile your code to make it work with
that object code library. So now you have three things to harmonize: the .h
file for the library, the .so file for the library, and the compile-time
arguments for the library, and you have to pick compile time arguments for
your own compilation that are compatible.
Most implementations of C also lack property #2, which means you actually
have to track down the correct library source code and compilation options
to use an already-compiled library. Interestingly enough, one of the
criticisms of C++ is that each compiler tends to implement (to the extent it
does) property #2 somewhat differently.
In other words, with #includes, using a library means you have to figure out
how to correctly compile someone else's code, in an environment that the
library author never tried compiling in, just to invoke "already compiled" code.
Also:
In *shitty* code, the fact that #include's aren't restricted to type
declarations but rather can arbitrarily change the syntax of the language
you're using is also a problem. Languages should strive to make it difficult
to write shitty code, *especially* shitty code that makes people who write
*good* code have a harder job of it. Again, this isn't a problem where one
does not need to compile someone else's code in order to use pre-compiled code.
I hope that answers it. You may *disagree* it's a problem, but I hope you
understand it.
--
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
|
![](/i/fill.gif) |