UNIX, C, Perl

[Pilcrow]

Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C? Examples:
Network and internet access, access to UNIX interprocess controls and
communication, locale determination, EBCDIC/ASCII discrimination, etc.

Almost all of these are easy in Perl. Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these? Isn't
anyone working on this problem? or is it all being left for proprietary
systems?

[jacob navia]

Richard wrote:

Ben Bacarisse <be********@bsb .me.ukwrites:

>Richard<rg**** @gmail.comwrite s:

>>ja*********@ver izon.net writes:

Richard wrote:
ja*********@ver izon.net writes:

<snip>

>>>>>While such a suggestion is on-topic in that group, it is still not the
>right place to make your proposal.

<snip>

>>>>All may be true. But to discuss it here is easily the best thing to do
since real programmers can dissect ideas "in the real world".
But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modification , and sufficiently important that they should be approved
immediatel y. Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.
Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.

Odd, then, that your contribution to this mature debate was:

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

to which Jacob simply suggested supplying an alternative oil. Why did
you not think Jacob would be receptive to a more technical critique at
the time?

Its called a joke. We had discussed it before and I explained my
"practical" objections to operator overloading in any language. i
realise I am in a minority. I remember when I thought they were
"kewl". Then I had to maintain and extend poorly written code which
absolutely thrashed the use of them. It was horrific.

*Anything* can be misused Richard, and operator overloading is no
exception.

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

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

[Richard Heathfield]

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?

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

[Richard]

jacob navia <ja***@nospam.c omwrites:

Richard wrote:

>Ben Bacarisse <be********@bsb .me.ukwrites:

>>Richard<rg*** *@gmail.comwrit es:

ja*********@ver izon.net writes:

Richard wrote:
>ja*********@ver izon.net writes:
<snip>
>>While such a suggestion is on-topic in that group, it is still not the
>>right place to make your proposal.
<snip>
>All may be true. But to discuss it here is easily the best thing to do
>since real programmers can dissect ideas "in the real world".
But he doesn't want his ideas dissected - the only thing he's open to
is unthinking uncritical acceptance of the "fact" that his ideas are
both sufficiently good that they should be approved without
modificatio n, and sufficiently important that they should be approved
immediately . Present him with any disagreement, no matter how trivial,
and all you'll receive in response is a stream of vituperation.
Total and utter nonsense.

He rises to Heathfield's arrogant posturing now and again but more often
than not Jacob is willing to discuss.
Odd, then, that your contribution to this mature debate was:

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

to which Jacob simply suggested supplying an alternative oil. Why did
you not think Jacob would be receptive to a more technical critique at
the time?

Its called a joke. We had discussed it before and I explained my
"practical" objections to operator overloading in any language. i
realise I am in a minority. I remember when I thought they were
"kewl". Then I had to maintain and extend poorly written code which
absolutely thrashed the use of them. It was horrific.

*Anything* can be misused Richard, and operator overloading is no
exception.

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

It is. Its also easier to type

a=f(a,z) than

total=sumOfTwoC oordinates(y1,y 2); /* totally made up example but try to
get the drift .. */

I know which makes more sense and is easier to read and debug. Yes, yes,
I know c.l.c regs don't debug because Kernighan once said its easier to
do it right the first time than to have to debug it later but, well,
we're not all Richard Heathfields or Chuck Falconers.

[Richard]

Richard Heathfield <rj*@see.sig.in validwrites:

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

But little thought is put into the example here.

Yes, it is easier. Especially when below is an example of it fully
extrapolated to a function call.

But what is easier in this instance?

i=a+b;

or

struct cursorPos=moveC ursorRelative(x delta,ydelta);

Really, I have been there done that. I never found anything worse in
code than operator overloading. It *does* get mis used. You can not read
the code properly from a print out IMO. Nightmare. So, basically I am
still to be convinced.

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

And integer arithmetic and anything else that uses "+" when you are
reading the code .....

[Bartc]

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

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?

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

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

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), but what about the intermediate strings?
The whole thing is very un-C-like.

--
Bartc

[Richard]

"Bartc" <[e-mail] rites:

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

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

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

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

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), but what about the intermediate
strings? The whole thing is very un-C-like.

Exactly. And it opens up entire "paradigm shifts" which would lead to a
mess. Keep C as C.

[jacob navia]

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?

1) I am not convinced that addition is the right operator for string
concatentation since if we use it for strings:
a+b != b+a
Normally we treat addition as commutative...

2) The problem with addition of pointer with integer is that this
operation is already defined and has a well defined meaning
in C. That is why lcc-win does NOT allow you to redefine it
to give it a new meaning. The reasons are many mainly:
(a) Existing code becomes ambiguous.
(b) It is impossible to address a character beyond the
start of a string...

Look Mr Heathfield, you know this by heart, and it is really not very
helpful to just play games and pose "clever" questions...

It would be *much* more helpful if you would help with the *real*
problems with this stuff...

(1) How do you overload the '[' ']' operators with multidimensiona l
arrays? This is not possible with C++. I think that a syntax like
(1) TYPE operator [][](TYPE table,int line,int column)
{ ... }
(2) TYPE operator [2](TYPE table,int line, column)
{ ... }

Or just the same notation as for the normal operator { ] with
more indices:
(3) TYPE operator [](TYPE table, int plane, int line, int column)

(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment

but I am not sure of this.

There are several open issues like those.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard]

jacob navia <ja***@nospam.c omwrites:

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?

1) I am not convinced that addition is the right operator for string
concatentation since if we use it for strings:
a+b != b+a
Normally we treat addition as commutative...

2) The problem with addition of pointer with integer is that this
operation is already defined and has a well defined meaning
in C. That is why lcc-win does NOT allow you to redefine it
to give it a new meaning. The reasons are many mainly:
(a) Existing code becomes ambiguous.
(b) It is impossible to address a character beyond the
start of a string...

Look Mr Heathfield, you know this by heart, and it is really not very
helpful to just play games and pose "clever" questions...

Its what he does. And he likes to seed Google with names (although
wrong) too I see!

>
It would be *much* more helpful if you would help with the *real*
problems with this stuff...

No chance. He is playing "friend" to appear to the casual observer that
he doesn't in fact hate your guts. And it is quite clear to anyone who
reads this newsgroup that he does indeed hate your guts. Very
un-christian like but most god botherers I have known have had similar
tendencies.

[Richard Heathfield]

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.

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.

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.

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.

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

[jacob navia]

Malcolm McLean wrote:

>
"jacob navia" <ja***@nospam.c omwrote in message

>(2)
How to overload the ++ operator to distinguish from pre-increment
and post increment?
I would propose
TYPE ++operator(TYPE s) // for pre-increment
TYPE operator++(TYPE s) // for post-increment

What a nightmare.

++obj will do something subtly different to obj++.

Can you explain a bit?

Because with
int a = 23;

++a does something subtly different than a++.

I'd keep the C rules
of precedence and binding, and define that the operations are always
identical otherwise.

I do not see how precedence rules are changed sorry. Maybe can you explain?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32