why not C++?

0 views
Skip to first unread message

Cocheese

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Dear Linux Community;

There has been a puzzling question on my mind for some time. First, I
admit i am no Linux Guru so this may be off the wall.


*Why Is linux done primarily in the C programming language rather than
C++?*


Again I admit it would take a little extra work and put a minor set
back in the evolution for a month or 2, but if C++ is so much faster,
easier, and stable- WHY NOT?


I have been a RH 6.0 user since the first week it was first released
and since then i have loved it. 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.

There are many differences Between the two programming languages and
there are huge advantages to C++.

The downside is "linux has always been a C based Program so it will always
be."

*** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***

-Sincerely

cocheese

------------------ Posted via CNET Linux Help ------------------
http://www.searchlinux.com

Xip

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Cocheese wrote:

Linux is primarily written in C because the C libs and gcc compiler is a lot
more stable than g++ and C++ libs used in Linux. Also, switching to C++ would
take a lot longer, considering GTK+ (even though there is GTK-- for C++) and
the other libs that are C specific. I prefer C because I don't really have
time to learn C++ (but I plan to), and so I can use the GTK+ libs.

Xip


Kaz Kylheku

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
On Mon, 16 Aug 1999 06:30:47 GMT, Cocheese <coch...@hotmail.com> wrote:
>Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
>admit i am no Linux Guru so this may be off the wall.
>
>
>*Why Is linux done primarily in the C programming language rather than
>C++?*

For one thing, when Linux started out, g++ wasn't all that great.
Only recently has g++ been whipped into shape by the EGCS project.

> Again I admit it would take a little extra work and put a minor set
>back in the evolution for a month or 2, but if C++ is so much faster,

Rewriting significant system components such as the kernel to take advantage of
the features of C++ would not be a month or two setback.

>easier, and stable- WHY NOT?

Doh, because it's NOT so much faster, easier and more stable? It's not faster
in run-time efficincy, nor in compile time. The history of g++ doesn't exactly
paint a picture of stability either.

C++ requires more extensive run time support. It gives you the object
orientation features, but you are stuck to how they are implemented by the
compiler. Many features in C++ are so complex that significant design choices
are involved in deciding how to implement them even without considering
machine dependencies. Once they are implemented a given way in a compiler,
the users are stuck with that.

Here is trivial example of C++ inflexibility. In C++, your concrete object has
to implement all pure virtual methods inherited from an interface base class.
Otherwise, invocations of that method cause a run time error (call to pure
virtual function). In many places in the Linux, virtual methods that are not
implemented are represented by a null pointer. The code that wants to call
the method tests for null and bypasses. Don't want to implement poll() in your
driver? No problem, just set it null. You can't do this in C++ code without
compiler-specific tricks that are undefined at the language level. The
compiler-generated virtual tables are sacred and untouchable things that are
invisible to the programmer. The usual escape hatch is to implement the
function, but have it return some ``I am not really implemented'' status. That
is much more expensive since an actual dispatch has to take place.

Another problem in C++ is that only member functions of a class can be virtual,
not data members. In C, whatever mechanism you use to represent virtual
dispatch tables can also hold things that are not pointers. Suppose that every
object in a class hierarchy has some characteristic that can be represented by
an integer. The characteristic is shared among all objects belonging to the
same class. In C++, you have to stick this characteristic into a base class
common to all the objects, or else use a virtual function to query the
characteristic. This is stupid, because the characteristic isn't settable for
each object, but is class-wide. You would ideally want to have some way of
saying ``object->characteristic'' and have virtual lookup take place to return
the class-specific value, but it's not available. You can do it easily if you
implement your own virtual table mechanisms. A virtual table done explicitly
can easily contain not only pointers to methods, but other class-specific data
as well.

In C++, when you start using multiple inheritance together with polymorphism,
things get very ugly at the compiler level. Depending on the vtable
implementation, you start seeing things like thunk code whose only job it is to
adjust an object pointer's value and then branch to some other code. Such
overheads exist even if you only use a subset of the full capabilities, such as
restricting yourself only to pure abstract base classes to create a single
concrete object. In actual object oriented programming, this sort of interface
inheritance is frequently all that you need, but C++ compilers make you pay
for the features you are not using.

In Linux, multiple inheritance is handled in an efficient, straightforward
manner. An ``class'', such as driver, implements two or more interfaces, which
are just sets of functions. Ppointers to these get stuffed into some
``operations'' structures that are static (that's another advantage to doing
things ``manually'': initialize vtables at run time!). The object then contains
some base part which contains a back pointer to the outer object. No
pointer-adjusting thunk functions are needed. The method itself can frequently
do the conversion simply by retrieving the context pointer from the base part
that it was given in the call. You can almost see the machine code. (Example
of multiple inheritance: the PPP driver, which is a kind of network device as
well as a kind of TTY line discipline).

> There are many differences Between the two programming languages and
>there are huge advantages to C++.

There are big advantages in C++, but I find that too many C versus C++
comparisons are based on false assumptions that none of the new C++ features
can be effectively simulated in C, or that the underlying techniques that the
C++ features support are unavailable to the C programmer. Assumptions such as
``because C doesn't have classes, object-oriented programming is impossible,
or so difficult as to be utterly impractical''.

Kaz Kylheku

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
On Mon, 16 Aug 1999 06:47:45 GMT, Satch <sa...@concentric.net> wrote:
>coch...@hotmail.com (Cocheese) wrote in
><rrfc0n...@news.supernews.com>:
>
>>*Why Is linux done primarily in the C programming language rather than
>>
>>C++?*
>
>Good question. Let me propose an answer. It has to do with the fact
>that the C++ environment has a lot of "baggage" that would adversely
>affect an operating system.
>
>First, the object model with its constructors and destructors mandates a
>heavy-duty memory management routine...and usually that memory management
>routine is part of the operating system. Chicken and egg problem...

Constructors and destructors don't imply memory management. They are just
functions that initialize and deinitialize an object. You have to have
constructors and destructors one way or another if you program using
abstract data types, because you need some way to bring each data object
into a sane state.

But there are disadvantages to C++ constructors. For one thing, they do not
return a value. The only sanctioned mechanism for indicating construction
failure is to throw an exception. Exception handling requires run-time support
and causes an increase in object file size. It has only recently begun to be
properly supported by G++, thanks to EGCS. The implementation adds serious
bloat to object files.

>Next, it's very difficult to predict how a C++ package is going to react
>in all circumstances, because there is more state inherent in a C++
>program than in a regular C program. Dynamic detection of object type,
>and run-time binding of objects to subroutines means that you have more
>run-time overhead...and operating systems already take too many cycles
>for the services they provide.

Linux has dynamic detections and virtual dispatches explicitly done in C. For
the most part, the mechanisms are clean and easy to understand. This can be
important if you are oops tracing after a crash.

Stephan Houben

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Cocheese <coch...@hotmail.com> writes:

> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
> admit i am no Linux Guru so this may be off the wall.
>
>

> *Why Is linux done primarily in the C programming language rather than
> C++?*
>
>

> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2, but if C++ is so much faster,

> easier, and stable- WHY NOT?

C++ might be easier, but it's not faster, nor stabler, than C.
OK, this depends also on the implementation, but the only serious
free C++-compiler is GCC, and for GCC, this statement is true.

You might want to take into account that Linus still sticks with
an older compiler (2.7, IIRC), because some of the optimisations
in the newer GCC versions break some of the Linux source code.

If even fixing such "minor" problems are that difficult, imagine
what it would mean to convert the whole of Linux to C++.

> There are many differences Between the two programming languages and
> there are huge advantages to C++.

There are also huge disadvantages.
C++ programs need a library for some of their more advanced language
constructs, such as new- and delete-operators, and exception handling.
Note that kernel memory cannot be swapped out; in a user program,
relying on a big shared library from which not everything is used is
no problem, but in the kernel, it is.

> The downside is "linux has always been a C based Program so it will always
> be."

A C++ Linux would probably mean a complete rewrite.
So who's stopping you from writing "Cocheex" ;-)

> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***

Did you take a marketing course recently?

Greetings,

Stephan

Erik de Castro Lopo

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Cocheese wrote:
>
> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
> admit i am no Linux Guru so this may be off the wall.

Well first off I should inform you there was a HTTNSTE (huge thread that
never seemed to end (tm)) a couple of weeks ago on this exact topic. Why
not search deja.com?


> *Why Is linux done primarily in the C programming language rather than
> C++?*

For programming OS kernels, C is a more lightweight language and probably
a better fit. For applications any language may be used, including C, C++
or any one of the dozen or so others that are available.

> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2,

To rewrite the kernel in C++? You must be joking. Even getting it to compile
reliably and correctly would take a lot of effort for exactly zero gain.

> but if C++ is so much faster,
> easier, and stable- WHY NOT?

How is faster, easier or more stable. C++ is a more complex laguage
syntactically and hence takes longer for the compiler to parse. C++
code object are bigger if things like exception handling and other C++
extras are used.

As for easier, how can you possibly say that a language with a much
larger syntax is easier. My experience of other people's C++ code
(I code mostly in C, only using C++ when I really need C++ features)
seems to suggest that with C++ it may be easier for an inexperienced
programmer to get something working (but inefficient) in C++ than it is
in C, but for an experienced programmers who know both languages there
isn't much difference.

The rare exception to this is where C++ is a much better fit to the
problem domain. For an example of this I would cite the Octave project
(large numerical analysis framework/application) where there is a
huge advantage to using C++ objects for things like matrices rather
than structs.

Finally, C++ compilers are not more stable. People have been working
on the gcc compiler for many years, but the C++ compiler g++ has only
just started being stable.

> I have been a RH 6.0 user since the first week it was first released
> and since then i have loved it. 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.
>

> There are many differences Between the two programming languages and
> there are huge advantages to C++.
>

> The downside is "linux has always been a C based Program so it will always
> be."

The kernel should be in C. C++ does not hold any huge advantages for
kernal development. For applications, feel free to use whatever you feel
mosty comfortable with.

Erik
--
+-------------------------------------------------+
Erik de Castro Lopo er...@zip.com.au
+-------------------------------------------------+
"I once worked for a company where as part of the BS5750 "Quality"
process I attended a meeting where I was informed that it was Company
Policy not to use free software. When I asked him for his written
authorisation for me to remove X Windows from our Sun workstations,
he backtracked." -- Phil Hunt

Frank V. Castellucci

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to

Kaz Kylheku wrote in message ...

>On Mon, 16 Aug 1999 06:47:45 GMT, Satch <sa...@concentric.net> wrote:
>>coch...@hotmail.com (Cocheese) wrote in
>><rrfc0n...@news.supernews.com>:
>>
>>>*Why Is linux done primarily in the C programming language rather than
>>>
>>>C++?*
>>
>>First, the object model with its constructors and destructors mandates a
>>heavy-duty memory management routine...and usually that memory management
>>routine is part of the operating system. Chicken and egg problem...
>
>But there are disadvantages to C++ constructors. For one thing, they do not
>return a value. The only sanctioned mechanism for indicating construction
>failure is to throw an exception. Exception handling requires run-time
support
>and causes an increase in object file size. It has only recently begun to
be
>properly supported by G++, thanks to EGCS. The implementation adds serious
>bloat to object files.
>

But this can be managed by the Factory pattern. In addition, in a OS
context, the factory would
be the desired route for instrumentation and management.

>>Next, it's very difficult to predict how a C++ package is going to react
>>in all circumstances, because there is more state inherent in a C++
>>program than in a regular C program. Dynamic detection of object type,
>>and run-time binding of objects to subroutines means that you have more
>>run-time overhead...and operating systems already take too many cycles
>>for the services they provide.

But the right analysis and design will allow predict invarient state.

I also noticed in this thread posits like "because g++ is not up to the
task" etc, etc. But I am sure that the developers of the Linux kernel
uncovered more then 1 bug in gcc!

Frank V. Castellucci

Christopher B. Browne

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
On Mon, 16 Aug 1999 07:47:33 -0400, Frank V. Castellucci <fca...@ibm.net>
posted:

>>and causes an increase in object file size. It has only recently begun to
>be
>>properly supported by G++, thanks to EGCS. The implementation adds serious
>>bloat to object files.
>
>But this can be managed by the Factory pattern. In addition, in a OS
>context, the factory would
>be the desired route for instrumentation and management.

Ah, yes. The famed "patterns."

>>>Next, it's very difficult to predict how a C++ package is going to react
>>>in all circumstances, because there is more state inherent in a C++
>>>program than in a regular C program. Dynamic detection of object type,
>>>and run-time binding of objects to subroutines means that you have more
>>>run-time overhead...and operating systems already take too many cycles
>>>for the services they provide.
>
>But the right analysis and design will allow predict invarient state.

In other words, if you move to C++, additional analysis and design work
is necessary to hope that it will work.

>I also noticed in this thread posits like "because g++ is not up to the
>task" etc, etc. But I am sure that the developers of the Linux kernel
>uncovered more then 1 bug in gcc!

GCC has represented a stable C compiler for many years now, and may
be considered mature.

G++ has not represented a stable C++ compiler for a terribly long time.
There is no question of it being "mature" yet.

The OS can only be as stable as the compiler is mature.

With the C++ language standard only having stabilized in the last year, it
hardly makes sense to criticize Linux for eschewing the use of a language
whose definition has been in flux throughout the bulk of its lifetime.

To my mind, the appropriate thing to do is to
Leave Well Enough Alone.

Linux functions well enough as implemented in C.

Breaking that by moving to C++, and thereby having a significant period of
time during which Linux would *definitely* not be stable, would be a
Very Dumb Idea.

If you want to have an OS written in C++, then it makes sense to start
designing a C++-based OS kernel.

It would make more sense to me to design such in something a bit less
egregariously complex, perhaps in Modula 3. This would have the clear
merit that people wouldn't make the Bad Mistake of assuming that they
could just fiddle with the C code and turn it into M3 as seems to be
the case with attempts to misdirect Linux kernel development to C++.
--
Rules of the Evil Overlord #35. "My pet monster will be kept in a
secure cage from which it cannot escape and into which I could not
accidentally stumble."
<http://www.eviloverlord.com/lists/overlord.html>
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>

Timo Tossavainen

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Oh no, not again... You did this on purpose... =)

I'll restate my point in the previous thread:

I need to interface to C from other languages (I don't use C or C++ on Linux
if there is a way I can avoid it). Interfacing from other languages to C++ is
harder than to C. This is because C++ objects don't have a binary standard and
there is no guaranteed way to interface with them. I use only Common Lisp on
Linux, maybe Prolog and some other more esoteric languages in the future and I
need this capability frequently. There is no single best language and using
C++ would make using the other languages harder. Yes, it's clearer than C in
most cases I won't argue about that.

Frankly I don't understand this C++ fetishism, if you want to do OO then at
least try Smalltalk or CLOS... the difference is unbelieveable. I've been
programming C++ for a few years and know it rather well, but Common Lisp was a
revelation in simplicity and elegance. Using C++ after that seems extremely
contorted, especially for dynamic stuff, like run-time extensibility.

This kind of thing is usually suggested by people who just learned to make
bigger programs using OO and in C++; no offense meant. I was quite a bit like
that after a few OO books and quite a lot of programming using OO and design
patterns. A side-effect of the OO hype ?

> The downside is "linux has always been a C based Program so it will always
> be."
>

> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***

<take with a grain of salt>
How about a paradigm shift ? Let's write a Lisp OS, where the Lisp environment
is the OS and throw away all the old buggy C code. Let's throw in
multiprocessing, hard realtime GC and scheduling and why not orthogonal
persistence while we're at it. Come to think of it this should have been done
ages ago... =) I'd be a happy user.
</take with a grain of salt>

The point being: If you want to do that, write a new OS and do it with pure
OO concepts from the very beginning. I don't see the benefit in trying to
force OO on a UNIX mindset. It won't work, you're better off with a new OS.
Maybe you could build some sort of OO system on top of the mach microkernel
in HURD and skip some of the devious stuff... I think it's designed for that
sort of thing. BTW, you could take a look at the academic OS research. There
are a lot of operating systems that have all sorts of nice OO capabilities.

Timo

Bob Martin

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
It has already been tried ( around kernel version 0.97 something, don't
remember exactly ) . didn't work out to well and was converted back to
standard C.

