Messages in this thread |  | | Date | Mon, 16 Oct 2000 04:35:32 +0300 | From | Eray Ozkural <> | Subject | Re: [Criticism] On the discussion about C++ modules |
| |
"Jeff V. Merkey" wrote: > > The [new] and constructor/destructor operations create hidden memory > allocations in C++ that can blow performance in kernel "fast paths".
That is designed to decrease the number of syscalls, not to increase them. Besides, in a successful C++ design memory allocation would be encapsulated in allocator classes as in the C++ standard library. It lets you manage the memory the way you want it, specify in an abstract way and yet achieve this with efficiency. For example, I'd written a very simple & efficient allocator that did only a single big alloc and free for a graph partitioning program. SGI's STL Programmer's Guide has some documentation on allocators at URI http://www.sgi.com/Technology/STL/ . The thing is memory management is something beginner programmers have difficulty with in every language. [Of course, you don't have to use allocator classes. You can do it any way you'd like. It'd be better, though.] Default STL allocators are quite efficient, and may be used generally. The good part is that containers don't try to handle locks by themselves.
> Writing kernel code in C++ is never a good idea because of this problem, > and the fact that with function overloading, it's possible for someone > to write code that is so difficult to follow, it's unmaintainable.
As I said, I don't think it's a C++ specific problem. A lot of C programs suffer from bad memory and I/O code, too.
Function/Operator overloading does give inexperienced programmers the opportunity to create semantic traps. It should be used when it is required. If the function overloading is used so that semantic similarity is preserved, it has its affordances. A similar argument goes for operator overloading.
After all, an inexperienced programmer wouldn't be able to write a maintainable kernel module in C | C++.
> MS > wrote a large portion of W2K in C++, which is one reason it's hard to > debug, and slow. C++ also puts in jump tables with mangled names, and > is very difficult to debug at the assembler level.
Which jump tables do you refer to? Those [vtables] come into play only when you use virtual function calls, which must be used for high-level functions. You can write a kernel module without using any. C++ doesn't require you to employ polymorphism.
Windows isn't bad because it's [largely] written in C++. It's bad because it's written by MS. ;) Do you think it would be better if they didn't use C++?
[BTW, let's not associate C++ with proprietary software! :/ ]
Best Regards,
-- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: erayo@cs.bilkent.edu.tr www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |