UNIX, C, Perl

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?

re: UNIX, C, Perl

jacob navia wrote, On 09/09/08 09:50: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>
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

re: UNIX, C, Perl

Nick Keighley wrote:.... snip ...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.

re: UNIX, C, Perl

REH wrote:.... snip off-topic junk ...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.

re: UNIX, C, Perl

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

--
Ian Collins.

re: UNIX, C, Perl

CBFalconer wrote:We had that discussion yesterday.

--
Ian Collins.

re: UNIX, C, Perl

Flash Gordon wrote: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

re: UNIX, C, Perl

"jacob navia" <jacob@nospam.comwrote in message
news:ga7qtg$lpp$1@aioe.org...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.
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

re: UNIX, C, Perl

jacob navia wrote, On 10/09/08 07:53:Here you always know that you are calling three user defined functions.
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.
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

re: UNIX, C, Perl

Flash Gordon <spam@flash-gordon.me.ukwrites:[...]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.
Agreed. I've used operator overloading myself, and I don't recall
running into serious problems with it; perhaps I've been lucky.
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.
Maybe.

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

re: UNIX, C, Perl

Flash Gordon wrote: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

re: UNIX, C, Perl

jacob navia wrote: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.

re: UNIX, C, Perl

Ian Collins wrote: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.

re: UNIX, C, Perl

On 10 Sep, 22:24, jacob navia <ja...@nospam.comwrote:"I wrote those functions" == "The implementor wrote those functions"
!= "user defined function"

Emphasis on "!="

re: UNIX, C, Perl

On Sep 10, 2:42*pm, Flash Gordon <spam@flash-gordon.me.ukwrote: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

re: UNIX, C, Perl

jacob navia wrote, On 10/09/08 22:24:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^The USER does not have to write that function, therefore it is NOT a
user defined function.
The USER does not have to write that function, therefore it is NOT a
user defined function.

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

re: UNIX, C, Perl

s0suk3@gmail.com wrote, On 11/09/08 11:38: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.
Yes, I do, but I've come across people who do not.
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.
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).
<snip examples with obvious names>
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

re: UNIX, C, Perl

Flash Gordon wrote: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.

re: UNIX, C, Perl

Ian Collins wrote: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.

re: UNIX, C, Perl

Ian Collins wrote, On 11/09/08 20:38: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

re: UNIX, C, Perl

Flash Gordon wrote: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.

re: UNIX, C, Perl

On 10 Sep, 20:42, Flash Gordon <s...@flash-gordon.me.ukwrote:<snip>
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).

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

re: UNIX, C, Perl

On 12 Sep, 09:06, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:this is, of course, bollocks. - is sensible mathematical set
notation, but not intersection. A while since I played with
sets

--
Nick Keighley

re: UNIX, C, Perl

Nick Keighley wrote, On 12/09/08 09:12:With well written code I agree. The problem is I also have to deal with
badly written code.
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

re: UNIX, C, Perl

Ian Collins wrote, On 12/09/08 03:32: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.
Agreed.

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