Cocheese wrote:
>
> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
>
> admit i am no Linux Guru so this may be off the wall.
>

> *Why Is linux done primarily in the C programming language rather than
>
> C++?*
>

> Again I admit it would take a little extra work and put a minor set
>

> back in the evolution for a month or 2, but if C++ is so much faster,


>
> easier, and stable- WHY NOT?
>

> I have been a RH 6.0 user since the first week it was first released
>
> and since then i have loved it. 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.
>
> There are many differences Between the two programming languages and
>
> there are huge advantages to C++.
>

> The downside is "linux has always been a C based Program so it will always
>
> be."
>
> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***
>

Edwin Young

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Stephan Houben <ste...@pcrm.win.tue.nl> writes:
> You might want to take into account that Linus still sticks with
> an older compiler (2.7, IIRC), because some of the optimisations
> in the newer GCC versions break some of the Linux source code.

I believe that kernel 2.0.x must be compiled with gcc 2.7.2.3 because
it has various bits of broken assembler which just happen to work with
that compiler, but not more recent versions. More recent kernels are
much more robust w.r.t gcc version.

Regards,

--
Edwin Young


Johan Kullstam

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Cocheese <coch...@hotmail.com> writes:

> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
> admit i am no Linux Guru so this may be off the wall.
>
>
> *Why Is linux done primarily in the C programming language rather than
> C++?*

oh dear god no. not *this* thread again.

<URL:http://deja.com/>

browse to your hearts content.

> Again I admit it would take a little extra work and put a minor set
> back in the evolution for a month or 2, but if C++ is so much faster,
> easier, and stable- WHY NOT?

well, it's not. at least if you are comparing C++ to C. C++ is equal
at best. C++ has a library which is constantly being revised. (i've
now got *5*, count 'em, *5* incompatible versions of libstc++.so on my
system.) C has libc which also changes, but it changes much more
slowly.

for kernel work, this library is not really an issue, since *you don't
have a library* and that make C++ somewhat less of a win.

> I have been a RH 6.0 user since the first week it was first released
> and since then i have loved it. 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.
>
> There are many differences Between the two programming languages and
> there are huge advantages to C++.

this is a matter of opinion. it also depends heavily on your target
program. applications in C++ is a good idea. for kernel and vital
utilities, i would say C++ is a bad idea.



> The downside is "linux has always been a C based Program so it will always
> be."

hey UTSL. get back to us when you've got something.

> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***

no. it's not. it's about cloning a 30 year old operating system.
admittedly it's a fairly good operating system. deviations are still
frowned upon.

--
johan kullstam

Doug DeJulio

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
In article <rrfc0n...@news.supernews.com>,

Cocheese <coch...@hotmail.com> wrote:
> Again I admit it would take a little extra work and put a minor set
>back in the evolution for a month or 2, but if C++ is so much faster,
>easier, and stable- WHY NOT?

Not everyone agrees that C++ is faster, easier, and stable. In
particular, it can be demonstrated that any stability C++ has on Linux
is actually fairly recent (egcs).

> There are many differences Between the two programming languages and
>there are huge advantages to C++.

Again, not everyone agrees that there are huge advantages to C++ when
used as a systems (as opposed to applications) programming language.
--
Doug DeJulio | mailto:d...@hks.net
HKS, Incorporated | http://www.hks.net/~ddj/

Kaz Kylheku

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
On 16 Aug 1999 18:16:56 GMT, William Burrow <aa...@DELETE.fan.nb.ca> wrote:
>There are kernels designed in C++ no doubt. I think the Tune OS page
>has a listing of various kernels. Memory fades....

But how do these stack up in static web page serving benchmarks? :) :) :)

Frank V. Castellucci

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to

Christopher B. Browne wrote in message ...

>On Mon, 16 Aug 1999 07:47:33 -0400, Frank V. Castellucci <fca...@ibm.net>
>posted:

>>But this can be managed by the Factory pattern. In addition, in a OS


>>context, the factory would
>>be the desired route for instrumentation and management.
>
>Ah, yes. The famed "patterns."


Patterns are not unique, or new. They have existed since life began. Famed?
I think not. Recognizable? You have answered that already.

>>But the right analysis and design will allow predict invarient state.
>
>In other words, if you move to C++, additional analysis and design work
>is necessary to hope that it will work.


Bzzzz! Wrong. I am of the strong point of view that ALL software development
should have a plan that includes the invarient state of (put your favorite
term here) all of the objects that participate during processing. Whether it
be assembler or Logo, if you as the architect do not know what state your
systems or sub-systems are in during use cases you will certainly have a
buggier product.

>GCC has represented a stable C compiler for many years now, and may
>be considered mature.
>
>G++ has not represented a stable C++ compiler for a terribly long time.
>There is no question of it being "mature" yet.
>
>The OS can only be as stable as the compiler is mature.


Yes, and I have seen the comments in the kernel code defering to bugs in the
compiler. We all have written "work-arounds" to overcome a weakness we may
find in our choice of compilers.

>With the C++ language standard only having stabilized in the last year, it
>hardly makes sense to criticize Linux for eschewing the use of a language
>whose definition has been in flux throughout the bulk of its lifetime.

No one is making any derogatory statements in this thread.

>To my mind, the appropriate thing to do is to
> Leave Well Enough Alone.
>
>Linux functions well enough as implemented in C.
>
>Breaking that by moving to C++, and thereby having a significant period of
>time during which Linux would *definitely* not be stable, would be a
>Very Dumb Idea.

Without any basis of how it would be a Very Dumb Idea, I won't agree with
you on these statements. I will take a moment to comment that THERE IS
CHANGE in this world. One measure of the flexibility of a system is how well
it can continue to work in the face of change. How well can it adapt to the
requirements needed to keep it usefull. I have run into these walls with
systems in many languages (including C++).


>If you want to have an OS written in C++, then it makes sense to start
>designing a C++-based OS kernel.

I think that was the original authors starting point.

Frank V. Castellucci

Randall Parker

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
Kaz,

I liked all your points. The hte points about the vtable remind me of
another one:

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.

The problem is that when each implementation of aa or bb or cc is defined
it is defined for a particular class. You then run into situations where
you have to repeat an implementation of a particular method in order to
get it in various combinations with the other implementations of other
methods in the inheritance hierarchy.

I've run into this problem more than once in C++ work. So we had to do
things like make functions and instantiate classes with constructors that
got passed lists of pointers to functions. Then you had a class that had
aa, bb, cc and each of them then called a function via a pointer that was
an object variable.

One really would like to be able to define a bunch of versions of aa, of
bb, and of cc. Then be able to instantiate objects that implemented
various combinations of those methods and have a vtable get built at time
of instantiation. That is what I most wanted.

Short of that I'd like to be able to define various classes where instead
of going:
MyDerivedClass::MyMethodAA(arg types)
{
the body of the method
}
One could preferably go:
MyPureBaseClass::MyMethodAA(arg types);
Then go
MyPureBaseClass::MyMethodAA(arg types) MyMethodAA1
{
the body of the method with AA1 style implementation
}
MyPureBaseClass::MyMethodAA(arg types) MyMethodAA2
{
a different body of the method with AA2 style implementation
}

Then be able to inherit MyFirstDefinedClass off of MyPureBaseClass to
define MyFirstDerivedClass. And then go:
MyFirstDerivedClass::MyMethodAA == MyMethodAA2
to indicate which variant of MyMethodAA should have its address stuffed
in the vtable for MyFirstDerivedClass.

But C++ can't do anything like this. Its incredibly static straitjacket
for vtable is a shame.

I think that class level variable scope control is a great idea. C needs
better ways to control the name space. C also needs all sorts of neat
little language extensions that came along in C++ that had nothing to do
with OO. Also, C++ templates (though a compiler writer's nightmare) are a
lot more flexible and powerful than #define macros. But I just find C++'s
way of constructing vtables to be far too limited.

(this message has gone on too long so I won't tell you other things I
find bad about C++)

In article <slrn7rfgu...@ashi.FootPrints.net>,
k...@ashi.FootPrints.net says...

Randall Parker

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
I think the real problem with C++ and heap memory is that too many
programmers who use C++ do not understand how much all the stuff they are
writing is fragmenting the heap.

Watching various (in many cases dangerous) programmers using C++ it has
been my experience that new seems to be more natural to them (ie they are
less likely to hesitate before using it) than is malloc. So they just use
it mad.

Also, I've seen a lot of people writing a bunch of classes where they end
up constructing a smaller object, then passing it to the constructor of a
larger one to be copied into it, and then repeating that about 5 times as
they built up bigger and bigger objects.

They don't see that they are copying data like mad. All that is hidden in
constructors. They also seem to think that doing a new on a class has no
more overhead than declaring a variable on the stack.

I think it takes far greater discipline to write good C++ than good C
even though in theory the syntax of C++ ought to encourage the users to
think more about the design and partitioning of a problem. In practice
they don't know how to partition things into objects, they thrash and
fragment the heap, and they consume way more memory and do much more
copying around of data.

And they do all this seemingly oblivious to what they are doing.

The worst I ever saw of this was when I was able to trace a piece of data
coming in on a serial device and then getting copied a dozen times into a
dozen successively instantitated objects as it got passed back up a call
tree and then got passed between two processes before finally being
formatted for display. Oh, and at each level the new object was bigger
than the object before it. The data did get scaled along the way but
maybe 2 or 3 copies were necessary. Then everyone wondered why the code
was so slow.

In article <m34si0i...@pcrm.win.tue.nl>, ste...@pcrm.win.tue.nl
says...

Tristan Wibberley

unread,
Aug 16, 1999, 3:00:00 AM8/16/99
to
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

Joshua D. Boyd

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
Timo Tossavainen wrote:

> <take with a grain of salt>
> How about a paradigm shift ? Let's write a Lisp OS, where the Lisp environment
> is the OS and throw away all the old buggy C code. Let's throw in
> multiprocessing, hard realtime GC and scheduling and why not orthogonal
> persistence while we're at it. Come to think of it this should have been done
> ages ago... =) I'd be a happy user.
> </take with a grain of salt>
>
> The point being: If you want to do that, write a new OS and do it with pure
> OO concepts from the very beginning. I don't see the benefit in trying to
> force OO on a UNIX mindset. It won't work, you're better off with a new OS.
> Maybe you could build some sort of OO system on top of the mach microkernel
> in HURD and skip some of the devious stuff... I think it's designed for that
> sort of thing. BTW, you could take a look at the academic OS research. There
> are a lot of operating systems that have all sorts of nice OO capabilities.

I've frequently wondered why other OSs don't become more popular. I'm use linux

almost exclusivly at home (I also have BeOS installed, which I do use, and Windows,

which is only used to play games, but I usually don't since the effort of rebooting

just to game is too much), and I've frequently wished for more modern OSs. I know

they are out there, but when ever I read about one, I usually also find that it is too

early in development. For profit I do database programming, and for fun, I write

heavy duty media programs (or at least attempt to). What I do for fun is really pushing

the edges of linux, let alone stuff like Plan9 or GNU/Hurd, and since I don't have the

skill or desire to do systems programming, I'm stuck using more established stuff.

I was quite excited when finally a version of BeOS came that would run on my hardware,

but I was quickly quite disappointed by the network services. It probably is a picky

point to complain about their primitive web browser, but I found myself needing to

reboot to linux anytime I needed to get something from the web, which isn't good if you

hate rebooting like I do. Also, I had trouble with networked file access (i'm told

that is fixed in the latest version which I haven't yet installed), which made getting

files to work from the server a real pain. Finally, I was disappointed by the fact

that it wasn't really a multiuser system.

On linux, for some tasks, I wish I had a pervasively object oriented system like BeOS

or NeXTStep, or many other less developed systems, but for various reasons, I was never

able to use them, or was unsatisfied. Don't get me wrong, I love linux, but I am

frequently left wondering if it couldn't be much more powerfull is wasn't lugging

all of the unix legacy behind. Stuff like BeOSs file system look really cool, not to

mention the NeXTStep display system (if only it could operate remotely like X11 does),

or the way ActiveX and OLE provides services (I think the implementations is awefull,

but I've never seen stuff like corba do the things that I do with ActiveX). Hopefully

someday soon peope will take something like Hurd, or Linux, or other free OS and turn

it into a more modern OS that is just as flexible as Linux, Irix, or Solaris is (I

don't consider *BSD, Windows NT, NeXTStep/OpenStep/MacOSX, or BeOS to be as flexible.

Each of those either lacks in the workstation arena or the server arena).

--
Joshua D. Boyd
http://catpro.dragonfire.net/joshua


Christopher B. Browne

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On Mon, 16 Aug 1999 20:50:43 -0400, Frank V. Castellucci
<fca...@ibm.net> posted:
>>GCC has represented a stable C compiler for many years now, and may
>>be considered mature.
>>
>>G++ has not represented a stable C++ compiler for a terribly long time.
>>There is no question of it being "mature" yet.
>>
>>The OS can only be as stable as the compiler is mature.
>
>Yes, and I have seen the comments in the kernel code defering to bugs in the
>compiler. We all have written "work-arounds" to overcome a weakness we may
>find in our choice of compilers.

Yes, and the maturity of GCC for C means that the kernel folk can
expect their understanding of how GCC generates code to be at least
somewhat meaningful.

>>If you want to have an OS written in C++, then it makes sense to start
>>designing a C++-based OS kernel.
>
>I think that was the original authors starting point.

... A starting point that doesn't relate to comp.os.linux.*, which
represents the set of newsgroups in which the notion is being
proposed.

comp.os.research would be a far better place to post proposals about
the idea of developing a new OS written in C++.
--
We all live in a yellow subroutine, a yellow subroutine, a yellow subroutine...
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>

Christopher B. Browne

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On 16 Aug 1999 18:16:56 GMT, William Burrow <aa...@DELETE.fan.nb.ca> posted:

>On Mon, 16 Aug 1999 13:38:25 GMT,
>Christopher B. Browne <cbbr...@news.brownes.org> wrote:
>>>I also noticed in this thread posits like "because g++ is not up to the
>>>task" etc, etc. But I am sure that the developers of the Linux kernel
>>>uncovered more then 1 bug in gcc!
>>
>>GCC has represented a stable C compiler for many years now, and may
>>be considered mature.
>
>True, but for sure bugs were found in gcc -- look for comments in the
>kernel source about these! There are also source optimizations to get
>around limitations in the gcc optimizer. There are few comments in
>Linux kernel source, but some of them are mighty interesting. :)

Toss in G++, and there will doubtless be a *host* of new bugs, just
'cause the code isn't *nearly* as mature.
- Just look back at the flame wars of the last year over the
merits/demerits of EGCS.
- Look at the number of not-quite-interoperable libg++ versions.

Some might draw the conclusion from such things that G++ is "rubbish;"
after removing such extreme positions from the population of issues,
we're still left with the conclusion that G++ has been changing quite
a lot and is not yet "stable."

>>If you want to have an OS written in C++, then it makes sense to start
>>designing a C++-based OS kernel.
>

>There are kernels designed in C++ no doubt. I think the Tune OS page
>has a listing of various kernels. Memory fades....
>

>>It would make more sense to me to design such in something a bit less
>>egregariously complex, perhaps in Modula 3. This would have the clear
>>merit that people wouldn't make the Bad Mistake of assuming that they
>>could just fiddle with the C code and turn it into M3 as seems to be
>>the case with attempts to misdirect Linux kernel development to C++.
>

>Could we start with a C library done in a Wirthian language? Ack, the
>horror.... :)

I suggest M3 for three reasons:
a) There are examples of OS kernels implemented in it (SPIN);
b) There is actual merit to the idea, as M3, while "Wirthian," is
nonetheless a fairly nice language, and most importantly,
c) Since there's no subset in common with C, nobody will make the
mistake of thinking that it's a quick port, as might be the case
with C++.

--
Rules of the Evil Overlord #39. "All naive, busty tavern wenches in my
realm will be replaced with surly, world-weary waitresses who will
provide no unexpected reinforcement and/or romantic subplot for the
hero or his sidekick."
<http://www.eviloverlord.com/lists/overlord.html>
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>

