Alternative to C for system programming

[Richard Tobin]

2) The OO paradigm is not adapted to OS writing, but an event
oriented program looks more promising... as it is now.

Many parts of an OS are well-suited to an object-oriented approach,
and many OSes written in C use that approach. For example, many
operating systems have a structure for device drivers that contains
pointers to functions for read, write, close, and so on. This would
be very naturally done by subclassing an abstract driver class that
had no-op methods for everything.

-- Richard

 

[Richard Tobin]

1) C can use a garbage collector without any trouble. See
http://www.cs.virginia.edu/~lcc-win32

[/QUOTE]

You mean without any trouble if you do not do the things which break
under GC and you can afford the unpredictable overheads of GC as has
been pointed out before. If you are willing to live with those issues
then you can use a 3rd party extension to do GC, but then you are
writing in C+GC not in C (although much of the code might be C).

Ah, so you admit you cannot use GC without any problems having just
stated you can.

You seem to be deliberately looking for something to complain about here.

Jacob made the perfectly reasonable (though disputable) point that the
problem for GC is not the language (C) but the application (an OS). Just
because he spread it out over two paragraphs doesn't mean you should
pretend he got it wrong and then admitted it.

-- Richard

 

[Kenny McCormack]

You [Flesh Gordon, ed.] seem to be deliberately looking for something
to complain about here.

And, in other news, water is wet and the sun rises in the east.

 

[CBFalconer]

Look at the Singular project at Microsoft.
http://research.microsoft.com/os/singularity/
They are building an OS from square 1 using C# and a bit of C.
Most of the OS is written in C#.

Since they don't know how to build an OS with real tools (see links
below) think how much better they can foul up with tools written in
an unstandardized and untested by time language.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Ian Collins]

Ian Collins a écrit :

Surely not ideal

1) Exception handling in the kernel is a NO-NO... Many programs
in C++ rely on that however.

As Marc said, many C programs rely on malloc, but kernels are still
written in C.

2) The OO paradigm is not adapted to OS writing, but an event
oriented program looks more promising... as it is now.

It's ideally suited to many aspects of kernel and driver writing.

3) The performance of C++ is not better than C, and mostly
worst. In an OS context this is not really a plus

Care to provide an example?

 

[Christopher Layne]

Garbage collected? Why?

I just laugh at the constant string of posters that blast C for this and
that, including lack of automatic memory allocation and/or garbage
collection and/or array bounds checking.

Generation Y/Z --> "Why can't I be lazy?"

 

[William Ahern]

Many parts of an OS are well-suited to an object-oriented approach,
and many OSes written in C use that approach. For example, many
operating systems have a structure for device drivers that contains
pointers to functions for read, write, close, and so on. This would
be very naturally done by subclassing an abstract driver class that
had no-op methods for everything.

Interestingly enough, they manage to do exactly this without using C++.
You can "derive" class interfaces by nesting structures. There are also
some macros, like container_of, provided as part of the kernel
headers which assist such techniques.

There are some things which C++ may, arguably, improve the expressiveness
of. But not enough, or in regard to the most important aspects, to
convince that community to use C++. And even the most bare-bones C++'ish
implementation carries more baggage than they want.

 

[jacob.navia]

Richard Tobin a écrit :

You seem to be deliberately looking for something to complain about here.

He always "comments" my posts. I wouldn't give it any importance.

 

[Chris Thomasson]

Well, 90% agreed here... However...

Untrue, C++ does just as good a job.

Supporting exceptions in the bootloader and in the early kernel environments
can be a bit annoying. But hey, who said you have to use exceptiong anyway!
So, yeah I could use C++ and an assembler for all of that stuff...

:^)

 

[Serve Laurijssen]

Interestingly enough, they manage to do exactly this without using C++.
You can "derive" class interfaces by nesting structures. There are also
some macros, like container_of, provided as part of the kernel
headers which assist such techniques.

There are some things which C++ may, arguably, improve the expressiveness
of. But not enough, or in regard to the most important aspects, to
convince that community to use C++. And even the most bare-bones C++'ish
implementation carries more baggage than they want.

funny, I read the first paragraph and already had the second paragraph in my
head when I started reading it
Indeed, C++ would improve the expressiveness by just having virtual
functions in a class etc, in C you have to code that mechanism yourself. But
its not that often you need it and the C expressiveness is good enough.

It's quite interesting to see how the usual FILE I/O is implemented in a C
library and how the different functionalities are overridden for serial
output, file output etc

 

[Serve Laurijssen]

You mean without any trouble if you do not do the things which break under
GC and you can afford the unpredictable overheads of GC as has been
pointed out before. If you are willing to live with those issues then you
can use a 3rd party extension to do GC, but then you are writing in C+GC
not in C (although much of the code might be C).

Thats the beauty of C, you have the choice.
If you have a system where you can get away with GC and having correct
programs delivered on time is more important than portability and efficiency
why not use it.
If you have a system where GC makes the system too slow to be usable then
dont use it!