lkml.org 
[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Object Oriented Linux
On Fri, 14 Jul 2000, Pavel Machek wrote:

> Hi!
>
> > > inline void *operator new(size_t size)
> > > {
> > > return kmalloc(size);
> > > }
> >
> > Yes? Care to compile that? FYI, kmalloc() has _two_ arguments. And no, I'm
> > not being pedantic - choice of the second argument matters. Big way. C++
> > has a notion of "allocation", but kernel has not. What it has is "atomic
> > allocation", "dma-suitable allocation", etc. Choosing the right one is
> > _not_ a task for compiler - it's AI-complete. Always forcing atomic is not
> > an option, BTW - performance hit will be too serious.

Wrong. You can supply special allocators to the STL routines, such as the
map<>, list<>, etc. etc. and you can supply one allocator for each instantiation
of such a template.

If your data structure must have objects that are allocated with GFP_DMA, then
the type system will even guarantee you that this happens consistently wherever
you allocate. Failing to do so would be a type error, a compile-time error.

>
> I already see this ugglyness:
>
> n_tty.c: get_zeroed_page(in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
>
> so C++ would not make it much worse.

You could(/would?) write the same in C++. But nevermind that for now.

Putting C++ in the kernel because of object orientation makes little sense to
me. C can be pretty object-oriented. You will see that a data block travelling
thru the block I/O layer is already an ``object'', holding data and parameters
as well as ``virtual methods'' (function pointers) to the lower-level I/O
routines required for that specific block. The kernel is object oriented
today.

C++ could make sense from other points of view. It could be convenient to have
parameterized types, default arguments, better type-safety in the generic data
structure routines, proper constructors and destructors that are guaranteed to
be called, etc. etc...

Thinking of C++ as merely ``object oriented C'' doesn't do C++ justice. And
IMO it makes little sense to talk about making the kernel more object oriented,
as it seems it is already object oriented to the point where it makes sense.

C++ is more dangerous than C, from a performance point of view. It makes it
easier to safely inline routines (using template functions instead of macros),
but it also makes it easier to get massive code bloat. You can become a good C
programmer in a number of months, you cannot become a good C++ programmer in a
year. If you think you can, you're either a genius or you don't know C++.

You can get more efficient code in pretty C++ than you can in pretty C. C++
doesn't have to have a run-time overhead, and in turn it can do optimizations a
C compiler cannot because of the differences in the type system. So properly
written C++ can be slightly faster than properly written C, in most larger
programs. But poorly written C++ will usually give you much worse performance
than poorly written C. And it is much easier to write poor C++ than it is to
write poor C, from a performance point of view.

In short: C++ gives you enough rope to shoot you in the feet. But if you do
so, it will usually blow off both your legs clean.

--
................................................................
: jakob@ostenfeld.dtu.dk : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.741 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site