UNIX, C, Perl - Page 4

#**151** September 6th, 2008, 09:35 PM

On 2008-09-06, Richard Heathfield <rjh@see.sig.invalidwrote:

Quote:

jacob navia said:
>
><snip>
>

Quote:

>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?
>

Well, C strings are objects of type pointer-to-char, so if the user
wants to use the + operator for something different than that defined
for ptr-to-char, he would have to define his own type anyway.

And presumably, that type would not be a pointer unto itself.

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

#**152** September 6th, 2008, 10:05 PM

jacob navia wrote:

Quote:

>
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++.

Quote:

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

Far from it, it is simple.

--
Ian Collins.

#**153** September 6th, 2008, 10:05 PM

Richard Heathfield wrote:

Quote:

jacob navia said:
>
<snip>
>

Quote:

>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.

#**154** September 6th, 2008, 10:35 PM

Richard Heathfield wrote:

Quote:

s0suk3@gmail.com said:
>

Quote:

>On Sep 6, 12:15 pm, Richard Heathfield <rjh@see.sig.invalidwrote:
><snip>

Quote:

>>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.

Quote:

>>>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

#**155** September 6th, 2008, 10:45 PM

"Richard Heathfield" <rjh@see.sig.invalidwrote in message
news:ToqdnUGWbKgOJF_VRVnyvwA@bt.com...

Quote:

Bartc said:

Quote:

>Richard Heathfield wrote:

<snip>

Quote:

>>>
>>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.

Quote:

>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.

Quote:

>

Quote:

>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.

Quote:

>

Quote:

>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

#**156** September 6th, 2008, 10:45 PM

Ian Collins wrote:

Quote:

jacob navia wrote:

Quote:

>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++.
>

Quote:

>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

#**157** September 6th, 2008, 10:45 PM

Ian Collins wrote:

Quote:

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

#**158** September 6th, 2008, 10:55 PM

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

Quote:

Richard Heathfield wrote:

Quote:

>s0suk3@gmail.com said:
>>

Quote:

>>On Sep 6, 12:15 pm, Richard Heathfield <rjh@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 apoelstra@wpsoftware.com
To email me, use the above email addresss with .com set to .net

#**159** September 6th, 2008, 11:05 PM

jacob navia wrote:

Quote:

Richard Heathfield wrote:

Quote:

>>
>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.

#**160** September 6th, 2008, 11:05 PM

"jacob navia" <jacob@nospam.comwrote in message
news:g9uspb$1qc$1@aioe.org...

Quote:

Richard Heathfield wrote:

Quote:

>s0suk3@gmail.com said:
>>

Quote:

>>On Sep 6, 12:15 pm, Richard Heathfield <rjh@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.
>>

Quote:

typedef struct tagString {

Quote:

typedef struct tagStringToken {
int len; // number of strings
char *strArray[];
}
>
StringToken operator+(String a,String b)

Quote:

StringToken operator+(String a, StringToken b)

Quote:

StringToken operator=(String &a, StringToken b)

Quote:

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

#**161** September 7th, 2008, 12:05 AM

Andrew Poelstra wrote:

Quote:

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

Quote:

>Richard Heathfield wrote:

Quote:

>>s0suk3@gmail.com said:
>>>
>>>On Sep 6, 12:15 pm, Richard Heathfield <rjh@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.

Quote:

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.

Quote:

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

#**162** September 7th, 2008, 12:25 AM

Andrew Poelstra <apoelstra@supernova.homewrites:
[...]

Quote:

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) kst-u@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"

#**163** September 7th, 2008, 12:25 AM

Ian Collins <ian-news@hotmail.comwrites:
[...]

Quote:

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) kst-u@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"

#**164** September 7th, 2008, 12:35 AM

jacob navia wrote:

Quote:

Ian Collins wrote:

Quote:

>jacob navia wrote:

Quote:

>>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++.
>>

Quote:

>>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.

#**165** September 7th, 2008, 12:35 AM

Keith Thompson wrote:

Quote:

Ian Collins <ian-news@hotmail.comwrites:
[...]

Quote:

>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.

#**166** September 7th, 2008, 12:35 AM

jacob navia wrote:

Quote:

Richard wrote:
>

Quote:

>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.

#**167** September 7th, 2008, 12:35 AM

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

Quote:

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) kst-u@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"

#**168** September 7th, 2008, 12:45 AM

Ian Collins <ian-news@hotmail.comwrites:

Quote:

Keith Thompson wrote:

Quote:

>Ian Collins <ian-news@hotmail.comwrites:
>[...]

Quote:

>>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 ....

#**169** September 7th, 2008, 12:55 AM

Malcolm McLean wrote:

Quote:

"Nick Keighley" <nick_keighley_nospam@hotmail.comwrote:
>

Quote:

>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.

#**170** September 7th, 2008, 01:05 AM

jacob navia wrote:

Quote:

>

.... snip ...

Quote:

>
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.

#**171** September 8th, 2008, 11:25 AM

CBFalconer <cbfalconer@yahoo.comwrote:

Quote:

jacob navia wrote:

Quote:

Richard wrote:

Quote:

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

#**172** September 8th, 2008, 04:25 PM

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

Quote:

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

Quote:

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

#**173** September 8th, 2008, 06:15 PM

"jacob navia" <jacob@nospam.comha scritto nel messaggio
news:g9uamt$o5a$1@aioe.org...

Quote:

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

#**174** September 8th, 2008, 08:05 PM

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

Quote:

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.

#**175** September 8th, 2008, 08:05 PM

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

Quote:

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

Quote:

>jacob navia wrote, On 04/09/08 00:08:

Quote:

>>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

#**176** September 8th, 2008, 08:35 PM

Flash Gordon wrote:
....

Quote:

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"

:-)

#**177** September 8th, 2008, 11:05 PM

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

Quote:

Flash Gordon wrote:
...

Quote:

>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

#**178** September 9th, 2008, 12:15 AM

Flash Gordon wrote:

Quote:

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

Quote:

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

Quote:

>>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:

Quote:

>>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

#**179** September 9th, 2008, 12:45 AM

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

Quote:

Flash Gordon wrote:

Quote:

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

Quote:

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.

>

Quote:

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?

>

Quote:

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

>

Quote:

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.

>

Quote:

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.

>

Quote:

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

#**180** September 9th, 2008, 05:55 AM

Anand Hariharan wrote:

Quote:

>

.... snip ...

Quote:

>
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.

#**181** September 9th, 2008, 06:15 AM

jacob navia wrote:

Quote:

>
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.

#**182** September 9th, 2008, 06:15 AM

REH wrote:

Quote:

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

Quote:

>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.

#**183** September 9th, 2008, 09:05 AM

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

Quote:

Flash Gordon wrote:

Quote:

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

Quote: