Linux-Development-Sys Digest #895, Volume #6 Sun, 27 Jun 99 04:13:49 EDT
Contents:
Re: Why not C++ (Bruce Hoult)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Why not C++ (Bruce Hoult)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Why not C++ (Bruce Hoult)
Re: Why not C++ (Linus Torvalds)
Re: Why not C++ (Bruce Hoult)
Re: tcp port no.s vs. processes (Justin Vallon)
Re: using C++ for linux device drivers (Justin Vallon)
Re: NT kernel guy playing with Linux (Peter Samuelson)
Re: Run in background (Peter Samuelson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 16:15:49 +1200
In article <7l33sf$c0f$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Nathan Myers) wrote:
> Bruce Hoult <[EMAIL PROTECTED]> wrote:
> > "Thomas Steffen" <[EMAIL PROTECTED]> wrote:
> >> apart from that, C++ might not be a very elegant language, but it is
> >> fast. at least compared to other OO languages. and still has about
> >> every feature you can expect.
> >
> >You might want to check out Dylan. It's much simpler and easier to learn
> >than C++, and yet is more powerful than C++ ...
> > Plus Dylan is designed to be as fast as C++. ...
> > Dylan is much better than C++ and Java.
>
> Nonsense. If you think Dylan is as fast as C++, you really
> don't know C++ at all, and should know better than to compare
> the languages so glibly. Anyway, this is not a languages list.
Sorry, but you're wrong. I've been using C++ professionally since 1989,
and love it. Employers and co-workers generally consider me to have well
above average knowledge of C++. I know the features of C++. I know how
they are implemented under the covers. I know the limitations. I know
what is fast and what is slow.
Dylan is better.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 26 Jun 1999 23:06:50 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Terry Murphy <[EMAIL PROTECTED]>]
> It sure sounds like "troll" referred to Mr. Nuri as he, after all, is
> the one starting an open source project and he is the one that posted
> the document to Usenet which some regarded as a troll.
Objection. He is not "starting an open source project", he is dreaming
and philosophizing about an open source project (actually I can't
recall offhand whether it was supposed to be open source). I guess the
point of contention is whether dreaming and philosophizing have
anything to do with actually advancing the state of the art.
In the open source world, you will typically never get very far on a
new project unless you do a significant amount of the initial coding.
Deciding that someone else should appear out of the woodwork, as it
were, to implement your great ideas, doesn't usually work. And many of
us consider it rather arrogant to *expect* this to work. Mr. Nuri has
so far shown *zero* inclination to do any of his magnum opus himself,
except the dreaming and philosophizing part. If Nuri's model is what
professional software houses use, God help professional software
houses. (I haven't worked in that field yet.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 16:20:15 +1200
In article <7l3950$5jg$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Nathan Myers) wrote:
> Thomas Steffen <[EMAIL PROTECTED]> wrote:
> > C++ might not be a very elegant language, but it is
> >fast, at least compared to other OO languages.
>
> Its syntax isn't very elegant, but where did that come from?
> It's fast compared to _any_ language, period. People who say
> it's slower than (e.g.) C are just spreading FUD.
Now this I agree with.
If you have a reason to use the advanced feaures of C++ (e.g. virtual
functions) then you'd need to do something similar manually in C and your
resulting C code will be either the same speed as the C++, or will
sometimes even be slower because you can't efficiently express some things
in C that the C++ compiler can express in assembler.
Exactly the same applies to a C++/Dylan comparison.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 26 Jun 1999 23:19:15 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[void <[EMAIL PROTECTED]>]
> > They seem to like NT well enough.
[The Ghost In The Machine <[EMAIL PROTECTED]>]
> This appears to be a result of their being pointy-haired... :-)
Hmmmm, cause or effect? Or maybe both traits are caused by an as yet
unidentified factor....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 16:30:00 +1200
In article <[EMAIL PROTECTED]>, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
>
> > Thomas Steffen <[EMAIL PROTECTED]> wrote:
> > > C++ might not be a very elegant language, but it is
> > >fast, at least compared to other OO languages.
> >
> > Its syntax isn't very elegant, but where did that come from?
> > It's fast compared to _any_ language, period. People who say
> > it's slower than (e.g.) C are just spreading FUD.
>
> C++ *is* slower than C. not by orders of magnitude or even a factor
> of two, but if you feed code to both C and C++ compilers, the C
> compiler will optimize harder and generally make a better product.
> this is because C is more mature and that C++ code is potentially more
> complex which causes a more conservative compile.
I'd love to see an example of this.
Given...
1) code that is both valid C and valid C++, and
2) a C++ compiler that compiles to C (e.g. AT&T CFront)
... you will end up with identical machine code, no matter whether you
compile with the C compiler, or compile with the C++ compiler (using the
same C compiler as the back end).
You may be able to find some particular C++ compiler that produces worse
code compiling a C program than some particular C compiler, but that is a
function of the compiler, not the language.
> on the other hand, common-lisps like CMUCL can acheive near C or
> fortran execution speed. speed is not exclusively the domain of the
> C-like languages.
I agree. The biggest problem with this is that Common Lisp is limited by
things such as the lack of type (and other) declarations which would
otherwise allow the compiler to generate even better code in many
situations. Dylan is much like Lisp, but has (optional) declarations of
all sorts of things to aid program correctness and compiler optomisation.
CMU Dylan (aka Gwydion Dylan, aka d2c) does the same sort of optomisations
as CMUCL, and more.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Linus Torvalds)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 05:34:19 GMT
In article <[EMAIL PROTECTED]>,
Bruce Hoult <[EMAIL PROTECTED]> wrote:
>
>You may be able to find some particular C++ compiler that produces worse
>code compiling a C program than some particular C compiler, but that is a
>function of the compiler, not the language.
In theory, you're right.
In practice, C++ is a much more complex language. As such, C++
compilers are much more complex beasts. And that is why some C++
compilers do not generate as good code as the equivalent C compilers do.
In effect, what you're saying is "there is no theoretical reason why C++
would be any slower than C". And you're right.
But what others are saying is "a lot of existing C++ compilers generate
worse code than a lot of existing C compilers". And they are right too.
Sometimes theory matters. Sometimes it doesn't. The world is not as
simple as you make it out to be.
Linus
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 16:10:30 +1200
In article <7l3en8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Don Waugaman) wrote:
> Could you describe what you don't like about C++ templates, and how a
> statically-checked language that intends to minimize runtime cost could
> do better?
Well, here's what *I* don't like about C++'s templates...
Actually, C++ templates are just fine -- they're probably one of the best
parts of the language.
The *problem* is that C++ templates are an ad-hoc solution to just one
problem, and C++ has too *many* ad-hoc solutions. When you write a
function in C++ you've got to choose between template functions, inline
functions, overloaded functions, virtual functions ... it's a mess. (Yes,
I know those choices aren't orthogonal, and can be combined -- that just
makes it worse.)
Bjarne Stroustrup started with the simple "one name = one function"
principle in C and added on on virtual functions with runtime dispatch on
the first argument so that he could emulate Simula.
Then he thought "wouldn't it be nice if you could write new versions of
'+' and '<' and use the same name for several similar functions of your
own?". So he created overloaded functions, which are a completly
different and incompatable thing from virtual functions.
To try to close the gap between overloaded functions and virtual functions
a bit, he eventually added template functions, which basically let you
write a number of overloaded functions more economically.
It's a big untidy mess. And sometimes you actually can't do what you want
to do.
Don't get me wrong -- I greatly admire Bjarne Stroustrup and think he did
a great job, and C++ was a big improvement on the state-of-the-art in 1980
when he started to implement it (or 1990, when it started to spread
widely). But I think it's time to move on now.
> how a statically-checked language that intends to minimize runtime cost
> could do better?
Ok, let's look at what happens in Dylan.
Dylan has only *one* kind of function -- the generic method -- but
depending on the circumstances, the compiler will do any of:
- compile time selection of the right function
- inlining of the right function
- outlining of the right function (using it as a template)
- run time selection of the right function
Let's look at an example:
define inline method myAdd(a, b)
a + b;
end myAdd;
define method f(x, y)
myAdd(x, y);
end f;
define method g(x :: <integer>, y :: <integer>) => (z :: <integer>)
myAdd(x, y);
end g;
define method h(x :: <single-float>, y :: <single-float>)
=> (z :: <single-float>)
myAdd(x, y);
end h;
Look at "myAdd". Unlike g and h, it doesn't declare the paramter types,
or the return value type(s). What sort of function is it? You could
think of it either as a C++ template function with a and b declared to be
of some unspecified type...
template<class T> T myAdd(T a, T b){
return a + b;
}
... but it's bit more than that. C++ templates require that the actual
types of a and b be known at compile time. This C++ template requires
that a and b be of the *same* type, which is also the type of the result.
But with the Dylan function the arguments could be of different types,
more like this:
template<class T1, class T2> ???? myAdd(T1 a, T2 b){
return a + b;
}
But this is not easy in C++. What is the function return type? T1? Not
necessarily. T2? Not necessarily. Something else? But *what* else?
It's impossible to say. Dylan doesn't care.
You could also think of myAdd as being like a C++ virtual function that is
not actually part of a class, and that does runtime type dispatch based on
the types of *both* arguments, not just the first one.
Let's see what "d2c" (see <http://www.gwydiondylan.org>) does with this --
here is the C code output by d2c (with my comments after //):
// This is a reference to the "generic function" (i.e. runtime virtual
// function dispatch) for "+"
extern descriptor_t dylanZdylan_visceraZPLUS; /* + */
// This is the "virtual function" method for myAdd, used when the compiler
// doesn't know the types of the operands at compile time, and doesn't
// inline it either for some reason -- which doesn't happen in this example.
/* myAdd{<object>, <object>} */
descriptor_t * templateZtemplateZmyadd_METH(
descriptor_t *orig_sp, descriptor_t A0 /* a */, descriptor_t A1 /* b */
){
descriptor_t *cluster_0_top;
orig_sp[0] = A0;
orig_sp[1] = A1;
/* + */
cluster_0_top = GENERAL_ENTRY(dylanZdylan_visceraZPLUS.heapptr)(
orig_sp + 2, dylanZdylan_visceraZPLUS.heapptr, 2
);
return cluster_0_top;
}
// This is "f". The compiler has inlined the code for myAdd, so this looks
// just the same as the code for myAdd (above).
/* f{<object>, <object>} */
descriptor_t * templateZtemplateZf_METH(
descriptor_t *orig_sp, descriptor_t A0 /* x */, descriptor_t A1 /* y */
){
descriptor_t *cluster_0_top;
orig_sp[0] = A0;
orig_sp[1] = A1;
/* + */
cluster_0_top = GENERAL_ENTRY(dylanZdylan_visceraZPLUS.heapptr)(
orig_sp + 2, dylanZdylan_visceraZPLUS.heapptr, 2
);
return cluster_0_top;
}
// now we get to the interesting part! Not only was the code for myAdd
// inlined, the compiler also knew the types of the parameters, so it
// was able to replace the virtual dispatch of "+" in myAdd with direct
// use of an integer add instruction, just as you would get in C++
// inline template functions
/* g{<integer>, <integer>} */
long templateZtemplateZg_METH(
descriptor_t *orig_sp, long A0 /* x */, long A1 /* y */
){
return (A0 + A1);
}
// just the same as the above function, but this time it's inlined to a
// direct use of a floating-point add instruction. Which just happens to
// look the same in C, but that's not essential -- it could have been '+'
// for a user-defined class, in which case d2c would have use the appropriate
// C function call for that class.
/* h{<single-float>, <single-float>} */
float templateZtemplateZh_METH(
descriptor_t *orig_sp, float A0 /* x */, float A1 /* y */
){
return (A0 + A1);
}
Now, in this case, d2c has decided to inline all uses of myAdd(). But
this isn't essential. If myAdd() had been something a bit more
complicated then it might have choosen not to inline it, but to instead
use it as a template to create specialised versions of myAdd().
We can force the issue (and demonstrate the point) by adding the following
functions:
define method myAdd(a :: <integer>, b :: <integer>, #next super)
=> (c :: <integer>)
super();
end myAdd;
define method myAdd(a :: <single-float>, b :: <single-float>, #next super)
=> (c :: <single-float>)
super();
end myAdd;
This is essentially identical in purpose and effect to C++ explicit
instantiation of template functions.
"super()" is essentially the same idea as "super" in Java or SmallTalk or
"inherited" in Object Pascal (or the unsucessful C++ "inherited::"
proposal -- see section 13.6 in "The Design and Evolution of C++") --
except that in Dylan it applies to any overloaded function, not just
virtual functions. (btw, the name "super" is arbitrary, and in fact the
conventional name in Dylan code is "next-method"). The meaning, as usual,
is "call the function that would have been called in the first place, had
the current function not existed"
This change results in the C code output from d2c including the following
functions:
/* myAdd{<integer>, <integer>} */
long templateZtemplateZmyadd_METH_2(
descriptor_t *orig_sp, long A0 /* a */, long A1 /* b */, heapptr_t A2
){
return (A0 + A1);
}
/* myAdd{<single-float>, <single-float>} */
float templateZtemplateZmyadd_METH(
descriptor_t *orig_sp, float A0 /* a */, float A1 /* b */, heapptr_t A2
){
return (A0 + A1);
}
In this case we've forced the compiler to produce this. If the contents
of "myAdd" were a bit more complex then a smart compiler (d2c isn't smart
enough right now, but I'm hoping we'll make it smart enough soon) would
generate these functions automatically, for use when the types of a and b
were known but it wasn't worth inlining the whole function.
Unlike C++ template functions, these specialised functions are also useful
when the types of a and b are NOT known in advance, but fortuitously turn
out to be <integer> or <single-float> at run time. The specialised method
will automatically be called, rather than the general one, which will
result in not having to do virtual (generic) calls of arithmetic,
comparisons etc inside the function, and it may result in more efficient
calling (or even inlining) of any other functions called from within
myAdd().
I hope that I have demonstrated that a single simple mechanism in Dylan
can sucessfully replace *all* the different kinds of functions in C++,
with no loss of efficiency over C++.
I'll just point out at the end that the Dylan compiler I've used as the
example, d2c, is a free open source compiler that is still under active
development. Hopefully it will soon automatically inline and outline
(template expansion) functions automatically rather than needing the hints
I've used here.
d2c happens to generate C code, which is then compiled using gcc (or
other). This is convenient for the purposes of this note, because it
means we don't have to delve through Pentium or PowerPC or other machine
code to see what's going on under the covers. I have not altered the
genuine output of d2c except to clean up the formating and remove
extraneous comments and whitespace. Generating C code is of course not
essential for a Dylan compiler, and Harlequin Dylan (see
<http://www.harlequin.com/products/ads/dylan/> generates machine code
directly.
-- Bruce
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: tcp port no.s vs. processes
Date: 26 Jun 1999 23:17:16 -0400
[EMAIL PROTECTED] (Sudip Sarbajna) writes:
> Hi
> Does this command come in standard package?
> I am not being able to find this command even as 'root' user.
> My bash shell says 'command not found' when I type 'Isof' or, 'isof' etc. at
> the command prompt.
> Could you pls. help me out?
That's lsof, as in "list open files".
You might need to install it.
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 26 Jun 1999 23:00:01 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Justin Vallon <[EMAIL PROTECTED]> wrote:
> >void *::operator new(size_t s) { return kmalloc(s, GFP_KERNEL); }
> >void ::operator delete(void *p) { kfree(p); }
> >
> >I think we are agreeing here. No?
>
> No. This neglects error recovery. Also, the declaration of pointer
> types above is not C++-like. In good C++ we use "void* p", not "void *p".
If kmalloc fails, 0 is returned (or it should be). If ::operator new
fails to allocate memory, it is free to return 0. In that case, C++
will not construct an object, and new T() will return 0. The caller
must check that new returns a non-zero pointer.
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: NT kernel guy playing with Linux
Date: 27 Jun 1999 02:02:17 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
Thanks, Linus -- I feel like you just cleared up whatever remained of
my misconceptions about mutual exclusion primitives. Very helpful
post.
[Peter Samuelson <[EMAIL PROTECTED]>]
> > I say this in the hope of sparing others the confusion I had about
> > what a spinlock is. (It looked a lot like what CS calls a
> > semaphore, so why don't they just call it a semaphore, and what's
> > this semaphore_t...?)
[Linus Torvalds <[EMAIL PROTECTED]>]
> If your CS courses didn't tell you the difference between a semaphore
> and a spinlock, your CS courses were bad (or just didn't cover much
> about concurrency, which is fairly common).
The latter, I think.
> Blame your professors, don't blame the Linux kernel code.
Of course. Anyway, I had never encountered the term "spinlock" before
reading kernel code, but it was not hard to figure out what it was.
(The term is very descriptive.)
> A spinlock is a mutual exclusion mechanism, not a semaphore (a
> semaphore is a very specific _kind_ of mutual exclusion).
True; I was thinking of mutexes, because I (like you) haven't really
seen anyone using N-user semaphores, so I was under the impression that
those are mostly academic.
> they explicitly imply a "sleep"/"wakeup" behaviour, ie they are _not_
> spinlocks.
See, I didn't know this either -- that's the other reason I thought
spinlocks could be considered semaphores. I figured the sleeping part
was an implementation detail. (Of course, for something like user-mode
threads, it'd be a pretty important detail....)
> > However, you need to grab a spinlock for the purpose of grabbing a
> > semaphore_t
> Only in bad implementations or on bad hardware.
Hmmm, I was sure I had seen this in a kernel header file somewhere.
Looking again, it seems what I had seen was the rescheduling part,
which as you say is only for the contention case.
> some people believe in a mix-and-match approach, where you have a
> spinlock that gets upgraded to a semaphore if it waits too long.
Yes, I'd heard of these, but I've always dismissed them as too complex
to be worthwhile. It seems you should have either a known-short
critical section or a probably-long critical section. In the case of a
probably-short critical section you can usually redesign it as one
known-short section and one probably-long section.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Run in background
Date: 27 Jun 1999 02:24:51 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[vineet]
> > How do I make my C program to run in background after getting
> > initialised. I mean that the program should detach from the
> > terminal and should run in background like a daemon.
[mlw <[EMAIL PROTECTED]>]
> super simple.
[...]
> if(!fork())
[...]
That doesn't "detach from the terminal". To do that you have to jump
through interesting hoops like closing your tty fd's (typically 0,1,2),
and while you're at it you may as well setsid() to get a new session.
As someone else already posted, any decent Unix programming book will
have the Correct Invocations [tm] which, btw, are not entirely
portable. (I mean to pre-POSIX systems.)
Someone else posted about daemon(3). I didn't know that one. I'll
have to remember it. (Though it's probably not �ber-portable either.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
