Re: Just starting off in obj C
Re: Just starting off in obj C
- Subject: Re: Just starting off in obj C
- From: Ian Joyner <email@hidden>
- Date: Sun, 26 Oct 2008 17:45:33 +1100
On 26/10/2008, at 3:27 PM, Chris Idou wrote:
--- On Sat, 10/25/08, Bill Bumgarner <email@hidden> wrote:
From: Bill Bumgarner <email@hidden>
Actually, the C standard encompasses both the C language
and the C runtime library, libC. libC includes printf style
formatting functions and, as such, the spec contains very exact
descriptions of the formatting string behavior therein.
Which doesn't actually solve everything. For example, it would be
quite a common thing in C to write a log() function that is
implemented via vsprintf and family, so that you are passing format
strings and arguments to functions other than the raw fprintf and
family functions, in which case you are out of luck for compiler
type checking. That's why I say its an ugly hack, regardless of how
well specified the standards documents are. Its also why most OO
languages I think have moved away from format strings, as inherently
ugly.
Sure -- the C runtime is brittle in the ways you mentioned
and thank
goodness tools like the Clang static analyzer and Valgrind
are
providing means of finding and eliminating such bugs.
Of course, retro-fitting static analysers to inherently unsafe
languages, can only go so far. Static analysis has its limits.
I agree. I have never liked tools like lint. A well-defined language
with well-implemented compilers should not need after-the-fact hacks.
That wasn't the point, though. At compilation time,
the C language is
relatively non-brittle. By ensuring most of the warnings
provided by
the compiler are enabled, that your code compiles without
warnings,
and that you aren't doing various rather dangerous
casting operations,
the compile time brittleness of C is greatly mitigated.
Well, if C isn't brittle, I'm not sure what language would be. One
classic example is that foo(i++) could give a different value for i,
depending if foo is a function or macro. That's pretty brittle I
think, and one reason other languages have shunned brittle features
like simplistic macros.
Probably my fault for introducing the term "brittle" which can mean
and be applied to a number of factors. What I mean is that definition
of a language should bear in mind what happens when a program evolves,
what kinds of changes programmers make. If you make one small policy
change, it should not cause a whole lot of rework – if it does, that
is an aspect that is brittle.
Ian _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden