Re: OT: Language War (Re: "C" Manual)
William T Wilson wrote:
>
> On Mon, 31 Dec 2001, Erik Steffl wrote:
>
> > consider perl which doesn't have strong types but it's quite
> > impossible to make it segfault and C++ on the other side which is
>
> That is true but it doesn't mean that type safety won't prevent it
> also. Consider a hypothetical language that doesn't have any dynamic
> resource allocation at all and has a very weak type system. Actually a
> shell scripting language is not very far from this. It can never segfault
> although it is still possible to have the same sort of bugs which cause
> segfaults.
are you trying to say same thing I said or are you saying the
opposite?
> > fairly dangerous even without casting (I would even go as far as
> > saying that casting makes no difference (statistally), but I'd have to
> > think about it).
>
> The presence of casting doesn't have too much of an impact on the
> reliability of a particular program (if anything it improves it because it
> means the programmer thought about what his data really meant) but a
> language that doesn't keep track of the type of its data on the
> programmer's behalf cannot detect many errors at compile-time.
wrong cast can lead to segfault, even if you'd use GC.
well, see perl. doesn't care about your types and still doesn't
segfault.
> It can make sure that the programmer doesn't try to access a field that
> isn't present in the type of data that the pointer is supposed to
> represent, but it can't make sure that the pointer actually points to that
> sort of data.
>
> The ability to check that the pointer points to the right type of data
> catches both a huge number of nuisance bugs *and* detects many types of
> segfaulting bugs even at compile time (and provides useful error
> descriptions even if it slips through to runtime).
providing you have pointers. again, compare perl and c++ - c++ has
fairly strong (not really strong) types and yet you can make it segfault
easily. perl doesn't care about types much but it doesn't segfault (of
course, it has to keep track of types internally but that's mostly
hidden from progammer).
> Programmers that haven't used a really strongly typed language may not
> even even realize that the compiler is able to catch these sorts of bugs.
perhaps...
> > most of the segfaults are because of the resource allocation
> > mistakes, not because of mistaken types... at last that's my
> > impression.
>
> In a lot of ways they are the same thing. Suppose you have a pointer to
> an integer, and you change it so it points to a dynamically allocated
> array of pointers to integers (i.e. a 2-dimensional array) - which is
> perfectly legal in C - and then you free() the pointer. Is this a
> resource allocation mistake or a type mistake? It's really a resource
> allocation mistake, but it's also a type mistake, and it's something that
> a compiler in a strongly typed language would catch.
a man was very poor. hungry all the time. finally got to hospital
emergency room with severe case of malnutrition.
you can say it's both economic problem and nutrion problem, but I
guess you would admit that economics and nutrition are separate
disciplines and that generally problems can be solved as economic
problems or nutrition problems...
don't mix the two. it just spoils the whole picture. the type problem
and the resource allocation problem are two separate problems, each can
be solved by different means.
> > note that in c++ there's basically no need for casting and using
> > void pointers (in general, there are special cases). That's of course,
>
> Casting you can't really get away from nor do you really need to. In fact
> the more strongly typed the language is, the more casting you have to do.
>
> (void) pointers on the other hand are generally not your friend :}
why wouldn't you get away from casting? requiring casting is usually a
design problem (in java it's language design problem, but it's getting
templates soon:-)
you might require casts in c for certain tasks...
erik
Reply to: