Re: OT: Language War (Re: "C" Manual)
On Mon, 31 Dec 2001 13:46:15 -0800, Erik Steffl <steffl@bigfoot.com> wrote:
> Richard Cobbe wrote:
> >
> > Lo, on Sunday, December 30, Dimitri Maziuk did write:
> >
> > > * William T Wilson (fluffy@snurgle.org) spake thusly:
> > > ...
> > > > So... why *should* the programmer concern himself with individual
> > > > bytes of memory? (Assuming he is writing an ordinary application and
> > > > not a hardware driver or something similar).
> > >
> > > Because if he does not, his application will segfault and dump core.
> >
> > No. This level of concern is necessary only for non-type-safe
> > languages. It is provably impossible for a program written in a
> > type-safe language to segfault (assuming that the language's run-time
> > system is implemented correctly, of course).
>
> ???
>
> it's the resource allocation that's important, not types. garbage
> collectors are generally more robust as far as segfaulting (and similar
> errors) go (of course, just because the program doesn't segfault it
> doen't mean it's working correctly). the other important factor is how
> much runtime check language does (e.g. checking for array boundaries
> etc.)
But it's the type safety of the language that prevents the abuse of
memory, not how it was allocated. Strong typing eliminates a huge
number of error cases. C and C++ both subvert the ability of the
compiler to do static type checking via casts and void pointers. Strong
static type checking also has the possible advantage that the compiler
can better optimize the generated code.
> and as far as runtime system goes - only interpreted languages have
> runtime systems.
Well, I dare you to remove 'ld' or 'libc.so' and see how many programs
run ;-) I think it's fair to characterize required language libraries
as part of the "run time" system. Whether or not a program is statically
compiled is unimportant, as the language library still performs actions
at runtime that "your" program depends on, and which "your" program
could not function without. Among those things, might be checking
array accesses and raising exceptions for range errors...
--
Eric G. Miller <egm2@jps.net>
Reply to: