Re: Panda Bears will die, Sloths will live on

[Sean Conner <sean@...>]

It was thus said that the Great Patrick Mc(avery once stated:
> On 11-10-18 07:16 PM, Elias Barrionovo wrote:
> >Its because you haven't included system libraries that themselves
> >other libraries and so on. In the end, if you include stdio.h just to
> >have a single printf function (for, say, a hello world) you end up
> >with loads and loads of other stuff stuff.
> Thanks Elias
> 
> So would the verbosity not be coming from the "hello world" code and not 
> the strange mid-file include? I don't understand the relation to the 
> discussion if so?

  The verbosity is coming from the include files.  Without them, the
following example code:

int main(int argc,char *argv[])
{
  double a;
  
  if (argc < 2)
  {
    fprintf(stderr,"usage: %s number\n",argv[0]);
    return EXIT_FAILURE;
  }
  
  a = strtod(argv[1],NULL);
  
  printf("%f\n",sin(a));
  return EXIT_SUCCESS;
}

won't even compile.  First off, because EXIT_FAILURE, EXIT_SUCCESS and
stderr aren't defined (they're defined in ANSI C).  So you need stdio.h and
stdlib.h for those.  Adding those explodes the 15 lines of code to 1,820
lines of code ("gcc -E c.c" to see the output).  Yes, within those 1,820
lines of code is the definition for stderr and EXIT_FAILURE/EXIT_SUCCESS are
translated to their proper numeric values (they're defined as #define).  

  But even then, the code may not run properly because the parameters and
return types of sin() aren't defined---for that, you need math.h (and now
we're up to 2,486 lines of code the C compiler chews through).  Most people
don't think about it because, well ... it's invisible and on a fast machine
it's not really noticible that the compiler is chewing through so much code.

  And if you start looking into header files, you'll see stuff like

	#ifndef _STDIO_H
	#define _STDIO_H

	/* blah blah blah */

	#endif

to prevent multiple inclusions from messing things up, and trust me on this,
it's not uncommon for a single header file to be included multiple times
from multiple places.  I just checked the output from one of my programs
which includes 29 header files, the file 

/usr/lib/gcc/i386-redhat-linux/3.4.6/include/stddef.h

ended up being included a total of 21 times.  20 of those times nothing was
included because of the heade guard (as it's called).  In total, 97 files
were ultimately included.  It's for these types of reasons (and C++ is even
worse in this regard) that just plain including files is not really liked
all that much by programmers.  As the program/project gets larger, you are
more likely to include the same file multiple times and unless you are
prepared for it, it's going to hurt (in the case of C, you'll started seeing
redeclaration errors; for a dynamic language like Lua, you'll probably
notice subtle bugs that are hard to track down).

  Now, going back to PHP for a moment---I worked on a web project where the
PHP system had to chew through over 15,000 lines of code (all due to those
dumb includes) before it even *started* processing the web request.  Yeah,
PHP is simple.  Yeah, you can include PHP code.  Yeah, PHP has an include
and include_once functions.  Yeah, it gets nasty quickly.

  -spc