On Tuesday 09 June 2009, Rick Altherr wrote:
> > although this is the first time I've ever
> > heard anyone apply that term to C. ...
>
> I've commonly heard C and C++ referred to as strongly-typed.
Never *once* have I heard that usage before yours. Usually C gets
described as a weakly/loosely typed language. (This is in the
context of multiple classes and seminars that did comparative
studies of dozens of programming languages and type systems.)
> The fact
> that you can't declare a variable without a type is an indication of
> this.
No; it just means they have types, and require declarations.
But in fact, C doesn't require, and never has required, types
for everything. I just compiled the following; no errors, and
not even any warnings unless I specify "-std=c99".
main(argc, argv)
{
argc = argv;
return 0;
}
Over time, C has integrated mechanisms that lets one's code
trigger warnings from some flavors of type abuse. But at
its core, it's still weakly typed.
Plus, having a declaration says nothing about whether that
will be "strongly" enforced, or can instead be suborned.
> void * let's you work around some undesirable effects of strong-
> typing, but it is a type itself.
That "work around" means "violate any type rules you want",
which is prima facie evidence that the type system is not
what's called "strong" ... either at compile time, or at
run time.
Contrast that to something like LISP or Lua ... or even TCL.
In key ways, those have stronger typing than C: they have
only a handful of data types and you can't escape them.
(That property is also a flavor of what's called "safety",
and one which lends itself to crash-free software. C is
not known for being crash-free; neither is C++.)
But on the flip side their type systems are not extensible,
so when you build abstraction layers you've got to define
your own typing conventions. Which can't be enforced at
compile time (another aspect of "safety", which would help
some other robustness characteristics), so they're weak in
those respects. Yet C provides some extension mechanisms...
:)
> > However, I'm all in favor of evolving code to respect clearly defined
> > data types, which encapsulate roles and responsibilities to support
> > better system structures. If there's a better way to do it, I've not
> > yet come across that answer. :)
>
> That's really all I'm recommending. I've seen a dynamic- and strongly-
> typed language do very well for doing encapsulation and using ADTs to
> make a very clean system architecture that allows for lots of future
> extensions.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
