Warp wrote:
>   What exactly is the difference here?

I have explained it repeatedly, but it basically breaks down to "I don't 
have to compile object code."

> (Why exactly would I need to specify which object
> file goes with what source file? I don't care. 

So there's no need to use the right .h files for a given .so file?

> you need to be explicitly pairing object files with source files.)

You need to specifically pair object files you're *linking* against with the 
source files you're compiling. But you don't have to find any *source* code 
that came with the object code you're linking against.

>   Whatever the building process might be, you still need to tell the
> compiler in one way or another where your source files are, and that's
> the point.

Right. And in C, I have to tell the compiler one way or another where *your* 
source files are too.

> (Your original argument was, after all, what
> happens if you have to C files of the same name.)

No, that was a trivial oversimplification to try to explain what I meant 
when I said the source code isn't sufficient to know what the dependencies 
are. Don't apply it to other situations.

>   Also, I don't understand what "factually incorrect" thing I have said.

I said "No. The programming language is such that it is impossible to figure 
out by looking at the source code what the dependencies are on other source 
code."

This is factually true. You argued "If that were true, then it would be 
impossible to compile the program."

Then I gave an example of source code from which you could not deduce the 
dependencies, and yet which is possible to compile.

Indeed, you're *making reference* to that example right here.


>> And you know, for someone who distinguishes "invoking the compiler 
>> preprocessor" from "invoking the compiler", saying there's no significant 
>> difference between source code and object code just doesn't ring true.
> 
>   Somehow it seems that you are talking about something else entirely.
> This whole "you tell the compiler which files to compile" argument started
> from your example of two C files with the same name. You have now made a
> strange jump to some C# object files, and I have no idea why or how it's
> related. It seems that you are thinking about something else entirely.

OK. If you can't read what *i'm* writing about a non-C language without 
running it through your C filter and changing the words I'm saying into 
something else, then I can't really explain it to you.

If you're going to change where I say "object code" into "source code" and 
when I say "library" into "include file" and where I say "link" you say 
"compile" and so on, then I'm just not going to be able to explain it to 
you.  I tried my best, including a couple of detailed and thought-out posts 
which you still haven't commented on or said anything to imply you read.

>>>   Are you saying that it's impossible to have a C# source file with the
>>> same name in two different directories and which implement a class with
>>> the same name?
> 
>> I'm saying that if you do, it doesn't matter, because your compilation isn't 
>> looking at that source code.
> 
>   And why not? That's right: Because you only told the compiler to use
> *one* of those files, rather than both. It's your decision which one.

No. It's because the equivalent code in C# would not look at *EITHER* of 
those two source files.

>   You don't seem to get my point here. My point is that your argument about
> the two C files with the same name is bogus. In other words, a bad example
> and a bad argument.

It was merely an argument to prove your assertion that having that is 
impossible is bogus.

>   It's anybody's guess what object files have anything to do with this
> whole thing.

Since it's pretty much the entire point I'm making, I'm not surprised this 
is going around and around.  You're taking an example I'm using to show one 
point and saying "that is nonsense in the context of this other point!" 
Well, yes, it's because it's a nonsense example to prove a very simple and 
specific point, because you seem to be having trouble following the overall 
discussion in a larger way.

>>>> Do you really not see the difference between saying "each time I compile 
>>>> something, I have to pick which source file to compile" and saying "each 
>>>> time I compile something, I have to pick the right source files that go with 
>>>> the corresponding libraries of every library I'll eventually link this with"?
>>>   Not really.
> 
>> OK. Then I'm afraid I can't explain it to you.
> 
>   Well, I just can't see the difference between the two sentences you wrote.
> They are saying the same thing.

Here's a simple summary: When I compile code I wrote in C# or Java or etc, I 
don't compile code I didn't write.

When I compile code I wrote in C, I almost invariably wind up also compiling 
code I didn't write at the same time in the same compilation unit.

>>> You have to specify which source files the program is
>>> composed of. 
> 
>> It's not my program.
> 
>   There's a difference between "the" and "my". I wrote "the".

And now you're trolling. You're here *intentionally* ignoring the point I'm 
making. You're saying "I don't understand the difference between your source 
code and my source code."  I say "I don't want to compile *your* source 
code." You say "You have to compile *the* source code."   Do grow up.

>>> Your example of the same C file being in two different directories is simply
bogus.
> 
>> Why?
> 
>   Because you tried to use it as some kind of example of why it's "not
> possible to figure out dependencies by looking at the source codes only"

