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?

[REH]

On Sep 9, 1:13*am, Ian Collins <[e-mail] mwrote:

REH wrote:

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

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.

Re-reading it, I believe you were confused/mislead by my overly
concise example. I meant to imply x = y[1]; was being used in a
context were y was constant. Obviously, if y is not constant, it would
call the "write" version for both lvalues and rvalues.

REH

[Ian Collins]

REH wrote:

On Sep 9, 1:13 am, Ian Collins <[e-mail] mwrote:

>REH wrote:

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

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

No, the constness of the object determines which one gets called. Try
it then ask down the hall.

--
Ian Collins.

[Bartc]

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

Flash Gordon wrote:

>>
Are you claiming that C should be used as a general solution to ALL
programming problems?

Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...

You apparently are of the same opinion.

By leaving application programming for other languages, you
effectively destroy C.

Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

My opinion when I first looked at C a few years ago was that this would be a
great language if you got rid of all the obsolete baggage and brought it
up-to-date. Like a 'C2004' version (as it would have been).

And, perhaps target it at more modern machines. Looking at a table of basic
types like the following (for perhaps C# or D):

char 1 byte 8 bits
short int 2 bytes 16 bits
int 4 bytes 32 bits
long int 8 bytes 64 bits

is somehow very wonderful and refreshing. Finally, you know exactly where
you are! Compare with the woolly approach used in C, which makes it
difficult to code with any confidence.

New C would be simpler and yet could be more powerful. Unfortunately people
creating successors to C don't know where to stop.

I am claiming that C can be used for general application
programming. It needs just a single modification
(operator overloading) and a rewrite of the standard library
to be able to be very useful in application programming.

When I looked at this for one of my languages once (but never implemented; I
found it easier to build any special types and their operators into the
language), I tried this approach:

* Create the code needed for the operations using ordinary functions. The
function names need to be unique, as function overloading is not used.

So far, this does not require anything special in the language, and people
who don't like overloading can use these directly.

THEN, possibly link each of these functions to a standard operator using
some syntactic device, perhaps a pragma:

#pragma registerop "*" (mat,mat) = multiplymat()

This way you can sneak in operator overloading into the language with hardly
anyone noticing.

--
Bartc

[REH]

On Sep 9, 7:11*am, Ian Collins <[e-mail] mwrote:

REH wrote:

On Sep 9, 1:13 am, Ian Collins <[e-mail] mwrote:

REH wrote:
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++.

Um, no I am not. I don't need to ask. I've been writing C++ code
before it even had a standard.

No, the constness of the object determines which one gets called. *Try
it then ask down the hall.

--
Ian Collins.

Please, read my other response.

REH

[s0suk3]

On Sep 9, 6:53*am, "Bartc" <[e-mail] rote:

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

news:g9******** **@aioe.org...

Flash Gordon wrote:

Are you claiming that C should be used as a general solution to ALL
programming problems?

Obviously Gwyn thinks that C is good for "System programming", where
it is unclear why system programming needs gets() and trigraphs...

You apparently are of the same opinion.

By leaving application programming for other languages, you
effectively destroy C.

Application programming should be done in "evolved" languages
and C should be kept at the level of gets() with a library
conceived in the 70s and still bug-compatible with that
one.

My opinion when I first looked at C a few years ago was that this would be a
great language if you got rid of all the obsolete baggage and brought it
up-to-date. Like a 'C2004' version (as it would have been).

And, perhaps target it at more modern machines. Looking at a table of basic
types like the following (for perhaps C# or D):

char * * * *1 byte * *8 bits
short int * 2 bytes * 16 bits
int * * * * 4 bytes * 32 bits
long int * *8 bytes * 64 bits

is somehow very wonderful and refreshing. Finally, you know exactly where
you are! Compare with the woolly approach used in C, which makes it
difficult to code with any confidence.

char 1 byte 8 bits
int16_t 2 bytes 16 bits
int32_t 4 bytes 32 bits
int_least64_t 8 bytes 64 bits (or more)

;-)

Sebastian

[Bartc]

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

On Sep 9, 6:53 am, "Bartc" <[e-mail] rote:

....

>Looking at a table
of basic types like the following (for perhaps C# or D):

char 1 byte 8 bits
short int 2 bytes 16 bits
int 4 bytes 32 bits
long int 8 bytes 64 bits

is somehow very wonderful and refreshing.

char 1 byte 8 bits
int16_t 2 bytes 16 bits
int32_t 4 bytes 32 bits
int_least64_t 8 bytes 64 bits (or more)

;-)

Yeah, bolting on this stuff (plus a few dozen other variations) using a
special header in a disputed standard is just as elegant as defining it
clearly once and for all in the core language.

--
Bart

[Richard Heathfield]

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

<snip>

char 1 byte 8 bits

Counter-example: some DSPs have 16 or even 32 bits per byte.

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

[Nate Eldredge]

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

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

<snip>

>char 1 byte 8 bits

Counter-example: some DSPs have 16 or even 32 bits per byte.

And, unless this was disallowed by ANSI, K&R I makes reference to the
Honeywell 9000, which apparently had 9 bits per byte (and an int was
36 bits). Granted, this probably plays into the OP's assertion that
such things are now relics and ought not to be considered anymore.

[Richard Heathfield]

Nate Eldredge said:

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

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

<snip>

>>char 1 byte 8 bits

Counter-example: some DSPs have 16 or even 32 bits per byte.

And, unless this was disallowed by ANSI, K&R I makes reference to the
Honeywell 9000, which apparently had 9 bits per byte (and an int was
36 bits).

It wasn't disallowed by ANSI, no.

Granted, this probably plays into the OP's assertion that
such things are now relics and ought not to be considered anymore.

<shrugSome of the embedded guys consider 8-bit bytes to be relics, too. I
don't let that stop me from writing code that'll work on systems with
8-bit bytes, 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

[Flash Gordon]

Richard wrote, On 09/09/08 11:25:

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

<snip>

>The problem with complicated/complex languages is that you just
can't have all the features of the language in your mind when writing
new code.

<snip>

>The problem with a language like that is that the interactions
among the million features are just *beyond* what a human
mind can follow.

Am I allowed here to say once more - and this is why operator
overloading is nonsense and leads to horrible, unmaintainable code?

<snip>

Yes, you are. I agree that operator overloading makes the language (and
particularly reading the code) more complex. This is one reason why I
don't expect operator overloading to ever be added to the C standard. It
is too controversial.
--
Flash Gordon