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?

[Andrew Poelstra]

On 2008-09-06, Richard Heathfield <rj*@see.sig.in validwrote:

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?

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 ap*******@wpsof tware.com
To email me, use the above email addresss with .com set to .net

[Ian Collins]

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.

[Ian Collins]

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.

[jacob navia]

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)
{
// 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+(Strin g 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=(Strin g &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

[Bartc]

"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:To******** *************@b t.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(addst ring(addstring( b,c),d),e);

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

a = addstring(temp2 =addstring(temp 1=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

[jacob navia]

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

[jacob navia]

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

[Andrew Poelstra]

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

OtherString operator+(Strin g 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*******@wpsof tware.com
To email me, use the above email addresss with .com set to .net

[Ian Collins]

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.

[Bartc]

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

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.

typedef struct tagString {

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

StringToken operator+(Strin g a,String b)

StringToken operator+(Strin g a, StringToken b)

StringToken operator=(Strin g &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