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?

[CBFalconer]

jacob navia wrote:

Flash Gordon wrote:

>jacob navia wrote, On 10/09/08 07:53:

>>You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined
functions.

>>is simpler to read than
q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling
and user defined functions and something about the types. If, on
the other hand, you have operator overloading you don't know
whether or not you are calling user defined functions (or which
ones) without checking the types of all of the variables and
whether the operators have been overloaded.

This is just not true. If you are working in a 16 bit machine
and you are doing a long divide in 32 bits you call a function.
If you are in a 32 bit machine and you are doing a 64 bit divide
you call a function too. I know because I wrote those functions
and they are messy :-)

You are missing the point. Imagine the the overloaded operators +,
/, and * are defined such that they all require a struct, type
foobah, for the second operand, and an integer for the first
operand. In this case + returns an integer, * returns a foobah,
and / returns a foobah. Now the types required for the statement
above are:

foobah = (int + foobah) / (int * foobah);

Don't complain about the foolish overloads. If present, someone
will so use them. Just think about the problems of trying to
untangle such code in a sizable application.

Note that making c an integer allows the + operator to work, the *
operator to work, the / operator to work, but the result is an
integer, and the assignment to a foobah doesn't work. Then
consider the problems associated with other types for the operands.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

>REH wrote:

.... snip off-topic junk ...

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

The C++ newsgroup is, surprise, named comp.lang.c++. This is
comp.lang.c, and C++ is off topic.

We had that discussion yesterday.

Are you claiming that it is on-topic today? :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[William Pursell]

On 10 Sep, 22:24, jacob navia <ja...@nospam.c omwrote:

Flash Gordon wrote:

jacob navia wrote, On 10/09/08 07:53:

You are saying that
* * q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

is simpler to read than
* * q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other
hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking the
types of all of the variables and whether the operators have been
overloaded.

This is just not true. If you are working in a 16 bit machine
and you are doing a long divide in 32 bits you call a
function. If you are in a 32 bit machine and you are doing
a 64 bit divide you call a function too. I know because I wrote
those functions and they are messy :-)

"I wrote those functions" == "The implementor wrote those functions"
!= "user defined function"

Emphasis on "!="

[s0suk3]

On Sep 10, 2:42*pm, Flash Gordon <sp**@flash-gordon.me.ukwro te:

jacob navia wrote, On 10/09/08 07:53:

>Flash Gordon wrote:

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

>You are saying that
* * q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

>is simpler to read than
* * q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other
hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking the
types of all of the variables and whether the operators have been
overloaded.

>This is why many languages use operator overloading!
It is much simpler to read and use.

It can make some things easier to write, and with sufficient discipline
it can be very useful. However, in general you don't know whether
sufficient discipline has been used. With operator overloading tell me
what the following line does...

* * count = a - b;

Bet you got it wrong, a and b are set types, - is overloaded to provide
the intersection, and = is overloaded so that if the left operand is an
integer types and the right a set type it assigns the cardinality of the
set to the left operand. So count will be the number of elements in both
a and b.

There are a couple of important factors you're overlooking:

o In real programs, you usually give more meaningful names to
variables

o In real programs, you always know the type of a variable (and if
you don't because, say, the variable is declared a few thousand lines
above the part where you're reading, then the program simply has a bad
design)

o Your above example is a real misuse of operator overloading; it's
not intuitive at all and it does more than it should do

Considering this, a more realistic example would be:

(Without operator overloading)

String fileName;
appendtostring( fileName, "a.txt");
String fileNameCopy;
copystring(file NameCopy, fileName);

(With operator overloading)

String fileName;
fileName += "a.txt";
String fileNameCopy = fileName;

The former is more explicit/verbose. The latter is more intuitive.

Even if we didn't give meaningful names to the variables, the mere
knowledge about their types would be enough:

String a;
a += "a.txt"
String b = a;

Sebastian

[Flash Gordon]

jacob navia wrote, On 10/09/08 22:24:

Flash Gordon wrote:

>jacob navia wrote, On 10/09/08 07:53:

>>You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

>>is simpler to read than
q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other

^^^^^^^^^^^^^^^ ^^^^^^^

>hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking

^^^^^^^^^^^^^^^ ^^^^^^^

>the types of all of the variables and whether the operators have been
overloaded.

This is just not true. If you are working in a 16 bit machine
and you are doing a long divide in 32 bits you call a
function.

The USER does not have to write that function, therefore it is NOT a
user defined function.

If you are in a 32 bit machine and you are doing
a 64 bit divide you call a function too.

The USER does not have to write that function, therefore it is NOT a
user defined function.

I know because I wrote
those functions and they are messy :-)

They are implementer defined functions, and you had to write them
because you are the implementer. I was quite deliberate in specifying
user defined functions because to understand what the code will do you
only need to know which are user defined functions.

Oh, and I've used compilers for processors without a divide instruction
and was doing programming back in the days where it was common to use an
8086 *without* an 8087 co-processor so all floating point was done by
functions. For integer operations though I would expect a compiler to
use inline-code rather than calling a function.
--
Flash Gordon

[Flash Gordon]

s0****@gmail.co m wrote, On 11/09/08 11:38:

On Sep 10, 2:42 pm, Flash Gordon <sp**@flash-gordon.me.ukwro te:

>jacob navia wrote, On 10/09/08 07:53:

>>Flash Gordon wrote:
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
overloadi ng 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.
You are saying that
q = divide(add(b,c) ,multiply(b,c)) ;

Here you always know that you are calling three user defined functions.

>>is simpler to read than
q = (b+c)/(b*c);

Without operator overloading here you know you are *not* calling and
user defined functions and something about the types. If, on the other
hand, you have operator overloading you don't know whether or not you
are calling user defined functions (or which ones) without checking the
types of all of the variables and whether the operators have been
overloaded.

>>This is why many languages use operator overloading!
It is much simpler to read and use.

It can make some things easier to write, and with sufficient discipline
it can be very useful. However, in general you don't know whether
sufficient discipline has been used. With operator overloading tell me
what the following line does...

count = a - b;

Bet you got it wrong, a and b are set types, - is overloaded to provide
the intersection, and = is overloaded so that if the left operand is an
integer types and the right a set type it assigns the cardinality of the
set to the left operand. So count will be the number of elements in both
a and b.

There are a couple of important factors you're overlooking:

You are missing the point that lots of us have to deal with code written
by other people who do not necessarily follow good practice.

o In real programs, you usually give more meaningful names to
variables

Yes, I do, but I've come across people who do not.

o In real programs, you always know the type of a variable (and if
you don't because, say, the variable is declared a few thousand lines
above the part where you're reading, then the program simply has a bad
design)

Sometimes I know that variable foo has the wrong value (because it is
printed) so I look at the line where it is assigned a value without
first looking at the definitions of all the variables used in that line.
It may be obvious that operator overloading is not being used, but that
obvious conclusion may be wrong due to badly named variables, so it is
something else that needs to be checked.

o Your above example is a real misuse of operator overloading; it's
not intuitive at all and it does more than it should do

Look at Pascal, that uses +, - and * for set operators, look at Perl
where using = can in some instances give you the number of elements in
something. Yes, I miss-remembered which operator is used in Pascal for
set intersection, but if I had used the operator that Pascal used then a
lot of people would have considered what I did to be perfectly
reasonable use of operator overloading. The fact that you don't just
goes to show that people *will* do what you consider to be abuse (Jacob
may or may not consider it to be abuse).

Considering this, a more realistic example would be:

<snip examples with obvious names>

Even if we didn't give meaningful names to the variables, the mere
knowledge about their types would be enough:

String a;
a += "a.txt"
String b = a;

An example where it is obvious does not disprove the existence of
examples where it is not obvious. My example was picked deliberately
using the types of things that the operators are used for in other
languages (although it should have been * rather than -, but who says
someone won't make the mistake I did?) and to thus be something that
*some* people are likely to use it for whist being surprising to others.

Note that one some projects I did in Pascal I used sets a fair bit, the
project being control software for 2nd line test equipment, something
where some people might not expect sets to be used. However, they made
solving some problems nice and easy.

if (cues_found == test_targets) ...

Does this check the number of cues is equal to the number of test
targets, or does it check that the set of cues found is the same as the
set of test targets?
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

s0****@gmail.co m wrote, On 11/09/08 11:38:

>>
There are a couple of important factors you're overlooking:

You are missing the point that lots of us have to deal with code written
by other people who do not necessarily follow good practice.

If you are going to use that argument, you may as well ban pointers as well.

Arguing against something because it might be dangerous in the context
of C is daft. Most language features that make the programmer's life
easier are open to abuse.

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

Flash Gordon wrote:

>s0****@gmail.co m wrote, On 11/09/08 11:38:

>>There are a couple of important factors you're overlooking:

You are missing the point that lots of us have to deal with code written
by other people who do not necessarily follow good practice.

If you are going to use that argument, you may as well ban pointers as well.

I should have said macros there. While maintaining other people's code
I've had more arse ache form stupid macros then I've ever had from
overloaded operators.

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote, On 11/09/08 20:38:

Ian Collins wrote:

>Flash Gordon wrote:

>>s0****@gmail.co m wrote, On 11/09/08 11:38:
There are a couple of important factors you're overlooking:
You are missing the point that lots of us have to deal with code written
by other people who do not necessarily follow good practice.

If you are going to use that argument, you may as well ban pointers as well.

I should have said macros there. While maintaining other people's code
I've had more arse ache form stupid macros then I've ever had from
overloaded operators.

If I was creating my ideal language it would not have macros, they make
the language more complex. However, that boat sailed a long time ago in
C. Anyway, I'm arguing that operator overloading is an additional
complexity and because of that it is unlikely to be added to C.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

Ian Collins wrote, On 11/09/08 20:38:

>Ian Collins wrote:

>>Flash Gordon wrote:
s0****@gmail.co m wrote, On 11/09/08 11:38:
There are a couple of important factors you're overlooking:
You are missing the point that lots of us have to deal with code
written
by other people who do not necessarily follow good practice.

If you are going to use that argument, you may as well ban pointers
as well.

I should have said macros there. While maintaining other people's code
I've had more arse ache form stupid macros then I've ever had from
overloaded operators.

If I was creating my ideal language it would not have macros, they make
the language more complex. However, that boat sailed a long time ago in
C. Anyway, I'm arguing that operator overloading is an additional
complexity and because of that it is unlikely to be added to C.

I can't argue with with it not being added to C, but having used
operator overloaded a lot in that other language, I still believe the
benefits more than outweigh any cost.

The last large project I working on had a lot of time types and
complicated periodic fixed or variable duration control processes. Most
of the time when working with times, the type of the time interval or
period was irrelevant. Having overloaded operators provided a
convenient level of abstraction enabling us to concentrate on the
problem, not the detail of the implementation.

--
Ian Collins.