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]

Andrew Poelstra wrote:

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

>Richard Heathfield wrote:

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

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+(Strin g 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 "StringToke n". 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+(Strin g 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+(Strin g,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

[Keith Thompson]

Andrew Poelstra <ap*******@supe rnova.homewrite s:
[...]

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_Keit h) 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"

[Keith Thompson]

Ian Collins <ia******@hotma il.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_Keit h) 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"

[Ian Collins]

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.

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotma il.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.

[CBFalconer]

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.

[Keith Thompson]

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

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_Keit h) 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"

[Richard]

Ian Collins <ia******@hotma il.comwrites:

Keith Thompson wrote:

>Ian Collins <ia******@hotma il.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 "oneupsmans hip" 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 ....

[CBFalconer]

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.

[CBFalconer]

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.