Re: Theodore Adorno, a prophet of data systems design
From: goose (ruse_at_webmail.co.za)
Date: 01/09/04
- Next message: Joseph Dionne: "Re: What IS Intelligence"
- Previous message: Richard Heathfield: "Re: Theodore Adorno, a prophet of data systems design"
- In reply to: Edward G. Nilges: "Re: Theodore Adorno, a prophet of data systems design"
- Next in thread: Richard Heathfield: "Re: Theodore Adorno, a prophet of data systems design"
- Reply: Richard Heathfield: "Re: Theodore Adorno, a prophet of data systems design"
- Reply: Randy Howard: "Re: Theodore Adorno, a prophet of data systems design"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 9 Jan 2004 06:18:45 -0800
spinoza1111@yahoo.com (Edward G. Nilges) wrote in message news:<f5dda427.0401081358.16e2244@posting.google.com>...
> Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<btiu3i$2ms$1@titan.btinternet.com>...
<snipped>
> > Rule 1) Do not invoke undefined behaviour, at all, ever, in any of your C
> > code.
>
> This isn't a useful rule. Characteristic of a useful rule would be
> that it would say "how" to avoid an undesirable result.
>
1. dont dereference invalid pointers.
2. dont generate trap values.
3. dont call functions with invalid arguments.
did I miss anything?
> Advising programmers to memorize the standard is silly.
but those are the rules. would you consider someone who
wrote buggy C# code by misusing C# a "good" programmer?
>
> >
> > Rule 2) Whenever you allocate memory, ensure that the program frees that
> > memory at some point. (I ensure this in my own programs by wrapping up
> > memory allocations in a well-defined way, and tracking them in the log
> > file. I have a program which reads the log file looking for leaks.)
> >
> Which means, of course, that the leaks occur even for you.
>
> My dear fellow, I have long since fallen prey to the false idea that
> the more elaborate the test and bug prevention facilities, the more
> likely they are to create, themselves, bugs, or to interact with other
> facilities to create bugs.
>
> Several objections therefore arise to your "leak log file".
>
> (1) I would suppose that the log file goes on disk, but if your code
> runs embedded or on a thin client, no disk is available.
not to worry, if my embedded device has at least 2 free output
pins, I can log it somewhere else (desktop PC maybe)?
>
> (2) Program maintainers are constrained to follow the rules of the
yes. the *RULES* of the language.
> language to compile the program but in no wise constrained to follow
> your protocol especially if they find it incomprehensible.
>
the *RULES* of the language are simple in this regard: free memory you
allocate. if they follow the rules of the language, then there is no
problem.
> (3) The solution won't work for multiple threads or processes.
yes it will; writing multiple threads in means that you
will *at* *least* have a seperate output thread. where is the
problem?
<snipped>
>
> The time for such cleverness is PAST.
why ? the OS you will be most likely using in 5 years will be
written in C, not <some other language>.
<snipped>
>
> There are no objects in C.
the standard (remember the *RULES* you went on about further
up?) defines objects in C.
your pet language may use the term "object" for something else
entirely, but as far as the C *RULES* are concerned, there /are/
objects.
>
> > don't, don't. Everything has a cost, including initialisation. If your code
> > writes to an object before it reads from it, the initialisation is a
> > redundant overhead.
> >
> > Personally, I /do/ initialise anyway, because /I/ think it makes my
> > debugging easier if the program is in a deterministic state at all times,
>
> ...which means you are not equal to the task of debugging a multiply
> threaded program which will be in a nondeterministic state some of the
> time,
how do you figure that? if each thread runs in a well-synchronised
state-machine, at any given point in the program, the program *is*
deterministic.
> and in which your job is NONETHELESS to guarantee a
> deterministic result in the sense of weakest post-condition.
>
you forget, EGN, that the C *RULES* are very clear with regard to
uninitialised variables.
>
> > but it's not for me to force my style decisions on others.
> >
> > <snip>
> >
> > >> > strange behavior near undocumented limits (a practice
> > >>
> > >> there are no undocumented limits, as far as I know. feel free
> > >> to prove me wrong by posting the list of undocumented limits.
> > >>
> > > Not in C. However, the way in which C allocates arrays and fails to
> > > provide hash tables as part of the language encourages secret decision
> > > making which should be the user's as when the programmer allocates the
> > > array as 1024 because 1024 seems like a big number.
> >
> > C makes the allocation of fixed-size arrays possible because there are some
> > situations where fixed-size arrays are desirable. As the smallest example I
> > can think of, if for some reason you want to reverse an octet's bit order,
> > you might reasonably do it like this:
> >
> > unsigned char reverse_octet(unsigned char ch)
> > {
> > static unsigned char nybble_r[16] =
> > {
> > 0, 8, 4, 12, 2, 10, 6, 14, 1, 9, 5, 13, 3, 11, 7, 15
> > };
> > unsigned char result = nybble_r[ch & 0xF] << 4;
> > ch >>= 4;
> > return result | nybble_r[ch & 0xF];
> > }
> >
> > No matter how much the user might like to think otherwise, an octet is never
> > going to have more than 8 bits (a byte is a different matter, obviously).
> > The name is a real giveaway, you see. So a 16-element nybble array is
> > always adequate. Fixed-size arrays /do/ have their place.
> >
> > If you use a fixed-size array when you should have used a dynamic array,
> > that's your fault. C provides dynamic array support. If you don't use it
> > when it's appropriate, don't blame the language.
> >
> > As for hash tables, they are trivial to implement using dynamic arrays. If
> > you're not able to write your own hash table, C is clearly not your
> > language.
>
> Of course, there is an example at my Web site in virtualString.
> >
> > > One of my issues with using C on a VMS system to develop a "C-like"
> > > compiler
> >
> > If indeed you did...
> >
> > > for business rules was I did not want to in any way bound the
> > > complexity of the rules. But all I had in C was the linked list
> > > perhaps with a hash index. I found the repeated coding of linked lists
> > > tedious and not suitable work for a gentleman.
> >
> > If you'd been clever, you'd have written one linked list ADT, and re-used
> > it. That's really the whole point of C, you see - code re-use.
>
> No, a UDT (not ADT, whatever that is)
my first year univ. textbook introduced the students to ADT's (no,
we were not being taught C). a quick mental review of my library (not
currently with me) comes up with a total of 7 programming books with
the term ADT in it.
What is a UDT?
(umlaat data type?)
<snipped>
> > >> > and the eternal green screen (a practice fostered by
> > >> > C's favorite OS).
> >
> > C is OS-blind.
>
> This isn't true. I taught SAS C for the IBM mainframe and despite the
> fact that SAS C conformed to the standard, it could not expect the
> same results for character comparisions as were expected in C running
> on ASCII machines.
>
then its one of two things:
a) your code used implementation-defined behaviour.
b) the compiler vendor lied to you[1].
if you can post the code, the C people here can verify
whether or not you followed the C *RULES*.
notes:
[1] yes, this happens often.
goose
regards
- Next message: Joseph Dionne: "Re: What IS Intelligence"
- Previous message: Richard Heathfield: "Re: Theodore Adorno, a prophet of data systems design"
- In reply to: Edward G. Nilges: "Re: Theodore Adorno, a prophet of data systems design"
- Next in thread: Richard Heathfield: "Re: Theodore Adorno, a prophet of data systems design"
- Reply: Richard Heathfield: "Re: Theodore Adorno, a prophet of data systems design"
- Reply: Randy Howard: "Re: Theodore Adorno, a prophet of data systems design"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
