UNIX, C, Perl

jacob navia wrote:

>
I think it is important to distinguish between read
and write access to tables. I use

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

You know this to be false. You asked a question about this on c.l.c++.

This is done to support read only data types, what is very hard in C++.

Far from it, it is simple.

--
Ian Collins.

Sep 6 '08 #152

Richard Heathfield wrote:

jacob navia said:

<snip>

>The main application domain I see [for operator overloading] is the
capacity of defining new types
of numerical data in C and keep the infix notation. You can't argue that
complicated fromula are more easily written using the notation we
learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

100% agreed. (And this is *me* saying it!)

I'm trying to work out how it would work for strings. It would be great to
be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s = t + n
instead of sprintf(s, "%s%d", t, n) - but that's going to make for an
almighty clash with ordinary pointer arithmetic. Any ideas?

C doesn't have strings. The solution would be to add them.

--
Ian Collins.

Sep 6 '08 #153

Richard Heathfield wrote:

s0****@gmail.com said:

>On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.

I already use constructors and destructors in C, so I know what you mean,
but it isn't quite what /I/ meant. In C, I have to call constructors and
destructors explicitly, and I'm fine with that. But if ISO were to
introduce operator overloading into C, I think there would be a lot of
pressure to introduce automatically-invoked constructors and destructors,
because (so it seems to me) there would be much more cleanup to do than is
at present the case, and the cost of overlooking cleanup could become
arbitrarily high.

lcc-win solves this with the gc (garbage collector). This solution is
much more advanced than constructors/destructors since it allows you
to forget the accounting needed for each malloc() call.

Another solution is to do the following:

typedef struct tagString {
char *str; // data
size_t length; // used data
unsigned flags;
} String;

typedef struct tagStringToken {
int len; // number of strings
char *strArray[];
}

StringToken operator+(String a,String b)
{
// this takes two strings and produces a
// string token with len 2 and an array of
// pointers of 2 dimensions. For instance for
// "abc" + "def" it would produce the
// equivalent of {2,{"abc","def"}}
// Obviously, the array is malloced
}

StringToken operator+(String a, StringToken b)
{
// This adds just one more string to the array,
// incresing the "len" counter. Note that a
// realloc is needed for the new array
}

StringToken operator=(String &a, StringToken b)
{
// This is the assignment to the final result.
// It allocates a string, adds all the substrings
// into a single one, constructing the result string
// with NO need for any destructors
}

Now seeing this in action:

String c = "first"+"second+"third";

"second"+"third" results in a StringToken
that is added to "first", resulting in a new
string token that is then assigned to the string
that contains the result.

>>>but what about the intermediate strings?
You would handle those the same way you handle intermediate values in f
= 1 + 2 + 3 + 4 + 5 in current C.

The whole thing is very un-C-like.
Yes. It's beginning to look remarkably C++-like, though.

If by C++-like you mean modern, then yes :-)

No, I don't mean that. C is just about as modern as C++ is. It's just
*different*. Adding operator overloading would make it slightly less
different, and adding constructors and destructors would make it slightly
less different still, but that wouldn't make it any more "modern".

