Warp wrote:
>   The problem is that you didn't know that you can actually implement what
> Andrew wanted with just a couple of simple and straightforward lines with
> a makefile 

Of course I knew that. Don't be insulting.

>>>>>   (And granted, with a "standard" non-gnu makefile you would need more
>>>>> than this.)
>>>> Another problem with make (and similar tools that get abused).
>>>   I honestly cannot undrestand why you call this "abuse". 
> 
>> Your reading comprehension is poor. Where did I say what you wrote is an 
>> abuse of make?  Answer: I didn't. I said that having a bunch of different 
>> versions is indicitive of a program whose capabilities have been expanded 
>> over time bit by bit without a coherent plan, in such a way that such 
>> extentions tend to get abused.
> 
>   I think it's you who didn't understand. What exactly is this 'make'
> abuse you are talking about?

If you've never seen abuse of makefiles, then power to you. I think anyone 
who has worked on an ugly system knows what I'm talking about. Otherwise, go 
look up the "buildroot" system for compiling kernels.  I mean, hell, 
buildroot was so makefile-abusive that people capable of working on the 
linux kernel said "screw this, let's throw it away and start over."

>> The problem is not that you have to tell the compiler what to 
>> compile. The problem is you have to (in C) compile much more than your own 
>> source code in order to compile your program.
> 
>   You have odd problems. I haven't encountered such a problem as far as
> I remember.

Well, good for you. The fact that you've not encountered that problem 
doesn't mean that the problem isn't real.

>   Maybe compilation times would get faster if the source files didn't depend
> on gigantic header files? Probably. However, I haven't personally encountered
> this as a problem, as I have never had to deal with gigantic projects with
> millions of lines of code. (I do understand that it might be a nuisance in
> such huge projects, though.)

Well, let me know when you've taken the source code for an entire toolchain, 
kernel, and application stack and cross-compiled it from scratch. Let me 
know how easy it is to figure out where everything goes when your makefiles 
download from FTP sites other makefiles and then run them thru sed to patch 
up the errors in them before invoking them, and then come back and tell me 
it isn't a problem.

>   If I install a new library from a OpenSuse repository, I still don't have
> to care where it's installing it. In fact, I don't even *know* where it's
> installing them, and I don't need to. They will still work.

Here you're arguing that someone else has already solved the problem for you.

>   Can this scheme sometimes cause *more* problems than when dealing with
> C# on Windows using Microsoft's IDE? Probably. It hasn't bothered me too
> much so far, though. 

Great. Install compilers for three different versions of Linux for three 
different architectures on the same machine. Make sure that you can use all 
three different versions of boost you need on each of those three compilers. 
Let me know how simple your makefiles are.