M van Oosterhout

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to Joshua D. Boyd
Joshua D. Boyd wrote:

> but I've never seen stuff like corba do the things that I do with ActiveX). Hopefully

Have you looked at GNOME?

It is a whole desktop environment based completely on CORBA. The
most impressive thing I've seen to date is embedding a complete
full-colour vector graphics image of a lion into a speadsheet.

I intend to look at this more in the future, but concepts
behind it are amazing.

Martijn van Oosterhout
Australia

Phil Howard

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On Mon, 16 Aug 1999 19:56:20 -0700 Randall Parker (rgpa...@west.net) wrote:
| I think the real problem with C++ and heap memory is that too many
| programmers who use C++ do not understand how much all the stuff they are
| writing is fragmenting the heap.

Of course. They tend to be abstraction oriented applications programmers.
Details? We don't need no steenkin details! :-)


| Watching various (in many cases dangerous) programmers using C++ it has
| been my experience that new seems to be more natural to them (ie they are
| less likely to hesitate before using it) than is malloc. So they just use
| it mad.

Many also seem to be less likely to hesitate to skip object oriented design
and jump right into object oriented coding. It's still object oriented so
they feel the objective (sorry) is met.


| I think it takes far greater discipline to write good C++ than good C
| even though in theory the syntax of C++ ought to encourage the users to
| think more about the design and partitioning of a problem. In practice
| they don't know how to partition things into objects, they thrash and
| fragment the heap, and they consume way more memory and do much more
| copying around of data.

The thing I think has really happened with C++ is that it has made it so
easy to program object oriented code, that so many ill-prepared programmers
have joined in, that much C++ code out there is assumed to be object
oriented only because it was written in C++ and uses many object classes.
Many, many, good C++ programmers do things the right way, but there is a
huge set of programmers that know OO is good, C++ is OO, and therefore
their C++ is OO ... they don't know what object oriented design is.

--
Phil Howard KA9WGN
ph...@intur.net ph...@ipal.net

andy_m...@my-deja.com

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
In article <slrn7rhga0....@knuth.brownes.org>,

cbbr...@hex.net wrote:
> Toss in G++, and there will doubtless be a *host* of new bugs, just
> 'cause the code isn't *nearly* as mature.
> I suggest M3 for three reasons:
> a) There are examples of OS kernels implemented in it (SPIN);
> b) There is actual merit to the idea, as M3, while "Wirthian," is
> nonetheless a fairly nice language, and most importantly,
> c) Since there's no subset in common with C, nobody will make the
> mistake of thinking that it's a quick port, as might be the case
> with C++.

I can hardly stand this ...

1.) IMHO it is best if the source corpus (the totality of all source
code of an operating system and its tools) is written in a single
language. The advantages are obvious: You just have to learn one
language, can concentrate on maintaining one compiler and not more,
you do not waste time by translating from one language into another,
can become a real expert on one language instead of having a more
vague knowledge of more languages and so on

2.) The language should be small and simple, kind of a "portable
machine language", we do not want to use recently developed
experimental language concepts. (Say things developed in the last
10 years.) (I admit that M3 is quite a stable thing.)

3.) Well, all of the above we have right now with C (ANSI C,
ISO C). We have a standard language. We can concentrate one
getting the job done in it. We do not have to waste time by
changing the language every 10 years rewriting all of the source
corpus and once its has stabilized after ten years to start
anew to rewrite in in the then-fashioned language.

Just keep on using C. Why mess it all up with M3, C++?
(Will someone come up with Java now?)

With kind regards

Andy Merkens


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Raikanta Sahu

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On Mon, 16 Aug 1999 19:43:39 -0700, Randall Parker <rgpa...@west.net> 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 |
| rs...@unm.edu | 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 |
+----------------------------------------------+--------------------------+

Bjorn Reese

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
Kaz Kylheku wrote:

> But there are disadvantages to C++ constructors. For one thing, they do not
> return a value. The only sanctioned mechanism for indicating construction
> failure is to throw an exception. Exception handling requires run-time support

> and causes an increase in object file size. It has only recently begun to be

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.

Furthermore, using virtual functions in constructors/destructors can
result in member functions being executed on uninitialized objects.

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.

Another poster replied to the above quote, but saying that it can be
managed by the Factory pattern. I agree, and want to add that the
Factory pattern can be implemented in C too.

Graffiti

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
In article <37B8188B...@cs.uta.fi>,
Timo Tossavainen <t...@cs.uta.fi> wrote:
[snip]

><take with a grain of salt>
>How about a paradigm shift ? Let's write a Lisp OS, where the Lisp environment
>is the OS and throw away all the old buggy C code. Let's throw in
>multiprocessing, hard realtime GC and scheduling and why not orthogonal
>persistence while we're at it. Come to think of it this should have been done
>ages ago... =) I'd be a happy user.
></take with a grain of salt>

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

-- DN (I don't know if the LISP machines purpoted to do hard-real time,
though. Doubt it.)

Arinte

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
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.

Timo Tossavainen

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
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

Kaz Kylheku

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On Mon, 16 Aug 1999 15:39:56 +0100, Tristan Wibberley <blo...@cus.umist.ac.uk>
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? ;)

Kaz Kylheku

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On Tue, 17 Aug 1999 13:28:38 -0400, Arinte <sho...@beinmessage.com> wrote:
>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.

Nonsense, you still have the choice of using C++. You should be able to
write a driver in C++ for Linux. A loadable module is just a slab of
machine code and data. As long as it behaves right and doesn't ask for any
symbols that the kernel can't give it, it's fine.

So for example if you wanted to use, say, C++ exception handling in your
driver, you would have to provide your own run-time support for it within that
object, since the kernel wouldn't resolve your undefined reference to
things like __throw() . Adding this support would take some work, so you
might opt for doing without the feature.

Warren Young

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
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.

Name mangling is a very practical solution to a real problem (namely,
old C-style linkers being used for linking C++ code). The problem is,
you can't call mangled C++ functions from non-C++ languages, at least
not without a whole lot of messy glue in between.

Keep in mind, not even C is the be-all and end-all of computer
languages. People regularly program Linux in dozens of other languages,
many of which don't have any real way of calling C++ code.

C-based interfaces, at least, are callable from any sane language.
Thus, it makes sense to write core libraries and interfaces in C. If
you want OO, you can write wrappers on top of that, as happened with
Gtk+ and OO extension libraries like Gtk--.

> The downside is "linux has always been a C based Program so it will always
> be."

Again, find or write appropriate C++ wrappers. You don't need to
re-write the kernel as an OOP program in order to write application
programs in an OOP fashion.
--
= Warren Young, maintainer of the Winsock Programmer's FAQ at:
= http://www.cyberport.com/~tangent/programming/winsock/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

Nix

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
[comp.os.linux.development.apps removed from followups.
This is not an application development question.]

Cocheese <coch...@hotmail.com> 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'.

Doug DeJulio

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
In article <37B98B21...@mail.com>,
Warren Young <tan...@mail.com> 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.)

Kaz Kylheku

unread,
Aug 17, 1999, 3:00:00 AM8/17/99
to
On Tue, 17 Aug 1999 10:17:38 -0600, Warren Young <tan...@mail.com> wrote:
>Keep in mind, not even C is the be-all and end-all of computer
>languages. People regularly program Linux in dozens of other languages,
>many of which don't have any real way of calling C++ code.

You can use the extern "C" linkage specifications to create C++ functions
that can be called as C functions (i.e. do not have name mangling).

Linkage specifications go both ways; they allow C++ programs to call C,
but also to define functions that are callable from C.

Christopher Browne

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
On Tue, 17 Aug 1999 20:50:42 +0300, Timo Tossavainen <t...@cs.uta.fi>
wrote:
>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.

The founding of Symbolics and Lisp Machines has a great deal to do
with the founding of the Free Software Foundation... I do not recall
offhand which company of the two RMS considered the "bad guys," but
there was much bad blood at the time...

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

Try *could* be more stable...

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

Richard Gabriel wrote a book about his related experiences; there was
a *lot* of AI-related hype, and a number of pretty big mistakes...

>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 ?
>=)).

--
"Parentheses? What parentheses? I haven't noticed any parentheses
since my first month of Lisp programming. I like to ask people who
complain about parentheses in Lisp if they are bothered by all the
spaces between words in a newspaper..."
-- Kenny Tilton <ti...@liii.com>
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lisposes.html>

Christopher Browne

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
On Tue, 17 Aug 1999 07:02:28 GMT, andy_m...@my-deja.com
<andy_m...@my-deja.com> wrote:
>Just keep on using C. Why mess it all up with M3, C++?
>(Will someone come up with Java now?)

I suggested M3 in part because that would make it manifestly obvious
that the result of such a process is Not Going To Be Linux.
--
"The Amiga is proof that if you build a better mousetrap, the rats will
gang up on you." -- Bill Roberts bill.r...@ensco.com
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>

Phil Howard

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
On Tue, 17 Aug 1999 13:28:38 -0400 Arinte (sho...@beinmessage.com) wrote:
| 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.

C++ can call C functions more easily (although without benefit of features)
than C can call C++. There would have to be C stubs to front end a C++ SPI.

I would have thought there would be a C++ analogy to the system calls that
has been written as a library somewhere. If not, then maybe there should be.
If C++ programmers feel the need, surely they would develop it, no?

Stephan Houben

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
Timo Tossavainen <t...@cs.uta.fi> writes:

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

I disagree. It's a bad idea to have a Lisp OS, a C++ OS, a Java OS,
and basically any X OS where X is a programming language. Why?
Because a general purpose OS should *never* force a particular
programming language upon its users. No language is perfect.
Every language sucks, if confronted with the "right" (i.e. the wrong)
application area.

IIRC there was a C compiler for some Lisp machines. It implemented
pointers with "cons"-cells. A greater abstraction inversion the world
has never seen.

Note that Linux is not a C OS. It is a general-purpose OS whose kernel
happens to be written in C. If they hadn't told me this, I would never know.
I still don''t care. As long as the StephanTalk compiler does its job,
I don't care in which language the OS is written.

Greetings,

Stephan

Timo Tossavainen

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
Stephan Houben wrote:

> Timo Tossavainen <t...@cs.uta.fi> writes:
>
> > 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.
>
> I disagree. It's a bad idea to have a Lisp OS, a C++ OS, a Java OS,
> and basically any X OS where X is a programming language. Why?
> Because a general purpose OS should *never* force a particular
> programming language upon its users. No language is perfect.
> Every language sucks, if confronted with the "right" (i.e. the wrong)
> application area.

Who ever said anything about general purpose ? I didn't mean to exclude other
languages, just the design and the internals of the OS (including the GUI and audio)
would be done using a Lisp mindset and a Lisp compiler rather than the C mindset and
a C compiler, it would at least be more extensible if done right and safer if the
safety checks would be left on. Using Lisp in Linux is harder than using C/C++
because the internals and the libraries are in C and the Lisp way of doing things is
different. No language is perfect, but some languages are more perfect than others
=) No seriously, the need to communicate with C is taking away some of the
expressive power of Lisp and forcing it to live at least partially in the static
world of C. For instance, it's probably practically impossible to build fine-grained
source code level parallel processing which is possible in functional languages on
top of C-style threads. That would probably require linking the kernel scheduler to
the lisp evaluator.

Timo


Stephan Houben

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
Timo Tossavainen <t...@cs.uta.fi> writes:

> Stephan Houben wrote:
>
> > Timo Tossavainen <t...@cs.uta.fi> writes:
> >
> > > 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.
> >
> > I disagree. It's a bad idea to have a Lisp OS, a C++ OS, a Java OS,
> > and basically any X OS where X is a programming language. Why?
> > Because a general purpose OS should *never* force a particular
> > programming language upon its users. No language is perfect.
> > Every language sucks, if confronted with the "right" (i.e. the wrong)
> > application area.
>
> Who ever said anything about general purpose ? I didn't mean to exclude other
> languages, just the design and the internals of the OS (including the GUI and audio)
> would be done using a Lisp mindset and a Lisp compiler rather than the C mindset and
> a C compiler, it would at least be more extensible if done right and safer if the
> safety checks would be left on.

So you mean that the OS is implemented in Lisp but more or less hides this
fact. Well, that might work, except that I feel that Lisp is not
really suited for this job. Common Lisp shares the problem with C++
that it relies on big standard libraries. Scheme is probably too
minimalistic, and call/cc makes efficient implementation nontrivial.

Nevertheless, a specially designed for kernel work Lisp type of language
could do the job.

> Using Lisp in Linux is harder than using C/C++
> because the internals and the libraries are in C and the Lisp way of doing things is
> different.

You are talking ordinary application development now?
Frankly, I don't use Lisp enough to comment.
However, I *do* use Python, which is != C, and which is very easy to
use on Linux, despite that fact.

> No language is perfect, but some languages are more perfect than others
> =) No seriously, the need to communicate with C is taking away some of the
> expressive power of Lisp and forcing it to live at least partially in the static
> world of C. For instance, it's probably practically impossible to build fine-grained
> source code level parallel processing which is possible in functional languages on
> top of C-style threads. That would probably require linking the kernel scheduler to
> the lisp evaluator.

IIRC, the "standard" solution is to have lots of user-level threads
that are piggybacked upon a limited number of kernel threads.
Similar approaches are used for a lot of languages when fine-grained
paralellism is required, even for C. So I wonder whether this is a Lisp issue.

But frankly, you might know much more about this subject than I do, so
perhaps I should stop talking now. ;-)

Greetings,

Stephan

Timo Tossavainen

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
Stephan Houben wrote:

> So you mean that the OS is implemented in Lisp but more or less hides this
> fact. Well, that might work, except that I feel that Lisp is not
> really suited for this job. Common Lisp shares the problem with C++
> that it relies on big standard libraries. Scheme is probably too
> minimalistic, and call/cc makes efficient implementation nontrivial.
>
> Nevertheless, a specially designed for kernel work Lisp type of language
> could do the job.

IIUC Common Lisp is sometimes implemented on top of a low level lisp, which is a bit like
C in that it can access pointers and handle other low level stuff and is of course as
unsafe as C. Basically a lisp system could go from Common Lisp all the way down to the
assembler level just the same as C++ goes from high level of abstraction to
inline-assembler.

> But frankly, you might know much more about this subject than I do, so
> perhaps I should stop talking now. ;-)

Probably not, I'm just a hobbyist in these things.

Timo


Tristan Wibberley

unread,
Aug 18, 1999, 3:00:00 AM8/18/99
to
Kaz Kylheku wrote:
>
> On Mon, 16 Aug 1999 15:39:56 +0100, Tristan Wibberley <blo...@cus.umist.ac.uk>
> 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?


Exactly. Global constructors are rarely useful, there is not much point
to them (IMHO) except making C++ easier to start learning (and it means
more bugs early on, but you don't have to learn a great deal of new ways
to do things to get started).


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


You would normally not construct until you have some initialisation, C++
is unforgiving performance wise if you do.


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


Yes, my statement above can be used as part of an argument for not using
global static objects.


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


Yes, this is dumb, extremely dumb - it has made lots of people misuse
them because they see it in the standard. I never liked that at all.
Fortunately, they are just for simple hacked together code and you don't
have to demean yourself by using them :)


> >because people who are that dumb are not usually capable of writing a
> >kernel ;)
>
> Who wrote MacOS or Windows 98 then? ;)

Sorry, let me correct myself "people who are that dumb are not usually
capable of writing a *good* kernel" ;)

--
Tristan Wibberley

Rainer Joswig

unread,
Aug 19, 1999, 3:00:00 AM8/19/99
to
In article <m34shxw...@pcrm.win.tue.nl>, Stephan Houben <ste...@pcrm.win.tue.nl> wrote:

> IIRC there was a C compiler for some Lisp machines. It implemented
> pointers with "cons"-cells.

Sure? The Lisp system had pointers (called Locatives) as a
primitive.

> A greater abstraction inversion the world
> has never seen.

Not really. Cons cells are in principle pointers. Two pointers
in one row. Actually on the Lisp machine they had tagged
data with CDR-coding for lists (-> cons cells).
This means a new list of, say, ten items is internally stored
as a consecutive array of ten pointers to items.

> Note that Linux is not a C OS. It is a general-purpose OS whose kernel
> happens to be written in C.

That's to bad.

> If they hadn't told me this, I would never know.
> I still don''t care. As long as the StephanTalk compiler does its job,
> I don't care in which language the OS is written.

A Lisp users says: I don't care what language the kernel
is written in, as long as it is Lisp.
The difference between a Lisp machine and a Linux
system is huge. The Lisp Machine has an open, incrementally
changeable and dynamic OS. The OS is written in a
pure OOP style. That means that things like
IP-Packets or Processes are objects. And operations
on them are implemented as methods.

Rainer Joswig

unread,
Aug 19, 1999, 3:00:00 AM8/19/99
to
In article <conu3.10933$gO1.3...@news2.giganews.com>, cbbr...@hex.net wrote:

> The founding of Symbolics and Lisp Machines has a great deal to do
> with the founding of the Free Software Foundation... I do not recall
> offhand which company of the two RMS considered the "bad guys," but
> there was much bad blood at the time...

It was Symbolics.

Stephan Houben

unread,
Aug 19, 1999, 3:00:00 AM8/19/99
to
jos...@lavielle.com (Rainer Joswig) writes:


> A Lisp users says: I don't care what language the kernel
> is written in, as long as it is Lisp.

IMHO, a supposedly "general purpose OS" should do more than
just please the Lisp users. (Any estimates of the precentage
of the programming community which consider themselves
Lisp users?)

> The difference between a Lisp machine and a Linux
> system is huge. The Lisp Machine has an open, incrementally
> changeable and dynamic OS. The OS is written in a
> pure OOP style. That means that things like
> IP-Packets or Processes are objects. And operations
> on them are implemented as methods.

But all this could be provided by a Lisp library which interfaces
with the underlying OS. Have the Linux kernel start up a Lisp
interpreter directly after booting and presto: your Lisp OS is
ready to run. You can then write a GUI or whatever in Lisp and
have *that* executed on startup.

Of course, the advantage that this gives you from just running
a Lisp interpreter from the shell is debatable. At least, you can
pretend you're not using Linux...

Now I think of it, there's also a C++ interpreter floating around
somewhere. So the same technique could be used to create a "C++ OS",
thereby answering the question of the original poster.

(And a Java OS, and a Perl OS, and a... Python OS. Mmm, perhaps
this is a cool idea after all.)

Greetings,

Stephan

kw...@hoser.dsl.xmission.com

unread,
Aug 19, 1999, 3:00:00 AM8/19/99
to
Cocheese <coch...@hotmail.com> writes:


Troll.

> The downside is "linux has always been a C based Program so it will always
> be."
>

> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***

No, not necessarily. You've been suckered by market hype.

Kurt
--
Arnold's Laws of Documentation:
(1) If it should exist, it doesn't.
(2) If it does exist, it's out of date.
(3) Only documentation for useless programs transcends the first two laws.

Johan Kullstam

unread,
Aug 19, 1999, 3:00:00 AM8/19/99
to
Stephan Houben <ste...@pcrm.win.tue.nl> writes:

> jos...@lavielle.com (Rainer Joswig) writes:
>
>
> > A Lisp users says: I don't care what language the kernel
> > is written in, as long as it is Lisp.
>
> IMHO, a supposedly "general purpose OS" should do more than
> just please the Lisp users. (Any estimates of the precentage
> of the programming community which consider themselves
> Lisp users?)

popularity means nothing. look how many windows users there are.
compare it to the number of linux users. is windows all that great?
does linux suck so much?

lisp isn't good for everything, but it is a good language for
designing a GUI. imho C++ is awful for this task. but what is
everyone using? the bandwagon effect doesn't select for quality.

> > The difference between a Lisp machine and a Linux
> > system is huge. The Lisp Machine has an open, incrementally
> > changeable and dynamic OS. The OS is written in a
> > pure OOP style. That means that things like
> > IP-Packets or Processes are objects. And operations
> > on them are implemented as methods.
>
> But all this could be provided by a Lisp library which interfaces
> with the underlying OS. Have the Linux kernel start up a Lisp
> interpreter directly after booting and presto: your Lisp OS is
> ready to run. You can then write a GUI or whatever in Lisp and
> have *that* executed on startup.

try to use linux without a libc. everything in linux goes to support
a C environment. static compile languages such as pascal or fortran
do well on unix. dynamic languages such as lisp do less well. this
is because a lisp environment has aspirations of being an operating
system itself and the kernel/app domains overlap.

the kernel of a lisp oriented box could be written in another language
than lisp such as C. however, it would offer a different set of
interfaces and services than unix. what lisp needs from its kernel is
different from what a C program needs.

> Of course, the advantage that this gives you from just running
> a Lisp interpreter from the shell is debatable. At least, you can
> pretend you're not using Linux...

as far as i understand it, it is a world of difference. a lisp isn't
some kind of scripting application. it's nearly a full blow operating
system with compiler, memory management, subprocesses &c. look at
emacs. emacs isn't great lisp, but it sure wants to take over the
world.

--
johan kullstam

Rainer Joswig

unread,
Aug 19, 1999, 3:00:00 AM8/19/99
to
In article <m3emh01...@pcrm.win.tue.nl>, Stephan Houben <ste...@pcrm.win.tue.nl> wrote:

> jos...@lavielle.com (Rainer Joswig) writes:
>
>
> > A Lisp users says: I don't care what language the kernel
> > is written in, as long as it is Lisp.
>
> IMHO, a supposedly "general purpose OS" should do more than
> just please the Lisp users. (Any estimates of the precentage
> of the programming community which consider themselves
> Lisp users?)

Sure, you could use Pascal, C, Prolog, Ada and Fortran
on a Lisp Machine. What was your point?


> > The difference between a Lisp machine and a Linux
> > system is huge. The Lisp Machine has an open, incrementally
> > changeable and dynamic OS. The OS is written in a
> > pure OOP style. That means that things like
> > IP-Packets or Processes are objects. And operations
> > on them are implemented as methods.
>
> But all this could be provided by a Lisp library which interfaces
> with the underlying OS.

Unfortunately the underlying OS then is written in a
low-level langauge. You won't get the dynamic behaviour.
You won't get the expressivity of Lisp. You won't
get the object-oriented structuring, ...

> Have the Linux kernel start up a Lisp
> interpreter

Btw., although the Lisp machine had an interpreter, the
interpreter was only used during development. All
the code was/is compiled to native code. Today's
Lisp systems have optimizing native code compilers
to the usual RISC or CISC chips.

> directly after booting and presto: your Lisp OS is
> ready to run. You can then write a GUI or whatever in Lisp and
> have *that* executed on startup.

Yeah, but the OS is not written in Lisp - this is a big difference.



> Of course, the advantage that this gives you from just running
> a Lisp interpreter from the shell is debatable. At least, you can
> pretend you're not using Linux...

I have that today. But on my Lisp machine I type
Edit Definition process:timer
and I'm editing the source code for timed processes.
I can write subclasses of that with different behaviours,
etc. There is nothing between my classes and the
hardware. The Lisp Machine is basically a huge
object machine.

> Now I think of it, there's also a C++ interpreter floating around
> somewhere. So the same technique could be used to create a "C++ OS",
> thereby answering the question of the original poster.

The point of a Lisp OS is not to have an interpreter. I'm
a Lisp developer and I have never had that much
need to use an interpreter in the last ten years. Instead
all my code is incrementally compiled.

A Lisp system is the ultimate in dynamic changeability
and debuggability. Unless you have **live** debugged stuff
like NFS mounts, you won't hardly understand what
this stuff is about. It is the ultimate hacker's machine.
All code a keypress away, tools tightly integrated,
excellent integrated documentation facilities, not the multitude of
stupid scripting languages, a real graphical and
mousable command interpreter, reusable OS facilities,
on the fly compilation, on the fly updating of change
objects, ...

Stephan Houben

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to
jos...@lavielle.com (Rainer Joswig) writes:

OK, you have me convinced. I want it.

Is anyone working on a new Lisp OS nowadays?

Greetings,

Stephan

David Schwartz

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to

Cocheese wrote:

> Again I admit it would take a little extra work and put a minor set
>
> back in the evolution for a month or 2, but if C++ is so much faster,
>
> easier, and stable- WHY NOT?

