Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Warp wrote:
> >>>   How do you resolve this? That's right: You tell the compiler which files
> >>> it needs to compile.
> > 
> >> Nope. You tell the compiler which *object* file goes with the appropriate 
> >> *source* file.
> > 
> >   Yeah, huge difference.

> And *this* is exactly why these arguments go on for so long.

> I can't tell whether you're being a truly masterful troll, or whether your 
> misplaced egoism has completely blinded you.


> I make a comment. You strawman an argument against it.  I point out that 
> you're putting words in my mouth. Instead of saying "OK, I was wrong in my 
> assertion, I don't see the difference, please explain again why it matters", 
> you say "I wasn't wrong, because even tho I was *factually* incorrect, it 
> doesn't make any difference, because there couldn't possibly be any 
> difference, so I'm really right anyway."

  I don't understand what you are talking about.

  I said, "you need to tell the compiler which files it should use to
compile the program", and you answer with "no, you tell the compiler
which object file goes with the appropriate source file".

  What exactly is the difference here? You are telling the compiler which
source files the program is composed of. What do the object files have
anything to do with this? In fact, you are making it sound *more* complicated
than it needs to be, (Why exactly would I need to specify which object
file goes with what source file? I don't care. Let the compiler figure
those things out. You are in fact making it sound like compiling a C#
program is actually more complicated than compiling a C++ program, if
you need to be explicitly pairing object files with source files.)

  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. If you have two files with the same name, you tell the compiler
which one of them to use. (Your original argument was, after all, what
happens if you have to C files of the same name.) I don't understand what
the "object files" have anything to do with this.

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

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

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

  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's anybody's guess what object files have anything to do with this
whole thing.

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

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

> I've never written a crypto library, nor have I written 
> a video codec. But I've compiled the source code for parts of those 
> libraries into every C program I've ever written that used them.

  So you tell the compiler which source files it should use to compile
the program. So? Isn't that what I'm saying?

> > 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"
and that you need to specify where the compiler has to look for those
sources, and this, apparently, is some kind of "problem" in C.

  My answer, which you still don't seem to understand, is that this has
nothing to do with C or any particular language. 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.

  Then you start rambling something strange about object files.

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

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

> >> Indeed, when I use the C# equivalent of stdio (or any other third-party 
> >> library), I don't need any source code I didn't write myself, nor do I need 
> >> to specify where to find the libraries. I merely say which version of what 
> >> implementation I want.
> > 
> >   And when I write C++, same thing. So what?

> So, when you use boost, you don't need to compile any source code to any 
> software you didn't write yourself? Sorry, that's just a lie. I've looked at 
> the boost code. It's mostly source code.  And you know what? I've worked on 
> projects where I've needed two different versions of boost in the same code, 
> neither version of which was in the repository. It sucks. It's very 
> difficult to get right.

  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.

  Also, if talking about template code, in a different subthread I actually
advocated the advantages of having such code in header files, and mentioned
<vector> as an example of this.

  I don't understand why you consider it a bad thing that eg. the boost
libraries are mostly in the header files (often because they are fully
templated and cannot be placed in precompiled libraries due to
compiler-technical reasons). So what if I need to "include someone else's
code in my program"? (The biggest issue with that for me would be the
usage license of the library, but that's completely tangential to the
subject.)

-- 
                                                          - Warp

Post a reply to this message