Yep! That was the point of the example. Why is it bogus.

>   My answer, which you still don't seem to understand, is that this has
> nothing to do with C or any particular language.

Yet, surprisingly, you said "If that were true, then it would be impossible 
to compile the program." That's all that example was about: showing you that 
your assertion that you can deduce the dependencies solely from the source 
code is bogus.

You made a factually incorrect statement. I showed you a trivial example of 
how you are factually incorrect. You then denied that you were incorrect 
*and* complained that the example was obviously stupid. Now you keep 
bringing it up for some reason.  Nice moves, Bats!

 > If you have a file with
> the same name in more than one place, you need to tell the compiler which
> one it should use. This is obviously true for any language. C isn't somehow
> inferior because of this.

I didn't say it is.

>>> It has nothing to do with C particularly.
> 
>> It is much more common in C than in other languages, I've found. YMMV, but 
>> that doesn't make me wrong.
> 
>   You are blaming C for a somewhat common bad practice among C programmers?

Yep!  Altho for some reason you seem to think there's some pejorative 
"blame" going on here.  I also blame any other language with disconnected 
and non-modular declarations and defintions.  (I don't like FORTRAN block 
common statements either, for example, for the same sort of reason, altho 
without macros it's somewhat less of a problem in fortran.)

>   If I were to go that path, I would say that C# and ASP are really crappy
> languages, judging from what I have seen at thedailwtf. (Of course this
> argument would be completely fallacious.)

Feel free! It would be interesting to hear some of the criticisms of C# 
technology.

>   You said, and you quoted it above: "when I use the C# equivalent of stdio",
> to which I responded "and when I write C++, same thing". I don't think I
> heve the source code for stdio even installed in my linux system.

So, what happens when you #include <stdio>?   Sorry, I thought stdio.h is 
source code, yes?  I mean, there are precompiled headers, but that's just 
running parts of the compiler first and dumping the symbol table, afaik.

Now I'm really curious. What does your stdio.h look like? Cause mine's full 
of C source code.

(And yes, I actually trusted you enough that I actually fired up Linux to 
check. :->  Plus, there are three stdio.h files under my /usr/include right 
now, so the whole idea that you might not know which is the right one isn't 
as far-fetched as one might think.)

> So what if I need to "include someone else's code in my program"? 

There's a whole slew of problems this enables. No, you might not run into 
any of these problems. But let me list again what they might be:

1) There's no way to know which header files go with which object files. 
Look at the man page for open() and tell me how you would figure out which 
header files you need to include for that to work.

If you compile against object code declarations instead of source code 
declarations, you don't have this problem. Instead of saying "I'm using the 
version of open() defined in sys/types.h and sys/stat.h and fcntl.h", you 
just say "I'm using the version of open() defined in crt.o". Instead of 
saying "I'm using the MPEG decoder as specified in RMinit.h, RMerr.h, 
RMinp.h, RMthis.h, RMthat.h, RMother.h oh wait I need to put RMthat.h before 
RMthis.h, and if I include RMinp.h it includes RMother.h in turn so that 
breaks...."  I could just say "I'll be linking against RMlib.so, so use that 
for declarations when I compile."

2) Header files can contain macros that change how your code behaves. Go 
read my post about the awful libraries I used at work, including
   #define char }}}}
put in there *explicitly* to fuck up the code of anyone trying to use the 
library (in the name of portability, of course). Along with a bunch of crap like
   #define IN
   #define OUT
etc, to the point where you're reading a declaration and you can't even tell 
looking at the arguments what are the types and what are the variable names.

If I'm compiling with declarations from object code, none of this happens, 
because I'm only compiling the code I myself wrote.

3) Stuff like #define making it impossible in some cases to track down just 
what name goes with what value, as I gave examples of.

Again, if I'm using declarations out of object code, the names vs values 
have already been compiled, and they won't change depending on what I put in 
my source code.

4) Compilation options for the compilation of a given library is usually not 
stored in the object code, and you're recompiling the declarations for each 
caller, so a change in calling convention, structure packing, etc between 
what the library was compiled with and what the caller was compiled with 
will often crash silently or messily, often without any indication of why.

If at compile time I'm supplying the object code instead of the source code, 
the compiler can either reject it during compilation, or it can adjust 
individual calling sequences to match the library being called.

-- 
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