(And you're giving *me* shit about not knowing how makefiles work? Really??)


> (Although I would be surprised that if you installed
> a C# library in a nonstandard location, you wouldn't have to explicitly
> tell the compiler where to find it. Well, unless the library installer
> doesn't tell it automatically, but that's just a technicality.)

I could describe how it works, but you're not interested enough to read it.

>   No, I oppose bashing C (and C++) for flaws that it doesn't really have.

You mean "flaws you haven't encountered".  Good for you.  Maybe I've used C 
more than you have even.

>> You don't understand the word "sources" in that sentence?  Reading 
>> comprehension, dear.
> 
>   I don't think I have the sources eg. for libc.so installed in this
> system, hence I don't have to tell the compiler where they might be.

Um, yes, you do. You have the sources for some of the openssl libraries 
installed, don't you?

>   I don't get your point.

Yes you do.

>> The fact that you can automate (in some cases) the copying of dependencies 
>> from one place to another does not mean you're not copying dependencies from 
>> one place to another.
> 
>   And I asked why should I care if it happens automatically behind the
> scenes.

And I answered this repeatedly, and you picked nits instead about whether 
invoking the C preprocessor is invoking the compiler or not.

>> Because now you need a third-party tool to automate dependency generation.
>   Even if you do, so what?

I already answered that.

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

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


Yes, there *is* a huge difference. I spent an entire post of several dozen 
lines long pointing out exactly why there's a difference and the 
implications it has for this, simply so you could stop picking nits one 
sentence at a time and maybe comprehend what I was trying to say. But you 
either didn't read it, or you read it and decided you couldn't pick nits 
with it, so you asked the same question again and again, ignoring the answer 
each time by equating it to something different and then dismissing the 
differences.


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.



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

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

> You have to specify which source files the program is
> composed of. 

It's not my program. 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.

> Your example of the same C file being in two different directories is simply bogus.

Why?

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

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

>   "I have seen the same C file in multiple places, but I have never seen
> the same C# file in multiple places, hence C is clearly the inferior
> language." Yes, very convincing argumentation.

It's only unconvincing because it's a straw man you refuse to acknowledge 
isn't what I'm arguing.

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

Warp wrote:
>   Let's take a better example: Every time I want to use std::vector,
> I have to #include <vector> in the source file where I want to do so.
>   Is there any advantage to this?

For C++ and templates, yes.  Altho (and I know you'll go apeshit over this 
comment) C# manages not to need the source code for generics like that.

The problem is, again, that it can be abused. It works great as long as you 
put templates and declarations and such in there, and as long as you don't 
build entire type systems and programming structures and such via macros[*]. 
It sucks when someone starts using include files that are order-dependent, 
that try to enforce coding conventions, that screw up the syntax of the 
language you're coding in, etc. None of which is possible if you're not 
including someone else's source code into your own compilation.


> OTOH, is there a huge disadvantage in having
> to include the files other than the trouble of having to write the
> #include lines?

Yes. And I had an entire 50-line post detailing the logical disadvantages of 
it. Basically, it discussed the benefits of having every source file 
actually generate object code. Perhaps you missed it?



[*] And please think about it for a bit before accusing me of moving the 
goalposts to include macros, eh?  Try to do the "why would he bring up that 
topic" question before just assuming I must be doing it to annoy you or 
something.

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>>   So essentially you want the compiler to know what to compile without
>>> you specifying what to compile.
> 
>> Nope. I specified that you want to compile "main".
> 
>   If your program consists of one single file named "main", then it could
> work.

But it doesn't. And in practice, in C, it almost never does. Yet in many 
other languages, it does.

>   Don't forget the context. You were talking about 'make' requiring overly
> complicated steps in order to automatically track the dependencies of
> include files in C programs, and how you don't like that.

Correct. In part, because you (for example) already have to know where all 
the C header files are in order to generate the dependencies to start with.

 > Then, suddenly,
> you come up with a "it's impossible to track dependencies by looking at
> the source code only" argument. 

That is correct also.  But the two are related. If you don't see how they're 
related, then I'm sorry, but you apparently have less experience with really 
crappy C code than I do.

> It was clear from the context that you
> were talking about C in particular, as if the same (quite trivial) problem
> didn't happen in more "advanced" languages.

And, generally, it doesn't. Really. It just doesn't cause the same sort of 
problems. I've never invoked a Java class where I needed to know what order 
to put #include headers in to make it compile.

>   So what's the point?

That you're a master troll? That you're ignoring everything I'm saying that 
conflicts with your view that it just isn't a problem?

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

Warp wrote:
>   Let's take a better example: Every time I want to use std::vector,
> I have to #include <vector> in the source file where I want to do so.

Or, to phrase it differently:

vector.hpp is a standard file from the standard library. Why the hell are 
you compiling it, over and over, every time you compile your program? 
Doesn't it strike you as a bit odd that standard libraries that come with 
the compiler still get compiled on your CPU over and over?

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

Darren New wrote:
> That you're a master troll? That you're ignoring everything I'm saying 
> that conflicts with your view that it just isn't a problem?

I'm sorry. There was a possibility I didn't consider.  Perhaps when you say 
"I don't understand", you really mean "I don't understand and I don't care 
to have you explain it, either."  I can perfectly understand that, if that's 
what you meant.  I was caught off-guard, because usually "I don't 
understand" in a social environment like this doesn't carry an implicit "so 
go away about this" trailer. My apologies if I was misinterpreting you in 
this way.

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

On 01/02/2011 05:16 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I'm curious to see if turning on optimisations actually makes any
>> noticeable performance difference... I guess I'll find out tomorrow.
>
>    Well, it depends on what those programs are actually doing. If they are
> doing some heavy-duty calculations that take seconds or more, then there
> usually is a quite drastic difference between using -O3 and not using it.

How about if the program just calls two or three library functions that 
do all the work?

Well anyway, I'll find out in just a minute...

Post a reply to this message

>>> I'm curious to see if turning on optimisations actually makes any
>>> noticeable performance difference... I guess I'll find out tomorrow.
>>
>> Well, it depends on what those programs are actually doing. If they are
>> doing some heavy-duty calculations that take seconds or more, then there
>> usually is a quite drastic difference between using -O3 and not using it.
>
> How about if the program just calls two or three library functions that
> do all the work?
>
> Well anyway, I'll find out in just a minute...

Conclusion: -O3 = small but measurable performance increase.

(E.g., 27 seconds instead of 30 seconds.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> How about if the program just calls two or three library functions that 
> do all the work?

  Well, then it shouldn't make much of a difference (because there usually
aren't different versions of libraries depending on your optimization level).

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   The problem is that you didn't know that you can actually implement what
> > Andrew wanted with just a couple of simple and straightforward lines with
> > a makefile 

> Of course I knew that. Don't be insulting.

  You said, and I quote:

"I don't remember. Do you have to actually list the programs in the makefile
that you want to compile?  Is a makefile that compiles 50 programs
necessarily larger than one that compiles 5?"

  That tells me that you didn't know about the implicit rules in gnu make
that allow avoiding having to call gcc explicitly (hence saving a significant
amount of writing), or you didn't know about gnu make's support for
wildcards. Probably both.

> >   I think it's you who didn't understand. What exactly is this 'make'
> > abuse you are talking about?

> If you've never seen abuse of makefiles, then power to you. I think anyone 
> who has worked on an ugly system knows what I'm talking about. Otherwise, go 
> look up the "buildroot" system for compiling kernels.  I mean, hell, 
> buildroot was so makefile-abusive that people capable of working on the 
> linux kernel said "screw this, let's throw it away and start over."

  So some people have abused make to do something it's not designed to do?
Is that supposed to somehow be a negative point about make, or something?
I already forgot the whole point of this "abuse" thing or why you even
brought it up.

> >> The problem is not that you have to tell the compiler what to 
> >> compile. The problem is you have to (in C) compile much more than your own 
> >> source code in order to compile your program.
> > 
> >   You have odd problems. I haven't encountered such a problem as far as
> > I remember.

> Well, good for you. The fact that you've not encountered that problem 
> doesn't mean that the problem isn't real.

  But it could perfectly well mean that it's not as common as you make it
sound (which, honestly, wouldn't actually surprise me).

  Some people write bad code. In some such cases other people need to
decipher that bad code. It probably sucks. However, this problem is not
exclusively limited to C and its variants. (And from what I read at
the daily wtf, higher level languages seem to be much more prominently
represented than lower-level languages like C. Not that this means that
in an absolute scale the problems are not more common in C. However,
it does tell that such problems are also quite common even in higher-level
languages. They are in no way safe from idiotic programmers.)

> >   If I install a new library from a OpenSuse repository, I still don't have
> > to care where it's installing it. In fact, I don't even *know* where it's
> > installing them, and I don't need to. They will still work.

> Here you're arguing that someone else has already solved the problem for you.

  Yeah, isn't it great? The C/C++ library system isn't so bad as you make
it sound, after all. It works like a charm for me.

> >   Can this scheme sometimes cause *more* problems than when dealing with
> > C# on Windows using Microsoft's IDE? Probably. It hasn't bothered me too
> > much so far, though. 

> Great. Install compilers for three different versions of Linux for three 
> different architectures on the same machine. Make sure that you can use all 
> three different versions of boost you need on each of those three compilers. 
> Let me know how simple your makefiles are.

> (And you're giving *me* shit about not knowing how makefiles work? Really??)

  You are still making all this to be some kind of issue about makefiles.
I don't really understand why.

  Perhaps next you'll complain how your car broke and it will cost you an
arm and a leg to repair it, and this, too, has something to do with why
makefiles suck.

> >> You don't understand the word "sources" in that sentence?  Reading 
> >> comprehension, dear.
> > 
> >   I don't think I have the sources eg. for libc.so installed in this
> > system, hence I don't have to tell the compiler where they might be.

> Um, yes, you do. You have the sources for some of the openssl libraries 
> installed, don't you?

  Openssl libraries? I have no idea. Why should I even care?

> >   I don't get your point.

> Yes you do.

  No, I don't. You are writing about library sources now, and I have no
idea what you are talking about.

> >> The fact that you can automate (in some cases) the copying of dependencies 
> >> from one place to another does not mean you're not copying dependencies from 
> >> one place to another.
> > 
> >   And I asked why should I care if it happens automatically behind the
> > scenes.

> And I answered this repeatedly, and you picked nits instead about whether 
> invoking the C preprocessor is invoking the compiler or not.

  Your "answer" seems to be to endlessly repeat the duplication argument.
You are not telling me why I should care if the dependencies are duplicated,
if the duplication happens automatically.

-- 
                                                          - Warp

Post a reply to this message