Re: OT: Language War (Re: "C" Manual)
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.
> 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.
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).
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.
> 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.
> 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 :}
Reply to: