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?

[Flash Gordon]

jacob navia wrote, On 09/09/08 09:50:

Flash Gordon wrote:

>I don't have enough experience of C++ to comment about that. However,
I do have experience of "simpler" languages than C and my experience
is that the skill level of the people and the quality of the
development process have a far larger impact than the language on the
bug count and the difficulty in finding the bugs.

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.

You don't need to. One of the questions I was asked in my interview for
my current job was why one should not use strtok (or something of the
sort). My honest answer (which I gave) was that I did not know because I
had never used it. What I did not say was that the reason I had never
used it was that I had never done any token parsing in C so I had no
reason to have looked at it. There was a lot more of the C language
(specifically the library) that I did not bare in mind because it was
completely irrelevant to what I was doing, and ignoring it did no harm.

<snip>

"To err is human", and the possibility of introducing errors in a
program increases with the number of features you have to keep
in mind.

There are more languages than just C and C++. I have also programmed in
Coral 66, Fortran 77, Basic, various assemblers some simper than C some
more complex, Forth (just a bit of playing), Logo (just a bit of
playing), ML (just a bit of learning), Lisp (just a little playing),
Pascal, Delphi, Perl, Java, a scripting language developed by someone I
know, a peculiar interfacing language designed and implemented by me
(which I am still learning the subtleties of), xslt, php (just a little
debugging and dabbling) and probably a few more I can't think of
currently. Often I'm dealing with multiple languages at the same time
and the interactions between them. I have also had to deal with code
written by fresh graduates with no experience, graduates with some
experience, and all the way up to people who have been programming
professionally since the early days of being able to get a job
programming. I've dealt with code written by good programmers and bad.
In my experience the programmer and process have a much greater impact
on the number of errors and how hard they are to find than the language.
Oh, and the hardest to debug has been some of the C code.
--
Flash Gordon

[CBFalconer]

Nick Keighley wrote:

jacob navia <[e-mail]:

.... snip ...

>

>I consider C++ a very complex language where bugs have a lot more
places to hide.

how many places can this expression generate an exception?
a = b + c;

Many, especially if operator overloading is present. As an
anti-example, consider the Pascal use of DIV for integers and '/'
for reals.

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

[CBFalconer]

REH wrote:

Ian Collins <[e-mail]:

>REH wrote:

>>jacob navia <[e-mail]:

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

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

[Ian Collins]

jacob navia wrote:

Nick Keighley wrote:

>Consider a C with operator over-loading. This is more both more
expressive and more complex than standard C. :-)

No, because standard C includes complex numbers. This extension would
make the language *smaller* because complex numbers could
be left *out* of the language itself, making it simpler
yet more powerful.

Which is how C++ does them, now there's an interesting contradiction!

--
Ian Collins.

[Ian Collins]

CBFalconer wrote:

REH wrote:

>Ian Collins <[e-mail]:

>>REH wrote:
jacob navia <[e-mail]:

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

--
Ian Collins.

[jacob navia]

Flash Gordon wrote:

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

>jacob navia <ja***@nospam.comwrites:

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

You are saying that
q = divide(add(b,c),multiply(b,c));
is simpler to read than
q = (b+c)/(b*c);

This is why many languages use operator overloading!
It is much simpler to read and use.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Bartc]

"jacob navia" <ja***@nospam.comwrote in message
news:ga**********@aioe.org...

Flash Gordon wrote:

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

>>jacob navia <ja***@nospam.comwrites:

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

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

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

Where b,c,q are clearly numeric types, then q=(b+c)/(b*c) is more intuitive.

The point is that operator overloads could be applied to /any/ user-types,
where b+c is not intuitive at all.

Neither would add(b,c) be, but now you can go and look at function add().
And in this case, if you are not using function overloading, you woudn't
call it add(), but something more apt. Then the function form could be
clearer to read even without looking at the source.

Anyway where an add() function returns objects using heap storage, this
requires extra effort and skill by whoever is writing the overload functions
to take care of memory. So being able to write a=b+c syntactically is only
half the work.

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

No, the end-result is much simpler to read and use, when appropriate. It's
the /mechanisms/ for making it possible that make the language complex.

--
Bartc

[Flash Gordon]

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

Flash Gordon wrote:

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

>>jacob navia <ja***@nospam.comwrites:

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

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.

Now, is the following easier to read?

count = card(intersect(a,b));
--
Flash Gordon

[Keith Thompson]

Flash Gordon <sp**@flash-gordon.me.ukwrites:

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.

Which means that operator overloading should (ideally) be used only
when not knowing whether you're calling user-defined functions doesn't
make it more difficult to understand the code.

If you happen to know that q, b, and c are of some type(s) other than
those for which those operators are built-in, then you know that at
least "+", "/", and "*" are overloaded operators (i.e., user-defined
functions). And if you don't know that, then you're probably not
going to understand the code anyway.

In real code, you'd use better names that q, b, and c (they're ok for
a short example like this, but not for real code). Even without
operator overloading, I have very little idea what
q = (b+c)/(b*c);
is supposed to do.

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

Agreed. I've used operator overloading myself, and I don't recall
running into serious problems with it; perhaps I've been lucky.

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.

Overloading "-" to denote set intersection is a bad idea; it's like
writing an ordinary function to compute a set intersection and calling
it "difference". I think "*" is sometimes used -- and that's ok if
your intended audience understands that "*" means set intersection.

Now, is the following easier to read?

count = card(intersect(a,b));

Maybe.

--
Keith Thompson (The_Other_Keith) 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"

[jacob navia]

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 :-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[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 <[e-mail]:

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

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

>Flash Gordon wrote:

>>Richard wrote, On 09/09/08 11:25:
jacob navia <ja***@nospam.comwrites:

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

>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(fileNameCopy, 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.com wrote, On 11/09/08 11:38:

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

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

>>Flash Gordon wrote:
Richard wrote, On 09/09/08 11:25:
jacob navia <ja***@nospam.comwrites:
<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.
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.com 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.com 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.com 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.com 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.

[Nick Keighley]

On 10 Sep, 20:42, Flash Gordon <[e-mail]:

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

<snip>

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,

and in well written code the definitions of a and b
wouldn't be far away. Hence I'd glance to the top of page
and find

SetType a;
SetType b;

which would warn me (even if I didn't know what SetType
meant) that there was something unusual going on with '-'
(at least).

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

Now, is the following easier to read?

* * count = card(intersect(a,b));

- for set intersection is common mathematical notation

--
Nick Keighley

In a sense, there is no such thing as a random number;
for example, is 2 a random number?
(D.E.Knuth)

[Nick Keighley]

On 12 Sep, 09:06, Nick Keighley <[e-mail]>
wrote:

On 10 Sep, 20:42, Flash Gordon <[e-mail]:

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

<snip>

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,

and in well written code the definitions of a and b
wouldn't be far away. Hence I'd glance to the top of page
and find

SetType a;
SetType b;

which would warn me (even if I didn't know what SetType
meant) that there was something unusual going on with '-'
(at least).

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

Now, is the following easier to read?

* * count = card(intersect(a,b));

- for set intersection is common mathematical notation

this is, of course, bollocks. - is sensible mathematical set
notation, but not intersection. A while since I played with
sets

--
Nick Keighley

[Flash Gordon]

Nick Keighley wrote, On 12/09/08 09:12:

On 12 Sep, 09:06, Nick Keighley <[e-mail]>
wrote:

>On 10 Sep, 20:42, Flash Gordon <[e-mail]:

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

<snip>

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

and in well written code the definitions of a and b
wouldn't be far away. Hence I'd glance to the top of page
and find

SetType a;
SetType b;

which would warn me (even if I didn't know what SetType
meant) that there was something unusual going on with '-'
(at least).

With well written code I agree. The problem is I also have to deal with
badly written code.

>>- 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.
Now, is the following easier to read?
count = card(intersect(a,b));

- for set intersection is common mathematical notation

this is, of course, bollocks. - is sensible mathematical set
notation, but not intersection. A while since I played with
sets

I'm sure someone will make that mistake when using operator overloading
to implement sets, just as both of us have now done ;-)

Many moons ago I did a lot of work using sets in Pascal, I just
miss-remembered it. With that Pascal code using * for intersection etc
was not a problem because the code was well written, after all I wrote
it ;-)

Operator overloading can be used to very good effect. However, for those
of us having to deal with code written by people we have no control over
and who abuse language features it would make reading the code more
complex because of the need to check.
--
Flash Gordon

[Flash Gordon]

Ian Collins wrote, On 12/09/08 03:32:

Flash Gordon wrote:

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

>>Ian Collins wrote:
Flash Gordon wrote:
s0****@gmail.com 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.

I agree that it can be used well. Where I used to work we could impose
appropriate disciplines to remove the abuses, and if I remember your
posting history correctly I suspect the same applies to where you work.

However, with one developer I know I can just imagine the mess he could
create since I know the mess he can create just with C as it is.

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.

Agreed.

You accept there is a cost, I accept there is a value.
--
Flash Gordon