I agree. Operator overloading is quite old, used in almost all
languages (Fortran, C#, etc)

But it *is* useful.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 6 '08 #154

Bartc

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:To*********************@bt.com...

Bartc said:
>Richard Heathfield wrote:
<snip>

>>>
I'm trying to work out how it would work for strings. It would be great
to be able to say s = t + u instead of sprintf(s, "%s%s", t, u) and s =
t + n instead of sprintf(s, "%s%d", t, n) - but that's going to make for
an almighty clash with ordinary pointer arithmetic. Any ideas?

t + u is addition of two pointers, which has at present no meaning in C.

Yeah, actually I thought a bit after hitting Send (always the way, ain't
it?), and it occurred to me that it /couldn't/ work for C strings, but it
could work for a new type, xstring or whatever.

I meant that t+u could work, because it doesn't clash with any other meaning
for t+u.

>t + n adds an integer to a pointer, and would be a problem, but it's not
unreasonable to require a conversion, eg: t + str(n).

But this would work:

xstring s, t;
t = "come in, number ";
s = t + 42;
s += "; your time is up.";

provided we didn't ever want to treat xstring as a pointer.

I've never been keen on mixing strings and numbers like this. What would be
the result of "123"+456, "123456" or 579? And if you had "123"+A, you
wouldn't have control over the formatting of A.

>
>More difficult is how to deal with the implicit memory handling which
needs to be done:

a = b + c + d + e

You might be able to do free(a),

No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

Well, I think it /could/ be done with ordinary strings (or rather, char*
objects). But this is little to do with operator overloading, which gives
little help anyway; the same problem is there using:

a = addstring(addstring(addstring(b,c),d),e);

It would need some compiler help and the result might look like:

a = addstring(temp2=addstring(temp1=addstring(b,c),d), e);
free(temp1); free(temp2);

with the requirement that addstring() returns a 'clean' char* value that
does not point at shared storage.

>
>but what about the intermediate strings?

You would handle those the same way you handle intermediate values in f =
1
+ 2 + 3 + 4 + 5 in current C.

I don't think so. These primitive values can live in registers and take no
heap storage, unlike strings.

--
Bartc

Sep 6 '08 #155

Ian Collins wrote:

jacob navia wrote:
>I think it is important to distinguish between read
and write access to tables. I use

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

You know this to be false. You asked a question about this on c.l.c++.

>This is done to support read only data types, what is very hard in C++.

Far from it, it is simple.

This is "simple" in C++ jargon, that I did not bother to
dig further.

It is not doable within the context we are discussing here.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 6 '08 #156

Ian Collins wrote:

C doesn't have strings. The solution would be to add them.

Well, operator overloading makes strings in C possible.

I have developed within lcc-win a full string package
(counted strings of course) with strings that
never overflow their buffers.

They use the natural syntax of
String s;
s[2] = 'e';

to access the members. They can be read-only
etc.

Just download lcc-win and you can see it in action, source
is provided.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 6 '08 #157

Andrew Poelstra

On 2008-09-06, jacob navia <ja***@nospam.comwrote:

Richard Heathfield wrote:
>s0****@gmail.com said:

>>On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.

I already use constructors and destructors in C, so I know what you mean,
but it isn't quite what /I/ meant. In C, I have to call constructors and
destructors explicitly, and I'm fine with that. But if ISO were to
introduce operator overloading into C, I think there would be a lot of
pressure to introduce automatically-invoked constructors and destructors,
because (so it seems to me) there would be much more cleanup to do than is
at present the case, and the cost of overlooking cleanup could become
arbitrarily high.

lcc-win solves this with the gc (garbage collector). This solution is
much more advanced than constructors/destructors since it allows you
to forget the accounting needed for each malloc() call.

Another solution is to do the following:

typedef struct tagString {
char *str; // data
size_t length; // used data
unsigned flags;
} String;

typedef struct tagStringToken {
int len; // number of strings
char *strArray[];
}

StringToken operator+(String a,String b)

How would the compiler know to make a StringToken given the
context of two strings? What if you also had something like

OtherString operator+(String a, String b)

How would the compiler know what (string + string) should
evaluate to, a StringToken or an OtherString?

Aside from that, this seems like a pretty elegant solution,
at least from the perspective of someone outside the black
box ;-)

<remainder snipped>

--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net

Sep 6 '08 #158

jacob navia wrote:

Richard Heathfield wrote:
>>
I already use constructors and destructors in C, so I know what you
mean, but it isn't quite what /I/ meant. In C, I have to call
constructors and destructors explicitly, and I'm fine with that. But
if ISO were to introduce operator overloading into C, I think there
would be a lot of pressure to introduce automatically-invoked
constructors and destructors, because (so it seems to me) there would
be much more cleanup to do than is at present the case, and the cost
of overlooking cleanup could become arbitrarily high.

lcc-win solves this with the gc (garbage collector). This solution is
much more advanced than constructors/destructors since it allows you
to forget the accounting needed for each malloc() call.

It isn't more advanced, it just solves a different problem.

--
Ian Collins.

Sep 6 '08 #159

Bartc

"jacob navia" <ja***@nospam.comwrote in message
news:g9**********@aioe.org...

Richard Heathfield wrote:
>s0****@gmail.com said:

>>On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain
amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.

It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.

I already use constructors and destructors in C, so I know what you mean,
but it isn't quite what /I/ meant. In C, I have to call constructors and
destructors explicitly, and I'm fine with that. But if ISO were to
introduce operator overloading into C, I think there would be a lot of
pressure to introduce automatically-invoked constructors and destructors,
because (so it seems to me) there would be much more cleanup to do than
is at present the case, and the cost of overlooking cleanup could become
arbitrarily high.

typedef struct tagString {

typedef struct tagStringToken {
int len; // number of strings
char *strArray[];
}

StringToken operator+(String a,String b)

StringToken operator+(String a, StringToken b)

StringToken operator=(String &a, StringToken b)

Now seeing this in action:

String c = "first"+"second+"third";

"second"+"third" results in a StringToken
that is added to "first", resulting in a new
string token that is then assigned to the string
that contains the result.

That's a neat idea, although I can see it getting complicated if other
string ops are introduced (such as "abc" * 5), or you want to call functions
taking or returning ordinary char* values.

But why has suddenly the precedence of "+" become right-to-left?

--
Bartc

Sep 6 '08 #160

Andrew Poelstra wrote:

On 2008-09-06, jacob navia <ja***@nospam.comwrote:
>Richard Heathfield wrote:
>>s0****@gmail.com said:

On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.invalidwrote:
<snip>
No, because 'a' wouldn't be a simple pointer - it would need to be an
object (in the C sense at the very least) that contains a certain amount
of state, so I think we're going to need a destructor of some kind. Ah,
this is where the C++ pollution begins, I see.
>
It has little to do with C++. Wherever there are the concepts of
"object" and "state", there are the concepts of "constructor" and
"destructor". C is no exception.
I already use constructors and destructors in C, so I know what you mean,
but it isn't quite what /I/ meant. In C, I have to call constructors and
destructors explicitly, and I'm fine with that. But if ISO were to
introduce operator overloading into C, I think there would be a lot of
pressure to introduce automatically-invoked constructors and destructors,
because (so it seems to me) there would be much more cleanup to do than is
at present the case, and the cost of overlooking cleanup could become
arbitrarily high.

lcc-win solves this with the gc (garbage collector). This solution is
much more advanced than constructors/destructors since it allows you
to forget the accounting needed for each malloc() call.

Another solution is to do the following:

typedef struct tagString {
char *str; // data
size_t length; // used data
unsigned flags;
} String;

typedef struct tagStringToken {
int len; // number of strings
char *strArray[];
}

StringToken operator+(String a,String b)

How would the compiler know to make a StringToken given the
context of two strings? What if you also had something like

The compiler doesn't know anything. It just applies the
operator + to a string and another string. Then, it sees
that the result is a thing called "StringToken". It searches
for an overloaded operator of string + stringtoken and
finds one, then it applies it, until it sees the
assignment. It looks for an overloaded operator
assignment with at the LHS a String and the right
hand side a StringToken since that is the result of the
last addition. It finds one and then it applies that to the
two operands.

OtherString operator+(String a, String b)

How would the compiler know what (string + string) should
evaluate to, a StringToken or an OtherString?

Because you told the compiler so by defining

StringToken operator+(String,String);

Now the compiler knows that when it sees an addition
of a string to a string it should call the function
so defined.

Aside from that, this seems like a pretty elegant solution,
at least from the perspective of someone outside the black
box ;-)

<remainder snipped>

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 6 '08 #161

Keith Thompson

Andrew Poelstra <ap*******@supernova.homewrites:
[...]

Well, C strings are objects of type pointer-to-char,

[...]

No, a C string is "contiguous sequence of characters terminated by and
including the first null character". You're thinking of a "pointer to
a string", defined as "a pointer to its [the string's] initial (lowest
addressed) character". C99 7.1.1p1.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Sep 6 '08 #162

Keith Thompson

Ian Collins <ia******@hotmail.comwrites:
[...]

C doesn't have strings. The solution would be to add them.

I presume that "C doesn't have strings" is a verbal shorthand for
something like "C doesn't have strings that can be conveniently
manipulated as first-class objects". C certainly does have strings;
see C99 7.1.1p1.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Sep 6 '08 #163

jacob navia wrote:

Ian Collins wrote:
>jacob navia wrote:
>>I think it is important to distinguish between read
and write access to tables. I use

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

You know this to be false. You asked a question about this on c.l.c++.

>>This is done to support read only data types, what is very hard in C++.

Far from it, it is simple.

This is "simple" in C++ jargon, that I did not bother to
dig further.

It is not doable within the context we are discussing here.

So you can post something you know to be false but a correction is not
applicable?

If you had bothered to look beyond the end of your nose, you would have
found there is an idiomatic solution.

--
Ian Collins.

Sep 6 '08 #164

Keith Thompson wrote:

Ian Collins <ia******@hotmail.comwrites:
[...]
>C doesn't have strings. The solution would be to add them.

I presume that "C doesn't have strings" is a verbal shorthand for
something like "C doesn't have strings that can be conveniently
manipulated as first-class objects". C certainly does have strings;
see C99 7.1.1p1.

Well yes, the snipped context should have made that clear.

--
Ian Collins.

Sep 6 '08 #165

jacob navia wrote:

Richard wrote:

>I would sooner boil my nuts in a vat of sun flower oil than agree
that operator overloading in C is a good idea.

Should I send you olive oil maybe?

Ahh. The first real progress seen in this thread. :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Sep 6 '08 #166

Keith Thompson

jacob navia <ja***@nospam.comwrites:
[...]

lcc-win solves this with the gc (garbage collector). This solution is
much more advanced than constructors/destructors since it allows you
to forget the accounting needed for each malloc() call.

[...]

Garbage collection manages one resource, allocated memory.
Constructors and destructors can manage any arbitrary resource.
Admittedly memory is often the most important resource in a program,
but it's not always the only one.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Sep 6 '08 #167

Richard

Ian Collins <ia******@hotmail.comwrites:

Keith Thompson wrote:
>Ian Collins <ia******@hotmail.comwrites:
[...]
>>C doesn't have strings. The solution would be to add them.

I presume that "C doesn't have strings" is a verbal shorthand for
something like "C doesn't have strings that can be conveniently
manipulated as first-class objects". C certainly does have strings;
see C99 7.1.1p1.

Well yes, the snipped context should have made that clear.

Well yes, but the on going game of "oneupsmanship" played by the 3 or 4
main posters to c.l.c would be severely hampered if people actually
maintained context or allowed even slight discrepancies through in what
would, otherwise, be a perfectly understandable and helpful thread.

I dont think I was ever so confused as to what a string was until I saw
an explanation or two in this newsgroup ....

Sep 6 '08 #168

Malcolm McLean wrote:

"Nick Keighley" <ni******************@hotmail.comwrote:

>Telephone numbers suffer from the same problem. Hence London (UK)
got renumbered *twice* in recent years.

I'm of the opinon that 3074457345 telephones ought to be enough
for anyone, if 64 bit integers were distributed fairly instead
of being hogged by the rich nations.

However I have a strong suspicion that 18,446,744,073,709,551,615
available URLs will suffice until the plague of humans
self-exterminates.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Sep 6 '08 #169

jacob navia wrote:

>

.... snip ...

