Re: C++ religious war (was: llua Higher-level C API for Lua)

[Sean Conner <sean@...>]

It was thus said that the Great steve donovan once stated:
> On Sun, Mar 23, 2014 at 3:45 AM, Tim Hill <drtimhill@gmail.com> wrote:
> > toward many+smaller source files). These days fewer+larger always seems to
> > me more sensible
> 
> Totally - as Sean indicated, the style is appropriate for libraries
> that have to be linked in statically by dumb linkers, not for
> applications.

  There are downsides to dynamic linking though---the resulting executable
does run slower (at least under Unix---I'm not sure how Windows handles
them).  That's because all calls to a function in a dynamically loaded
library go through a small stub routine---escentially:

		call	printf
		...

printf		jmp	real_printf_routine

all because of the way they're constructed (also to support lazy
loading---the final address is actually resolved at first call, so the stub
routine at first jumps to a resolving routine that patches the stub so that
subsequent calls go directly to the actual routine).

  Dynamic linking also allows one to intercept any library function with
LD_PRELOAD---whether that is a Good Thing or a Bad Thing depends upon your
point of view (programmers---it's a Good Thing as it allows testing and
debugging; sysadmins---it's a Bad Thing as it allows nasty things like root
kits to run).

> C headers continue to irritate me, after all these years - the less of
> them the better!

  Anything in mind on how to replace or remove them?  

> I've got more tolerance for big files than most (e.g. Lake as a single
> 3.5Kloc script) perhaps because I use bookmarks.  In the Lua world,
> there is little penalty for loads of little modules, but it leads to
> more 'accidental complexity' (Fred Brooks again).

  How so?

  -spc (Who tends to get antsy when a source file gets over 2k lines ... )