Linux-Development-Sys Digest #63, Volume #7 Tue, 17 Aug 99 18:14:12 EDT
Contents:
Re: why not C++? (Raikanta Sahu)
Re: Troll (was: why not C++?) (Timo Tossavainen)
kernel guides? (James Stevenson)
Re: why not C++? (Tristan Wibberley)
Re: Printing in Linux ("Norm Dresner")
Re: why not C++? ("Arinte")
naive newbie wants to call add_timer() ([EMAIL PROTECTED])
Linux Site with 100's of links (arty)
Re: "top" command's source code! (Nix)
Re: why not C++? (Nix)
Re: why not C++? (Kaz Kylheku)
Re: threads ("Ted Pavlic")
Re: usleep() (David Schwartz)
Re: Source code licenses allow sharing between Linux and BSDs? (David Schwartz)
Re: why not C++? (Doug DeJulio)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Raikanta Sahu)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 17 Aug 1999 16:38:58 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 16 Aug 1999 19:43:39 -0700, Randall Parker <[EMAIL PROTECTED]> wrote:
>
> Suppose you have 3 methods in your pure virtual base class: aa(), bb(),
> cc(). Then you start inheriting off it in all sorts of ways that have
> various levels of inheritance hierarchy. For the purpose of notation
> suppose that each inherited version of aa is numbered: aa1, aa2, aa3, and
> so on. Ditto for bb (bb1, bb2, etc) and cc.
>
> Well, you could see a class that implemented
> aa1, bb1, cc1,
> Then another class that inherited from that class and just overrode bb
> again to make it:
> aa1, bb2, cc1.
> But then another class that inherited from the previous and added a new
> cc:
> aa1, bb2, cc2
> Now here is where we see how C++ comes up short. We want to make a new
> class that has
> aa1, bb1, cc2.
> Well, guess what? There is no way to make this new class after making
> those 4 other previous classes without repeating the body of either bb1
> or bb2 or cc1 or cc2.
Agreed that the language does not provide the capability you describe.
However, one can easily achieve what you want.
Let's call the base class MyClass1 and the subsequent classes MyClass2,
MyClass3, and MyClass4 respectively. The implementation of MyClass4::bb
would look like the following.
ReturnType MyClass4::bb(Args args)
{
return MyClass1::bb(args);
}
This seems to be a more than adequate answer to your need, I think.
I am curious to know whether this is a concocted problem or have you
really faced such a problem?
--
-Raikanta
+----------------------------------------------+--------------------------+
| Raikanta Sahu | phone: (505) 277-8332 |
| [EMAIL PROTECTED] | FAX : (505) 277-8235 |
+----------------------------------------------+--------------------------+
| Research Staff | 1601 Central Ave NE |
| Albuquerque High Performance Computing Center| University of New Mexico |
| University of New Mexico | Albuquerque, NM 87131 |
+----------------------------------------------+--------------------------+
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: Tue, 17 Aug 1999 20:50:42 +0300
Graffiti wrote:
> Oh god. The return of the LISP machines.... *shudder*
> They weren't *bad*, but look at where they are now. See my point?
> (Or rather, don't see it? :-)
Well, I think the lisp machines had specialized chips to evaluate lisp and were
quite proprietary. I think a modern open Lisp OS would be a good idea. It would be
a lot more stable than one, whose applications are mostly written in C/C++ and the
paradigm might be quite different from UNIX. Lisp machines and a Lisp OS are
different in the sense that lisp machines included specialized hardware. See
anything with specialized hardware in general use ? I'm not aware of the reasons
why the lisp machines didn't work out. I know people still use them but if someone
knows a bit more history, I'd be interested. It was most certainly not the fault
of the lisp language (or are people really that parenthetically challenged ? =)).
Timo
------------------------------
From: [EMAIL PROTECTED] (James Stevenson)
Subject: kernel guides?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 17 Aug 1999 20:01:56 +0000
Hi
is there any infomation
on the linux kernel
eg the linux kernel hacking guid
i cannot seem to find it
thanks
James
--
=============================================
Check Out: http://www.users.zetnet.co.uk/james/
E-Mail: [EMAIL PROTECTED]
8:00pm up 19:09, 4 users, load average: 2.05, 2.08, 2.02
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 16 Aug 1999 15:39:56 +0100
Reply-To: [EMAIL PROTECTED]
While I'm not opposing your conclusion that C++ in kernel is bad, I
would like to take issue with two of the reasons you present below.
Bjorn Reese wrote:
>
> To add salt to injury, you cannot use exceptions in global static objects
> because their constructors are executed before main(), and therefore
> cannot catch the exception.
You can use exceptions in global static objects. You reserve the space,
and construct the objects in main using placement new. This is what you
do in C, and what you should do in C++.
> I've also found it more difficult to debug C++ than C (especially the
> code of other people,) because (operator) overloading can make otherwise
> innocent looking code do much more than you had expected.
This is the same as using c_integer_shift( myint, myshift ). It
shouldn't do anything more than shift the integer by the specified
amount, but it might. This problem doesn't normally happen in a kernel
because people who are that dumb are not usually capable of writing a
kernel ;)
--
Tristan Wibberley
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Printing in Linux
Date: 17 Aug 1999 19:47:50 GMT
Chris <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> On 16 Aug 1999 21:02:04 GMT, "Norm Dresner" <[EMAIL PROTECTED]>
wrote
> in comp.os.linux.development.apps:
>
> >I need to write a c-program to print to the "default" printer which is
>
> Ignore the hardware-- you'll just get yourself into trouble. The system
> has a print queue that will manage the printing for you. Just open a
pipe
> to the lp program and dump everything there.
>
>
[SNIP]
Yes, on a normal, multi-user system, you'll all right, no program should
write directly to the printer. But (and I suppose I should have made this
clear), this isn't a normal application, more like an embedded computer
that happens to be running linux.
So, is there an answer to the question of how I can tell if there's a
default printer installed?
Norm
------------------------------
From: "Arinte" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 17 Aug 1999 13:28:38 -0400
Well, I can see some of your points. But, if it was programmed it C++ then
the programmer can have a choice of doing there code in c or c++ without
having to do extra work. Using C++ would have been more open.
But, C was the best choice since the C++ compiler wasn't up to snuff at the
time.
------------------------------
From: [EMAIL PROTECTED]
Subject: naive newbie wants to call add_timer()
Date: Tue, 17 Aug 1999 20:08:58 GMT
I'm trying to get some rudimentary understanding of calling a system
function.
// itimetest.c
#include <linux/timer.h>
int main()
{
timer_list tl; // (todo: initialize tl properly!)
add_timer( &tl);
}
[jclonts@deathstar cpp]$ g++ itimetest.c
/tmp/ccNO5zm3.o: In function `main':
/tmp/ccNO5zm3.o(.text+0xb): undefined reference to
`add_timer(timer_list *)'
So I'm trying to figure out, how do I tell the linker about the
function add_timer?
Thanks,
John
john-clonts(AT)reliantenergy(DOT)com
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: arty <[EMAIL PROTECTED]>
Subject: Linux Site with 100's of links
Date: Tue, 17 Aug 1999 16:14:31 -0400
Hi Check out my linux site it has 100's of usefull linux links.
http://mh005.infi.net/~arty3
Thanks
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: "top" command's source code!
Date: 17 Aug 1999 17:59:27 +0100
[EMAIL PROTECTED] (Kaz Kylheku) writes:
> On Sun, 15 Aug 1999 23:22:40 +0800, lming <[EMAIL PROTECTED]> wrote:
> >Hi...
> >
> >Does somebody could tell me where the top command's source code is ??
>
> I believe that it's part of a package called ``psutils''. Search for that.
ITYM `procps'. HTH.
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 17 Aug 1999 18:32:07 +0100
[comp.os.linux.development.apps removed from followups.
This is not an application development question.]
Cocheese <[EMAIL PROTECTED]> writes:
> *Why Is linux done primarily in the C programming language rather than
> C++?*
Many reasons.
Unix is normally written in C.
The C++ ABI is not yet stable (a major change is arriving with gcc-3.0,
for one).
Until the egcs project took off there was frankly no *good* free C++
compiler (the g++ frontend didn't do so many optimizations, and so
forth).
Many kernel developers feel that C++ does too much `behind the
programmer's back' (implicit type conversions, constructor calls,
&c). For normal development I feel that this is not true, but it may
well be true for kernel code, especially in time-critical hotspots or in
areas where races may happen, in which case it is important to be able
to *see* what's happening.
While it is true that a C++ person *can* see what is happening in C++
code, there is a vastly larger pool of C people than C++ people, and
most of the kernel developers are C people (although some are C++ people
too).
> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2,
Now this is a serious misstatement. Rewriting the kernel in C++ would
likely require a redesign of some portions; C++ is not C, it is a
different language, and if you want `a C++ kernel' rather than `a C
kernel written in C++' then design changes are necessary.
This would take *years*, probably. Most think this is not worth it for
the improvements it might bring (and I emphasize `might').
And Linus thinks that multi-year development cycles are a bad idea
(witness the feature freeze coming down for Linux 2.4 already).
> but if C++ is so much faster,
It isn't, normally. Heavy template magic can cause speedups in some
areas (eg Blitz++ can be substantially faster than C code), but this
involves shuffling computation off to compile-time, which is not often
useful for a kernel (the whole essence of which is rapid response to
real-time service requests &c).
Bear in mind that C++ and C both compile to assembler. C++ is not magic.
> easier,
This is meaningless marketroid garbage, sorry. It's a substantially more
complex language than C (many say it is *too* complex) and concomitantly
harder to learn.
It's also not easier to maintain than an equivalent corpus of C code, if
the C code is well-written. There would, I think, be negigible
maintenance improvements from changing the kernel to C++; the Linux
kernel is highly modular and uses many `OO-in-C' techniques already
(encapsulation and polymorphism are there, and access control is not
exactly a priority within the kernel code).
> and stable
It's considerably less stable than C. There are as yet no free compilers
that implement the entirety of the ISO C++ Standard. gcc is close, but
until a few weeks ago when 2.95 was released it was not very close.
The ABI is still changing (and you do not want *that* in kernel mode!)
The optimizers are still changing (and if you think optimizations
applied by the compiler do not affect kernel code, you would be wrong;
kernels often have to do things `below the surface' which may be broken
by optimizations applied by the compiler. There have been several
instances of such in the Linux kernel already.)
Your reasons for switching are very poor.
(There *are* reasons to switch, but they are thoroughly unconvincing.)
> I am struggling with it a bit but as i
> continue to learn this from an "other leading brand OS" and a full time
> programmer for a large company.
I have great difficulty parsing this statement. It doesn't appear to
obey standard English grammar rules; you have one clause which tails off
without an ending.
> There are many differences Between the two programming languages and
> there are huge advantages to C++.
Not in kernel code; at least not yet.
> The downside is "linux has always been a C based Program so it will always
> be."
Not necessarily. Linux has always been a GNU C (*not* ANSI/ISO C!) based
program, its developers like the language, and there are 1.5 million
lines of it. So changing it would need some pretty bloody good reasons
to get past Linus... especially given that several prominent developers
have said publically that they'd fork the tree and keep working on the C
branch if the kernel ever switched to C++.
> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***
Change with reason, where necessary. It's all about stability; kernels
have to be.
There was a massive flamewar on exactly this topic on linux-kernel a few
months back. You may want to look through the linux-kernel archives and
familiarize yourself with the arguments pro and con (mostly con, which
is a pity; I like C++ too. But unfortunately reality punctures many
dreams...)
--
'- I can't believe my room doesn't have Ethernet! Why wasn't it wired
when the house was built?
- The house was built in 1576.' --- Alex Kamilewicz on the Cambridge
breed of `conference American'.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 17 Aug 1999 19:55:04 GMT
On Mon, 16 Aug 1999 15:39:56 +0100, Tristan Wibberley <[EMAIL PROTECTED]>
wrote:
>While I'm not opposing your conclusion that C++ in kernel is bad, I
>would like to take issue with two of the reasons you present below.
>
>Bjorn Reese wrote:
>>
>> To add salt to injury, you cannot use exceptions in global static objects
>> because their constructors are executed before main(), and therefore
>> cannot catch the exception.
>
>You can use exceptions in global static objects. You reserve the space,
>and construct the objects in main using placement new. This is what you
>do in C, and what you should do in C++.
Right, but that is awfully inconvenient. What is the point of having global
constructors then if you are going to call the constructions from main?
Also, how do you reserve the space with guaranteed alignment?
You can't just do things like:
static char space_for_object[sizeof MyClass];
You might as well then just use the regular new operator then, which is
what is often done in practice.
What you could do is have a default constructor that does nothing to
the object, and can be safely called at global construction time. Then
when you do the placement new, you use a different constructor, the
real one that does work and can throw. (And to be totally correct,
you should call the in-place destructors of all the objects first).
If you are going to go to all this trouble, you might as well just not use a
constructor for doing the initialization. Have a default construtor that
doesn't do anything heavy such as acquisition of resources. And then have an
initialize() method which either returns false or throws or whatever. Then you
don't have to mess around with crap like placement new.
I find that in practice it's easier just to dynamically allocate the global
object. That way you have control about the timing of its construction,
and can catch exceptions and all that jazz.
>> I've also found it more difficult to debug C++ than C (especially the
>> code of other people,) because (operator) overloading can make otherwise
>> innocent looking code do much more than you had expected.
>
>This is the same as using c_integer_shift( myint, myshift ). It
>shouldn't do anything more than shift the integer by the specified
>amount, but it might.
Funny you should say that, given that the shift operators are used for
performing input and output in C++.
>because people who are that dumb are not usually capable of writing a
>kernel ;)
Who wrote MacOS or Windows 98 then? ;)
------------------------------
From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Tue, 17 Aug 1999 16:34:56 -0400
> This is most likely why NT & IIS was able to serve up web pages more
quickly
> then Linux & Apache in recent tests. My guess is that Windows programmers
> tend to think in terms of threads and Unix programmers tend to think in
> terms of processes. Possibly one reason why Linux is more stable, threads
> can be difficult to debug.
This is a very good point. But give Linux people time, I really think we all
will be more comfortable with threads as we realize exactly how many
advantages come with threads. Threads are really the next step PAST forking
off multiple processes to do concurrent tasks. Threads do this better.
Threads communicate with each other a lot better. Threads share memory a lot
better. True, threads are much more complicated and require a little bit
more thought, but once one gets used to threads, they become a very useful
and important tool.
To Linux programmers out there very stubborn about trying using threads, I
encourage them to broaden their views. Threads are important to NT. We all
know how Linux compares to NT.... Just think if threads help improve the
efficiency of NT, what could they do for Linux?
Anyone know of thread support being built into perl? ;-)
All the best --
Ted
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: usleep()
Date: Tue, 17 Aug 1999 14:09:47 -0700
Try nanosleep.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To:
comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.openbsd.misc
Subject: Re: Source code licenses allow sharing between Linux and BSDs?
Date: Tue, 17 Aug 1999 13:59:02 -0700
> In practice, BSD- and X11-type licensed software is often treated as
> if its copyrights had been transferred the public domain; many
> have no qualms about changing the licence on derivatives without
> consulting the other owners of the now-joint "work". Most will
> obey the terms of the original license and think there are no other
> considerations. I think they are wrong. They may, according to the
> license, distribute modified versions of the software in source or
> binary form, but nothing has given them the right to change the
> license of the original licensor's code which is contained in the
> now-jointly-owned software. The BSD license says "All rights reserved."
> That includes the right to control the use of their software using
> a license. The work of the original licensor remains controlled by
> that license until he explicitly allows the license to be changed.
> It seems like basic copyright law concepts. I wouldn't have any doubt
> that I could be wrong about this, except that it seems that so many
> disagree. IFAIK, no one has been to court over it yet.
The detail omitted from this analysis is that the source is, in effect,
dropped from airplanes. By doing so, the enforceability of your license
decreases dramatically.
Suppose I write a poem and drop 10,000 copies of it from an airplane.
On the back of the poem contains a clause that states that the poem is
the property of whomever picks it up and cannot be transferred to
another party. It also states that there's a $10 charge for reading it.
Clearly these terms could never be enforced. At least, I hope it's
clear.
Now imagine I put a poem up on a billboard. Do you think I could stop
someone from distributing a photograph that included my billboard? Do
you think I could collect royalties from everyone who read the
billboard?
Now consider code that's put on public FTP servers. It's included on
CDROMs that are given away. It's emailed to people. For all intents and
purposes, it's dropped from airplanes.
The crux is that no agreement entered into between the author and the
licensee when the copyrighted work changes hands. This is one step
_down_ from a shrink wrap agreement! At least there's a specific point
where a shrink wrap agreement can be argued to have been entered into,
prior to the copyrighted work being accessible to the person you are
claiming is agreeing.
I'm not a lawyer, I don't even play one on TV.
DS
------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 17 Aug 1999 16:53:00 -0400
In article <[EMAIL PROTECTED]>,
Warren Young <[EMAIL PROTECTED]> wrote:
>Cocheese wrote:
>> *Why Is linux done primarily in the C programming language rather than
>> C++?*
>
>I've seen many points brought up in this thread, but there's one that's
>absolutely critical, and it goes beyond all the reasons rooted in
>anti-C++ biases: C++ requires name mangling.
If the "why C" question is asking about libraries, your point applies.
It's possible to work around this C++ problem by declaring your
external interfaces via 'extern "C" { }' constructs, but that takes
discipline which many developers lack. For the reason you state, I
consider it really important that any widely-used open-source library
be written in C and not C++.
If the "why C" question is asking about the kernel, this issue is less
relevant. Programming libraries and user-space applications access
the kernel via a system call mechanism that has nothing to do with
symbol names (start reading the source code for the "open()" or
"ioctl()" function and see if you can detect the point where control
passes from user space to kernel space to see what I mean). The
symbol name conventions used by the kernel are *only* relelvant to
code that runs in kernel space (eg. the kernel itself, modules loaded
into the kernel, an interactive kernel debugger, et cetera).
Also, in this small and restricted domain (kernel hackers), the
discipline in enforcing 'extern "C" { }' interfaces would in theory be
easier to maintain.
In other words, I don't think people have refrained from mentioning
name mangling because nobody thought of it, but because the assumption
has been that the kernel is what's under discussion, and it's actually
*not* a major issue for the kernel.
(And I'm not saying this because I'd like things to switch to C++ -- I
would not. I'm one of the people the author would probably consider
to have "anti-C++ biases". I'd just like the decision to stick with C
to rest on more firm ground.)
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
** 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
******************************