>
The main application domain I see is the capacity of defining new
types of numerical data in C and keep the infix notation. You
can't argue that complicated fromula are more easily written
using the notation we learned at school.

It *is* easier to write
c = a+b
than c = sum(a,b);

Yes we can argue. In C (not C++), the function 'sum' will have
defined types and ranges for the arguments a and b, and will
produce a functional result according to some rules (totally
exposed by the code of 'sum'). Thus the results validity and value
is clearly defined. However, the '+' operator is already
overloaded, in that it can at least have byte, short, int, long,
float, double parameters, possibly mixed. Thus evaluating the
correctness of "c = a + b" requires careful consideration.

I consider the correctness and readability of a statement to be
more important than its terseness.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Sep 7 '08 #170

Richard Bos

CBFalconer <cb********@yahoo.comwrote:

jacob navia wrote:
Richard wrote:

I would sooner boil my nuts in a vat of sun flower oil than agree
that operator overloading in C is a good idea.
Should I send you olive oil maybe?

Ahh. The first real progress seen in this thread. :-)

For boiling nuts, arachis oil is the obvious choice.

Richard

Sep 8 '08 #171

Anand Hariharan

On Sep 4, 6:15*pm, Flash Gordon <s...@flash-gordon.me.ukwrote:

jacob navia wrote, On 04/09/08 00:08:
Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.

I've seen a lot of bugs in code written in simpler languages.

Could you elaborate? What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

- Anand

Sep 8 '08 #172

rio

"jacob navia" <ja***@nospam.comha scritto nel messaggio
news:g9**********@aioe.org...

Richard wrote:
It *is* easier to write
c = a+b
than c = sum(a,b);

the answer is not full
it will be full if

c = a+b;
if(c==ERRORVALUE) goto error;

or

c = a+b;

and some definition of exception in case of overflow c

Sep 8 '08 #173

REH

On Sep 6, 1:44*pm, jacob navia <ja...@nospam.comwrote:

TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

* * * * table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

This is done to support read only data types, what is very hard in C++.

nonsense.

Read:
const TYPE& operator[](std::size_t i) const;

or, if you prefer by value:

TYPE operator[](std::size_t i) const;

Write:
TYPE& operator[](std::size_t i);

x = y[1]; would call the operator with the read prototype.

y[1] = x; would call the operator with the write prototype.

Sep 8 '08 #174

Anand Hariharan wrote, On 08/09/08 16:19:

On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
>jacob navia wrote, On 04/09/08 00:08:
>>Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.
I've seen a lot of bugs in code written in simpler languages.

Could you elaborate? What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

Depending on your definition of simpler, I have...

Z80 assembler. This is a nice fairly simple assembly language and I've
seen lots of bugs in code written in it. It certainly was mainstream
back when I started using it, and there are a lot of NSC800 processors
(the military equivalent with a few extra built-in peripherals) still
flying around.

Pascal. This is simpler in terms of being in general a higher level
language without OO (which Jacob considers complex, and not without
reason), and I've seen lots of bugs in Pascal.

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.
--
Flash Gordon

Sep 8 '08 #175

jameskuyper

Flash Gordon wrote:
....

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

simpler := "more like C"

:-)

Sep 8 '08 #176

ja*********@verizon.net wrote, On 08/09/08 20:32:

Flash Gordon wrote:
...
>Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

simpler := "more like C"

:-)

#define := =
#define = ==
#define Pascal C
#define :=) ;-)
--
#define Flash Mark
Flash Gordon

Sep 8 '08 #177

Flash Gordon wrote:

Anand Hariharan wrote, On 08/09/08 16:19:
>On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
>>jacob navia wrote, On 04/09/08 00:08:
Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.
I've seen a lot of bugs in code written in simpler languages.

Could you elaborate? What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

Depending on your definition of simpler, I have...

Z80 assembler. This is a nice fairly simple assembly language and I've
seen lots of bugs in code written in it. It certainly was mainstream
back when I started using it, and there are a lot of NSC800 processors
(the military equivalent with a few extra built-in peripherals) still
flying around.

Pascal. This is simpler in terms of being in general a higher level
language without OO (which Jacob considers complex, and not without
reason), and I've seen lots of bugs in Pascal.

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

I did NOT say that C has no bugs. Read what I wrote again:

>>jacob navia wrote, On 04/09/08 00:08:
Simple languages are easier to
understand and use, and have less surface for bugs.

Is that clear to you now?

"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

I consider C++ a very complex language where bugs have a lot more
places to hide.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 8 '08 #178

Anand Hariharan

On Sep 8, 6:14*pm, jacob navia <ja...@nospam.comwrote:

Flash Gordon wrote:
Anand Hariharan wrote, On 08/09/08 16:19:
On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
jacob navia wrote, On 04/09/08 00:08:
Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.
I've seen a lot of bugs in code written in simpler languages.

Could you elaborate? *What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

Depending on your definition of simpler, I have...

Z80 assembler. This is a nice fairly simple assembly language and I've
seen lots of bugs in code written in it. It certainly was mainstream
back when I started using it, and there are a lot of NSC800 processors
(the military equivalent with a few extra built-in peripherals) still
flying around.

Pascal. This is simpler in terms of being in general a higher level
language without OO (which Jacob considers complex, and not without
reason), and I've seen lots of bugs in Pascal.

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

I did NOT say that C has no bugs. Read what I wrote again:

*>>jacob navia wrote, On 04/09/08 00:08:
*>>>Simple languages are easier to
*>>>understand and use, and have less surface for bugs.

Is that clear to you now?

"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

Jacob - From what I read of Flash's response to my post, I understood
him as saying 'Jacob believes Pascal and/or Object Orientation to be
complex, and he is justified in believing it to be so'.
Flash - I agree with you in that, I consider Pascal to be simpler than
C. Since I have never had to maintain a code base in Pascal (my only
stint with Pascal was as a freshman in college, and I very likely
wrote buggy code, but I never had to review enough Pascal code to
uncover bugs), I can't offer an opinion about which language is
(inherently) more easily susceptible to bugs.
- Anand

Sep 8 '08 #179

Anand Hariharan wrote:

>

.... snip ...

>
Flash - I agree with you in that, I consider Pascal to be simpler
than C. Since I have never had to maintain a code base in Pascal
(my only stint with Pascal was as a freshman in college, and I
very likely wrote buggy code, but I never had to review enough
Pascal code to uncover bugs), I can't offer an opinion about
which language is (inherently) more easily susceptible to bugs.

I can. I spent many years concentrating on Pascal, building Pascal
systems and Pascal applications. Properly used Pascal is much less
bug susceptible than C. The point is that most such bugs will
appear at compilation time, and the code need never be run to debug
them. It is especially important to properly type design the
elements.

There is virtually no advantage for those who just write C using
Pascal code.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Sep 9 '08 #180

jacob navia wrote:

>
I consider C++ a very complex language where bugs have a lot more
places to hide.

While it is complex, it offers bigger hammers to squash bugs!

Like many new toys, C++ adds the tools to eliminate common C bugs, while
introducing plenty of scope for bugs of its own.

--
Ian Collins.

Sep 9 '08 #181

REH wrote:

On Sep 6, 1:44 pm, jacob navia <ja...@nospam.comwrote:
>TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

This is done to support read only data types, what is very hard in C++.

nonsense.

Read:
const TYPE& operator[](std::size_t i) const;

or, if you prefer by value:

TYPE operator[](std::size_t i) const;

Write:
TYPE& operator[](std::size_t i);

x = y[1]; would call the operator with the read prototype.

y[1] = x; would call the operator with the write prototype.

No you are wrong there. Ask why on c.l.c++.

--
Ian Collins.

Sep 9 '08 #182

jacob navia wrote, On 09/09/08 00:14:

Flash Gordon wrote:
>Anand Hariharan wrote, On 08/09/08 16:19:
>>On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
jacob navia wrote, On 04/09/08 00:08:
Because it is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.
I've seen a lot of bugs in code written in simpler languages.

Could you elaborate? What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

Depending on your definition of simpler, I have...

Z80 assembler. This is a nice fairly simple assembly language and I've
seen lots of bugs in code written in it. It certainly was mainstream
back when I started using it, and there are a lot of NSC800 processors
(the military equivalent with a few extra built-in peripherals) still
flying around.

Pascal. This is simpler in terms of being in general a higher level
language without OO (which Jacob considers complex, and not without
reason), and I've seen lots of bugs in Pascal.

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

I did NOT say that C has no bugs. Read what I wrote again:

Read what I said again. I said "lots".

>>jacob navia wrote, On 04/09/08 00:08:
>>>Simple languages are easier to
>>>understand and use, and have less surface for bugs.

Is that clear to you now?

"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

My experience is that bugs are just as common and just as good at hiding
in code written in every language I have used.

I consider C++ a very complex language where bugs have a lot more
places to hide.

I don't have enough experience of C++ to comment about that. However, I
do have experience of "simpler" languages than C and my experience is
that the skill level of the people and the quality of the development
process have a far larger impact than the language on the bug count and
the difficulty in finding the bugs.
--
Flash Gordon

Sep 9 '08 #183

Nick Keighley

On 9 Sep, 00:14, jacob navia <ja...@nospam.comwrote:

Flash Gordon wrote:
Anand Hariharan wrote, On 08/09/08 16:19:
On Sep 4, 6:15 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
jacob navia wrote, On 04/09/08 00:08:

>>Because [C] is a *simple* language. Simple languages are easier to
understand and use, and have less surface for bugs.

I dunno. You tend to have to write more code to do things that
a more "complex" language would express in less code.

Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C. :-)

>I've seen a lot of bugs in code written in simpler languages.

Could you elaborate? *What are the mainstream programming languages
(as in those languages with a reasonable number of programs written
using them) that you consider to be simpler than C?

Depending on your definition of simpler, I have...

Z80 assembler. This is a nice fairly simple assembly language and I've
seen lots of bugs in code written in it. It certainly was mainstream
back when I started using it, and there are a lot of NSC800 processors
(the military equivalent with a few extra built-in peripherals) still
flying around.

Pascal. This is simpler in terms of being in general a higher level
language without OO (which Jacob considers complex, and not without
reason), and I've seen lots of bugs in Pascal.

Choose a definition of simple and I am sure I can find a language I've
used which meets that definition.

I did NOT say that C has no bugs. Read what I wrote again:

he didn't say you said...

*>>jacob navia wrote, On 04/09/08 00:08:
*>>>Simple languages are easier to
*>>>understand and use, and have less surface for bugs.

Is that clear to you now?

"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

um no. Since programming languages don't have surfaces they can't
have "less surface". It's a metaphor and you don't explain a metaphor
by, basically, repeating the metaphor.

One of my pet hates is things like "he was *literally* blown away".
Well
unless he was mishandling explosives, no he wasn't.

I consider C++ a very complex language where bugs have a lot more
places to hide.

how many places can this expression generate an exception?
a = b + c;
--
Nick Keighley

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?"
-- Tom Cargil, C++ Journal.

Sep 9 '08 #184

Nick Keighley wrote:

Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C. :-)

No, because standard C includes complex numbers. This extension would
make the language *smaller* because complex numbers could
be left *out* of the language itself, making it simpler
yet more powerful.

>"Less surface" means that, less surface, not NO bugs but fewer and
easier to find.

um no. Since programming languages don't have surfaces they can't
have "less surface". It's a metaphor and you don't explain a metaphor
by, basically, repeating the metaphor.

The "surface" of a language is the number of features exposed
to the user at any given time.

When you write in a simple language you can have all the features
of the language in your mind and you can know exactly what are you
doing.

When you write in a complex language, there are so many features
available that it is impossible for you to have all of them
in your mind when writing new code. There are then features that can
provoke bugs that you can't foresee.

>
--
Nick Keighley

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?"
-- Tom Cargil, C++ Journal.

It is interesting that in your signature you quote a confirmation of
what I am arguing.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 9 '08 #185

Flash Gordon wrote:

I don't have enough experience of C++ to comment about that. However, I
do have experience of "simpler" languages than C and my experience is
that the skill level of the people and the quality of the development
process have a far larger impact than the language on the bug count and
the difficulty in finding the bugs.

The problem with complicated/complex languages is that you just
can't have all the features of the language in your mind when writing
new code.

For instance I said in this same thread that C++ can't differentiate
with the overloaded '[' ']' operator between writing and reading.

Almost immediately, one C++ expert told me that is nonsense and
proposed a solution. The solution looks quite plausible, and nobody
objected (I was just waited).

A day later another expert says that the solution proposed by the
first expert will just not work. He said (to the first expert) that
he should ask in comp.lang.c++ why it doesn't work.

When I asked the same question in the C++ experts group, it took
quite a while until one expert proposed a solution that was
accepted by the others, maybe because involved templates and
was (as always in c++) an atomic bomb to kill a fly.

The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

The specifications for name lookup when following a class
overloaded operator are pages and pages, involving a
topological sort, etc. It is impossible for a human to
follow all that. Only a machine can have the patience to
do this kind of stuff.

At that point, a language becomes segmented in the programmer's
mind. He/she will concentrate on the features he/she assumes
that have relevance to the problem at hand and ignore the
possible subtle interactions of all the others.

You have to keep in mind that when writing code there are
TWO completely different "computers" involved:

(1): A "biological" computer made of billions of processors that
is NOT designed for programming
(2) a CPU

(1) is designed after around 1 billion years of evolution for
coping with a natural environment, where computers just
do not exist. It has a short attention span and a very
limited short term memory.

"To err is human", and the possibility of introducing errors in a
program increases with the number of features you have to keep
in mind.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 9 '08 #186

Nick Keighley

On 9 Sep, 09:26, jacob navia <ja...@nospam.comwrote:

Nick Keighley wrote:

Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C. * :-)

No, because standard C includes complex numbers. This extension would
make the language *smaller* because complex numbers could
be left *out* of the language itself, making it simpler
yet more powerful.

a similar argument could be made for templates in C++
allowing the existence of the STL
<snip>

The "surface" of a language is the number of features exposed
to the user at any given time.

When you write in a simple language you can have all the features
of the language in your mind and you can know exactly what are you
doing.

When you write in a complex language, there are so many features
available that it is impossible for you to have all of them
in your mind when writing new code. There are then features that can
provoke bugs that you can't foresee.

--
Nick Keighley

"If you think C++ is not overly complicated, just what is a protected
*abstract virtual base pure virtual private destructor, and when
*was the last time you needed one?"
* * * * * * * * * *-- Tom Cargil, C++ Journal.

It is interesting that in your signature you quote a confirmation of
what I am arguing.

my sigs are not randomly generated
--
Nick Keighley

why isn't there an obfuscated C++ contest?

Sep 9 '08 #187

Richard

jacob navia <ja***@nospam.comwrites:

Flash Gordon wrote:
>I don't have enough experience of C++ to comment about
that. However, I do have experience of "simpler" languages than C
and my experience is that the skill level of the people and the
quality of the development process have a far larger impact than the
language on the bug count and the difficulty in finding the bugs.

The problem with complicated/complex languages is that you just
can't have all the features of the language in your mind when writing
new code.

For instance I said in this same thread that C++ can't differentiate
with the overloaded '[' ']' operator between writing and reading.

Almost immediately, one C++ expert told me that is nonsense and
proposed a solution. The solution looks quite plausible, and nobody
objected (I was just waited).

A day later another expert says that the solution proposed by the
first expert will just not work. He said (to the first expert) that
he should ask in comp.lang.c++ why it doesn't work.

When I asked the same question in the C++ experts group, it took
quite a while until one expert proposed a solution that was
accepted by the others, maybe because involved templates and
was (as always in c++) an atomic bomb to kill a fly.

The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

Am I allowed here to say once more - and this is why operator
overloading is nonsense and leads to horrible, unmaintainable code?

I have worked with experts and language lawyers. And all they do is
argue about the cleverest way to do things. And Introducing Operator
Overloading into C will see a huge reduction in the quality and
maintainability of the code bases. Been there done that with C++.- Yes,
I know, "if done properly" - but listen to the experts argue about best
approach and then consider "average Ted" and what he would
do. Nope. Keep them away.

Sep 9 '08 #188

REH

On Sep 9, 1:13*am, Ian Collins <ian-n...@hotmail.comwrote:

REH wrote:
On Sep 6, 1:44 pm, jacob navia <ja...@nospam.comwrote:
TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

* * * * table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

This is done to support read only data types, what is very hard in C++..

nonsense.

Read:
const TYPE& operator[](std::size_t i) const;

or, if you prefer by value:

TYPE operator[](std::size_t i) const;

Write:
TYPE& operator[](std::size_t i);

x = y[1]; would call the operator with the read prototype.

y[1] = x; would call the operator with the write prototype.

No you are wrong there. *Ask why on c.l.c++.

--
Ian Collins.

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

REH

Sep 9 '08 #189

jacob navia wrote:

>
For instance I said in this same thread that C++ can't differentiate
with the overloaded '[' ']' operator between writing and reading.

Almost immediately, one C++ expert told me that is nonsense and
proposed a solution. The solution looks quite plausible, and nobody
objected (I was just waited).

How do you define 'immediately' (almost 2 days) and how do you define
expert?

A day later another expert says that the solution proposed by the
first expert will just not work. He said (to the first expert) that
he should ask in comp.lang.c++ why it doesn't work.

Where else should the so called expert go to find the error of his ways?
Do all C programmers agree all of the time? A day or two here will
answer that.

When I asked the same question in the C++ experts group, it took
quite a while until one expert proposed a solution that was
accepted by the others, maybe because involved templates and
was (as always in c++) an atomic bomb to kill a fly.

Proxies are the idiomatic way to determine read from write. No
templates are required.

The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

Then use the ones your mind can follow, which is what most programmers
do in most languages. What I do like is a language that can solve
problems (such as determining read from write to an array) without
resorting to language extensions.

At that point, a language becomes segmented in the programmer's
mind. He/she will concentrate on the features he/she assumes
that have relevance to the problem at hand and ignore the
possible subtle interactions of all the others.

So all C programmers use all the dusty corners of the language? Most
programmers work in teams and the collective knowledge of the team helps
the individual's knowledge to grow.

--
Ian Collins.

Sep 9 '08 #190

REH

On Sep 9, 1:13*am, Ian Collins <ian-n...@hotmail.comwrote:

REH wrote:
On Sep 6, 1:44 pm, jacob navia <ja...@nospam.comwrote:
TYPE operator [ ]=(TYPE table, int idx, ELEMENT_TYPE newvalue)
This would apply to

* * * * table[idx] = newvalue;

In C++ there is no way to distinguish between those
operations since you just return a pointer.

This is done to support read only data types, what is very hard in C++..

nonsense.

Read:
const TYPE& operator[](std::size_t i) const;

or, if you prefer by value:

TYPE operator[](std::size_t i) const;

Write:
TYPE& operator[](std::size_t i);

x = y[1]; would call the operator with the read prototype.

y[1] = x; would call the operator with the write prototype.

No you are wrong there. *Ask why on c.l.c++.

--
Ian Collins.

Re-reading it, I believe you were confused/mislead by my overly
concise example. I meant to imply x = y[1]; was being used in a
context were y was constant. Obviously, if y is not constant, it would
call the "write" version for both lvalues and rvalues.

REH

Sep 9 '08 #191

REH wrote:

On Sep 9, 1:13 am, Ian Collins <ian-n...@hotmail.comwrote:
>REH wrote:

>>Read:
const TYPE& operator[](std::size_t i) const;
or, if you prefer by value:
TYPE operator[](std::size_t i) const;
Write:
TYPE& operator[](std::size_t i);
x = y[1]; would call the operator with the read prototype.
y[1] = x; would call the operator with the write prototype.
No you are wrong there. Ask why on c.l.c++.

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

No, the constness of the object determines which one gets called. Try
it then ask down the hall.

--
Ian Collins.

Sep 9 '08 #192

Bartc

"jacob navia" <ja***@nospam.comwrote in message
news:g9**********@aioe.org...

Flash Gordon wrote:
>>
Are you claiming that C should be used as a general solution to ALL
programming problems?

Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...

You apparently are of the same opinion.

By leaving application programming for other languages, you
effectively destroy C.

Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

My opinion when I first looked at C a few years ago was that this would be a
great language if you got rid of all the obsolete baggage and brought it
up-to-date. Like a 'C2004' version (as it would have been).

And, perhaps target it at more modern machines. Looking at a table of basic
types like the following (for perhaps C# or D):

char 1 byte 8 bits
short int 2 bytes 16 bits
int 4 bytes 32 bits
long int 8 bytes 64 bits

is somehow very wonderful and refreshing. Finally, you know exactly where
you are! Compare with the woolly approach used in C, which makes it
difficult to code with any confidence.

New C would be simpler and yet could be more powerful. Unfortunately people
creating successors to C don't know where to stop.

I am claiming that C can be used for general application
programming. It needs just a single modification
(operator overloading) and a rewrite of the standard library
to be able to be very useful in application programming.

When I looked at this for one of my languages once (but never implemented; I
found it easier to build any special types and their operators into the
language), I tried this approach:

* Create the code needed for the operations using ordinary functions. The
function names need to be unique, as function overloading is not used.

So far, this does not require anything special in the language, and people
who don't like overloading can use these directly.

THEN, possibly link each of these functions to a standard operator using
some syntactic device, perhaps a pragma:

#pragma registerop "*" (mat,mat) = multiplymat()

This way you can sneak in operator overloading into the language with hardly
anyone noticing.

--
Bartc

Sep 9 '08 #193

REH

On Sep 9, 7:11*am, Ian Collins <ian-n...@hotmail.comwrote:

REH wrote:
On Sep 9, 1:13 am, Ian Collins <ian-n...@hotmail.comwrote:
REH wrote:
Read:
const TYPE& operator[](std::size_t i) const;
or, if you prefer by value:
TYPE operator[](std::size_t i) const;
Write:
TYPE& operator[](std::size_t i);
x = y[1]; would call the operator with the read prototype.
y[1] = x; would call the operator with the write prototype.
No you are wrong there. *Ask why on c.l.c++.

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

No, the constness of the object determines which one gets called. *Try
it then ask down the hall.

--
Ian Collins.

Please, read my other response.

REH

Sep 9 '08 #194

s0suk3

On Sep 9, 6:53*am, "Bartc" <bc@freeuk.comwrote:

"jacob navia" <ja***@nospam.comwrote in message

news:g9**********@aioe.org...

Flash Gordon wrote:

Are you claiming that C should be used as a general solution to ALL
programming problems?

Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...

You apparently are of the same opinion.

By leaving application programming for other languages, you
effectively destroy C.

Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

My opinion when I first looked at C a few years ago was that this would be a
great language if you got rid of all the obsolete baggage and brought it
up-to-date. Like a 'C2004' version (as it would have been).

And, perhaps target it at more modern machines. Looking at a table of basic
types like the following (for perhaps C# or D):

char * * * *1 byte * *8 bits
short int * 2 bytes * 16 bits
int * * * * 4 bytes * 32 bits
long int * *8 bytes * 64 bits

is somehow very wonderful and refreshing. Finally, you know exactly where
you are! Compare with the woolly approach used in C, which makes it
difficult to code with any confidence.

char 1 byte 8 bits
int16_t 2 bytes 16 bits
int32_t 4 bytes 32 bits
int_least64_t 8 bytes 64 bits (or more)

;-)

Sebastian

Sep 9 '08 #195

Bartc

s0****@gmail.com wrote:

On Sep 9, 6:53 am, "Bartc" <bc@freeuk.comwrote:

....

>Looking at a table
of basic types like the following (for perhaps C# or D):

char 1 byte 8 bits
short int 2 bytes 16 bits
int 4 bytes 32 bits
long int 8 bytes 64 bits

is somehow very wonderful and refreshing.

char 1 byte 8 bits
int16_t 2 bytes 16 bits
int32_t 4 bytes 32 bits
int_least64_t 8 bytes 64 bits (or more)

;-)

Yeah, bolting on this stuff (plus a few dozen other variations) using a
special header in a disputed standard is just as elegant as defining it
clearly once and for all in the core language.

--
Bart

Sep 9 '08 #196

Richard Heathfield

s0****@gmail.com said:

<snip>

char 1 byte 8 bits

Counter-example: some DSPs have 16 or even 32 bits per byte.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 9 '08 #197

Nate Eldredge

Richard Heathfield <rj*@see.sig.invalidwrites:

s0****@gmail.com said:

<snip>

>char 1 byte 8 bits

Counter-example: some DSPs have 16 or even 32 bits per byte.

And, unless this was disallowed by ANSI, K&R I makes reference to the
Honeywell 9000, which apparently had 9 bits per byte (and an int was
36 bits). Granted, this probably plays into the OP's assertion that
such things are now relics and ought not to be considered anymore.

Sep 9 '08 #198

Richard Heathfield

Nate Eldredge said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>s0****@gmail.com said:

<snip>

>>char 1 byte 8 bits

Counter-example: some DSPs have 16 or even 32 bits per byte.

And, unless this was disallowed by ANSI, K&R I makes reference to the
Honeywell 9000, which apparently had 9 bits per byte (and an int was
36 bits).

It wasn't disallowed by ANSI, no.

Granted, this probably plays into the OP's assertion that
such things are now relics and ought not to be considered anymore.

<shrugSome of the embedded guys consider 8-bit bytes to be relics, too. I
don't let that stop me from writing code that'll work on systems with
8-bit bytes, though.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Sep 9 '08 #199