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?

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

<snip>

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

It wasn't a clever question. It was in fact a dumb question (but an honest
one), and it had an obvious answer, and having spent a few minutes
thinking about it I've answered it myself elsethread, in what I hope is a
positive way.

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?

I wouldn't. I would allow any user-defined type to overload the array
operator, but I would stop there.

<snip>

(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

Those look fine to me.

>
but I am not sure of this.

Why not? What is your concern?

There are several open issues like those.

So bring them on.

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

[Malcolm McLean]

"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++. I'd keep the C rules of
precedence and binding, and define that the operations are always identical
otherwise.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

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

So what? It already does.

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

[s0suk3]

On Sep 6, 12:15*pm, Richard Heathfield <rj*@see.sig.in validwrote:
<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 "constructo r" and
"destructor ". C is no exception.

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

Sebastian

[Richard]

s0****@gmail.co m writes:

On Sep 6, 12:15Â*pm, Richard Heathfield <rj*@see.sig.in validwrote:
<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 "constructo r" and
"destructor ". C is no exception.

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

Sebastian

RH knew exactly which way the conversation would turn. It is foolish to
pretend the addition of overloaded operators in C will not turn C into a
"poor mans" C++.

[Richard Heathfield]

s0****@gmail.co m said:

On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.in validwrote:
<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 "constructo r" 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.

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

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

Richard Heathfield wrote:

>(1) How do you overload the '[' ']' operators with multidimensiona l
arrays?

I wouldn't. I would allow any user-defined type to overload the array
operator, but I would stop there.

But why? I do not see any reason (besides C++ compatibility) to avoid
overloading n dimensional arrays.

<snip>

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

Those look fine to me.

OK

>

> but I am not sure of this.

Why not? What is your concern?

>There are several open issues like those.

So bring them on.

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.

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

I will bring other issues later.

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

[Richard]

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

s0****@gmail.co m said:

>On Sep 6, 12:15 pm, Richard Heathfield <rj*@see.sig.in validwrote:
<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 "constructo r" 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.

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

That last paragraph is complete and utter rubbish and I have no idea why
someone with your technical knowledge and skills would say such a
thing. Note that "modern" does not, in any way, indicate "improved" as
far as the end product goes but there is a LOT of modern OO thinking
that has gone into C++.

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>>(1) How do you overload the '[' ']' operators with multidimensiona l
arrays?

I wouldn't. I would allow any user-defined type to overload the array
operator, but I would stop there.

But why? I do not see any reason (besides C++ compatibility) to avoid
overloading n dimensional arrays.

If you really want to do it, I suppose one way would be to allow type
synonyms to have their operators overloaded too. So, for example, here is
a not-very-well-thought-out idea in a language only barely resembling C:

struct foo
{
int i;
int j;
};

int foo::operator[](int offset) { return offset==0 ? i : j; }

/* yes, I stole the s.r.o. from C++ - sorry about that, but it conveys the
idea better than any other way I could think of */

typedef struct foo bar[]; /* bar is a synonym for an array of foo
with an arbitrary number of members */

int bar::operator[](int offset) { whatever...

the idea being that any given type can only overload one level of array
operator, but you add the ability to "build up" array types, dimension by
dimension, using typedef, and you give these array types the ability to
overload /their/ array operator. That would give you as many dimensions as
you need.

The more I think about this, the more I think it belongs in
comp.programmin g, not comp.lang.c. Still, at least it /is/ a discussion
now, which is a good start.

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

[Andrew Poelstra]

On 2008-09-06, Malcolm McLean <re*******@btin ternet.comwrote :

>
"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++. I'd keep the C rules of
precedence and binding, and define that the operations are always identical
otherwise.

ITYM, only one ++ behavior should be defined, and when it is invoked as
++obj, the value returned will be that /after/ said behavior, and when
invoked as obj++, the original object should be returned.

I'm not sure 'precedence' and 'binding' are the correct terms for that.

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