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