C++ may have some advantages over C, but "faster", "easier" and
"stabler" are NOT them!

DS

David Schwartz

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to

Phil Howard wrote:
>
> On Mon, 16 Aug 1999 19:56:20 -0700 Randall Parker (rgpa...@west.net) wrote:
> | I think the real problem with C++ and heap memory is that too many
> | programmers who use C++ do not understand how much all the stuff they are
> | writing is fragmenting the heap.
>
> Of course. They tend to be abstraction oriented applications programmers.
> Details? We don't need no steenkin details! :-)

This is the penalty you take everytime your language takes you further
from the hardware.

I remember way back in my microcontroller days, dealing with a chip
that had no hardware capability to do signed arithmetic. So when people
had:

int i;
for(i=0; i<10; i++) { something(i); }

I changed it to:

unsigned int i;
for(i=0; i<10; i++) { something(i); }

And things got much faster. Then I remembered that the chip had a
'decrement and jump if not zero' instruction. So we next went to:

unsigned int i;
for(i=10; i!=0; i--) { something(i); }

And things got much faster again.

You always have to look at what your code is making the machine
actually _do_.

DS

Christopher B. Browne

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to
On 20 Aug 1999 08:59:59 +0200, Stephan Houben
<ste...@pcrm.win.tue.nl> posted:
>OK, you have me convinced. I want it.
>
>Is anyone working on a new Lisp OS nowadays?

See: <http://www.hex.net/~cbbrowne/lisposes.html> for links to several
projects.

It's not clear which, if any, will get sufficiently developed as to be
of real interest...

--
"Note that if I can get you to `su and say' something just by asking,
you have a very serious security problem on your system and you should
look into it." -- Paul Vixie, vixie-cron 3.0.1 installation notes
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

Paul D. Smith

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to
%% David Schwartz <dav...@webmaster.com> writes:

ds> I remember way back in my microcontroller days, dealing with a chip
ds> that had no hardware capability to do signed arithmetic. So when people
ds> had:

ds> int i;
ds> for(i=0; i<10; i++) { something(i); }

ds> I changed it to:

ds> unsigned int i;
ds> for(i=0; i<10; i++) { something(i); }

ds> And things got much faster. Then I remembered that the chip had a
ds> 'decrement and jump if not zero' instruction. So we next went to:

ds> unsigned int i;
ds> for(i=10; i!=0; i--) { something(i); }

ds> And things got much faster again.

Of course, these two loops aren't equivalent.

ds> You always have to look at what your code is making the machine
ds> actually _do_.

MHO: optimizations for specific hardware should be the responsibility of
the compiler and, given that you're interested in writing general,
portable code and not device drivers, etc. the programmer should not
bother to concern him/herself with them.

I never look at what my code is making the machine actually do when
writing C, since I write code that runs on many platforms and that kind
of optimization in C is useless (or worse) in the large.

If I care that much about what the machine is actually doing, well,
that's what the asm statement is for, right?

--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Randall Parker

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to
It is not a concocted problem.

I've run into this sort of situation when dealing with writing interfaces
to a set of embedded devices which each had slightly different ways of
formatting their packets for serial communication.

I solved the problem by declaring pointers to functions where each
function had a different way of formatting output or of interpreting
input. I could make up a description for how to communicate to a
particular embedded device by selecting a set of pointers that together
worked with that device.

I've run into this kind of situation in other problem domains as well.

Lots of people solve it by putting in lots of flags and conditions within
code that gets executed so that in every pass thru the code the
particular way of doing each step has to be selected for every time thru.

Well, I don't like testing flags more often than necessary. It strikes me
as wasteful. Also, each routine that does get executed ends up being
bigger than it needs to be and more code has to be loaded into cache.
I've worked with embedded devices where the CPU had a large L1 cache and
all external RAM had many wait states on it. In those cases the ability
to make things small enough to fit in cache pays big dividends in
performance.

In article <slrn7rj3bh...@rcde02.ahpcc.unm.edu>,
rs...@news.arc.unm.edu says...
>
> 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?
>
>
>

Randall Parker

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to
In article <p53dxed...@baynetworks.com>, psm...@baynetworks.com
says...

> MHO: optimizations for specific hardware should be the responsibility of
> the compiler

But if the compiler doesn't do the optimization the result is slower
code.

If, for instance, you don't need ii to go from 0 to 9 and it is just as
easy to count down then it makes sense to code your for loops that way.
Almost all processor instruction sets have a decrement and test for 0 and
by doing the decrement to 0 you may avoid the reloading of the boundary
test value at the bottom of pass thru a big loop. I fail to see how such
an optimization is going to slow it down for some processors so why not
make it a standard practice?

I've been faced with situations where my choice was either write it in
assembly to make it fast enough or write very careful C to make it fast
enough. Well, I chose the latter.

One of the advantages of your coding carefully in C is that you rarely
will thereby write code that an optimizer will make go slower and usually
even when using an optimizing compiler the code will be faster than code
written with less thought of the fact that underlying hardware will
execute it.

>and, given that you're interested in writing general,
> portable code and not device drivers, etc. the programmer should not
> bother to concern him/herself with them.

Most C optimizations are not specific to a particular processor
architecture. Most of those that are are not, as a result, going to be
slower when later compiled for a different processor architecture.

However, the fact is that if you are writing in C and you do not
consciously code for a particular processor architecture your style may
accidentally lend itself to one processor architecture over another.

For instance, some processor architectures can shift left faster than
shifting right (or maybe I have that backward). So if you do your
shifting always one way you are writing your code to be faster or slower
for a particular processor architecture whether you are aware of this or
not.

> I never look at what my code is making the machine actually do when
> writing C, since I write code that runs on many platforms and that kind
> of optimization in C is useless (or worse) in the large.

You ought to start looking at the generated assembly on a couple of
different architectures and see whether your carefree attitude isn't
consistently costing you performance loss unnecessarily.

> If I care that much about what the machine is actually doing, well,
> that's what the asm statement is for, right?

If you care enough about what the machine is doing you can code C better
so that the resort ot asm can happen less often.

Paul D. Smith

unread,
Aug 20, 1999, 3:00:00 AM8/20/99
to
%% rgpa...@west.net (Randall Parker) writes:

rp> But if the compiler doesn't do the optimization the result is
rp> slower code.

Yes. Until the compiler is improved, etc.

Either way, except in very specific circumstances where the code _must_
be as fast as possible (drivers, very busy daemons, etc.) and I know
that this is what's slowing it down (see below) it's simply not worth
my effort to worry about it.

rp> For instance, some processor architectures can shift left faster
rp> than shifting right (or maybe I have that backward). So if you do
rp> your shifting always one way you are writing your code to be
rp> faster or slower for a particular processor architecture whether
rp> you are aware of this or not.

Exactly my point. In widely ported and portable code, these kinds of
things are unknowable and, in general, not very interesting as
efficiency increases anyway.

It's a rare, and probably pretty specialized, program that will see any
significant benefit by having its loops count down rather than up.

rp> You ought to start looking at the generated assembly on a couple
rp> of different architectures and see whether your carefree attitude
rp> isn't consistently costing you performance loss unnecessarily.

No thanks. I have much better things to do than compare the output of
Sun's compiler vs AIX's compiler vs. HP's compiler vs. Greenhill's
compiler vs. GCC on each of those platforms, etc. etc. worrying about
these kinds of optimization issues. I'm sure the results will just as
often as not be contradictory anyway.

As I mentioned above, it's a rare program where micro-optimizations like
this will even be noticeable. The vast majority of slow code is due to
algorithm design issues or other kinds of latency.

You should read the famous whitepaper "News Need Not Be Slow", by Geoff
Collyer and Henry Spencer. There're a lot of good nuggets for practical
and results-oriented optimization in there.

ftp://ftp.cs.toronto.edu/doc/programming/c-news.ps

I'm not saying that adopting habits that are more likely to lead to
efficient code is bad (I decrement where possible, and I also use lots
of temporary pointer variables instead of int indices, for example). I'm
just saying it's very likely not worth going back and re-editing code on
a whim.

Noah Roberts (jik-)

unread,
Aug 20, 1999, 3:00:00 AM8/20/99