Re: about DoublyLinkedList

Ingo Weinhold> 
>[...]
> Definitely. If it was up to me, I would root out the evil pure C code 
> and C 
> interfaces in the kernel completely. :-P
> 
+1 for me:)
also i found very interesting this, from my point of view, explain why 
we should:
Taken from: http://www.tux.org/lkml/#s15-3
[...]
# Why don't we rewrite the Linux kernel in C++?
conversation between  ADB: Andrew D. Balsa,  REW: Roger E. Wolff,
REG: Richard E. Gooch (FAQ maintainer)
    * (ADB) Again, this has to do with practical and theoretical 
reasons. On the practical side, when Linux got started gcc didn't have 
an efficient C++ implementation, and some people would argue that even 
today it doesn't. Also there are many more C programmers than C++ 
programmers around. On theoretical grounds, examples of OS's 
implemented in Object Oriented languages are rare (Java-OS and Oberon 
System 3 come to mind), and the advantages of this approach are not 
quite clear cut (for OS design, that is; for GUI implementation KDE is 
a good example that C++ beats plain C any day).
    * (REW) In the dark old days, in the time that most of you hadn't 
even heard of the word "Linux", the kernel was once modified to be 
compiled under g++. That lasted for a few revisions. People complained 
about the performance drop. It turned out that compiling a piece of C 
code with g++ would give you worse code. It shouldn't have made a 
difference, but it did. Been there, done that.
    * (REG) Today (Nov-2000), people claim that compiler technology has 
improved so that g++ is not longer a worse compiler than gcc, and so 
feel this issue should be revisited. In fact, there are five issues. 
These are:
          o Should the kernel use object-oriented programming 
techniques? Actually, it already does. The VFS (Virtual Filesystem 
Switch) is a prime example of object-oriented programming techniques. 
There are objects with public and private data, methods and 
inheritance. This just happens to be written in C. Another example of 
object-oriented programming is Xt (the X Intrinsics Toolkit), also 
written in C. What's important about object-oriented programming is the 
techniques, not the languages used.
          o Should the kernel be rewritten in C++? This is likely to be 
a very bad idea. It would require a very large amount of work to 
rewrite the kernel (it's a large piece of code). There is no point in 
just compiling the kernel with g++ and writing the odd function in C++, 
this would just result in a confusing mix of C and C++ code. Either the 
kernel is left in C, or it's all moved to C++.
            To justify the enormous effort in rewriting the kernel in C
++, significant gains would need to be demonstrated. The onus is 
clearly on whoever wants to push the rewrite to C++ to show such gains.
          o Is it a good idea to write a new driver in C++? The short 
answer is no, because there isn't any support for C++ drivers in the 
kernel.
          o Why not add a C++ interface layer to the kernel to support 
C++ drivers? The short answer is why bother, since there aren't any C++ 
drivers for Linux. However, if you are bold enough to consider writing 
a driver in C++ and a support layer, be aware that this is unlikely to 
be well received in the community. Most of the kernel developers are 
unconvinced of the merits of C++ in general, and consider C++ to 
generate bloated code. Also, it would result in a confusing mix of C 
and C++ code in the kernel. Any C++ code in the kernel would be a 
second-class citizen, as it would be ignored by most kernel developers 
when changes to internal interfaces are made. A C++ support layer would 
be frequently be broken by such changes (as whoever is making the 
changes would probably not bother fixing the C++ code to match), and 
thus would require a strong commitment from someone to regularly 
maintain it.
          o Can we make the kernel headers C++-friendly? This is the 
first step required for supporting C++ drivers, and on the face seems 
quite reasonable (it is not a C++ support layer). This has the problem 
that C++ reserves keywords which are valid variable or field names in C 
(such as private and new). Thus, C++ is not 100% backwards compatible 
with C. In effect, the C++ standards bodies would be dictating what 
variable names we're allowed to have. From past behaviour, the C++ 
standards people have not shown a commitment to 100% backwards 
compatibility. The fear is that C++ will continue to expand its claim 
on the namespace. This would generate an ongoing maintenance burden on 
the kernel developers.
            Note that someone once submitted a patch which performed 
this "cleaning up". It was ~250 kB in size, and was quite invasive. The 
patch did not generate much enthusiasm.
            Apparently, someone has had the temerity to label the above 
paragraph as "a bit fuddy". So Erik Mouw did a short back-of-the-
envelope calculation to show that searching the kernel sources for 
possible C++ keywords is a nightmare. Here is his calculation and 
comments (dates April, 2002):

            % find /usr/src/linux-2.4.19-pre3-rmap12h -name "*.[chS]" |
\
                xargs cat | wc -l
              4078662

            So there's over 4 million lines of kernel source. Let's 
assume 10% is
            comments, so there's about 3.6 million lines left. Each of 
those lines
            has to be checked for C++ keywords. Assume that you can do 
about 5
            seconds per line (very optimistic), work 24 hours per day, 
and 7 days
            a week:
                              5 s	  1 hour     1 day	  1 week
            3600000 lines * ------ * -------- * ---------- * -------- = 
29.8 weeks
                             line     3600 s     24 hours     7 days

            Sounds like a nightmare to me. You can automate large parts 
of this,
            but you'll need to write a *very* intelligent search-and-
replace tool
            for that. Better use that time in a more efficient way by 
learning C.

            Note that this is the time required to do a proper manual 
audit of the code. You could cheat and forgo the auditing process, and 
instead just compile with C++ and fix all compiler errors, figuring 
that the compiler can do most of the work. This would still be a major 
effort, and has the problem that there may be uses of some C++ keywords 
which don't generate a compiler error, but do generate unintended code. 
In other words, introduced bugs. That is not a risk the kernel 
development community is prepared to take.

      My personal view is that C++ has its merits, and makes object-
oriented programming easier. However, it is a more complex language and 
is less mature than C. The greatest danger with C++ is in fact its 
power. It seduces the programmer, making it much easier to write 
bloatware. The kernel is a critical piece of code, and must be lean and 
fast. We cannot afford bloat. I think it is fair to say that it takes 
more skill to write efficient C++ code than C code. Not every 
contributer to the linux kernel is an uber-guru, and thus will not know 
the various tricks and traps for producing efficient C++ code.
    * (REG) Finally, while Linus maintains the development kernel, he 
is the one who makes the final call. In case there are any doubts on 
what his opinion is, here is what he said in 2004:

      In fact, in Linux we did try C++ once already, back in 1992.

      It sucks. Trust me - writing kernel code in C++ is a BLOODY 
STUPID IDEA.

      The fact is, C++ compilers are not trustworthy. They were even 
worse in 1992, but some fundamental facts haven't changed:
          o the whole C++ exception handling thing is fundamentally 
broken. It's _especially_ broken for kernels.
          o any compiler or language that likes to hide things like 
memory allocations behind your back just isn't a good choice for a 
kernel.
          o you can write object-oriented code (useful for filesystems 
etc) in C, _without_ the crap that is C++.
      In general, I'd say that anybody who designs his kernel modules 
for C++ is either
          o (a) looking for problems
          o (b) a C++ bigot that can't see what he is writing is really 
just C anyway
          o (c) was given an assignment in CS class to do so.
      Feel free to make up (d).
[...]
-----------------------------------------------------------------------
-------------

Bye,
	Vasilis

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV