为什么Linux内核不使用C++开发
2009-11-10 20:27
519 查看
原文链接:http://www.kernel.org/pub/linux/docs/lkml/
(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:
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.(面向对象编程的要点是使用面向对象技术(编程思想),而不是使用的语言)
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.
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.
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.
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: *Linus的观点*:
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:
the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
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
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
(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:
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.(面向对象编程的要点是使用面向对象技术(编程思想),而不是使用的语言)
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.
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.
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.
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: *Linus的观点*:
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:
the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
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
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
相关文章推荐
- 为什么Android开发使用Java而不是C++?
- 为什么Android系统需要使用C、C++和Java语言共同开发
- Linux内核的创始人Linus Torvalds 说明了内核开发需要使用C语言而非C++的理由
- 为什么游戏引擎大多选择使用 C++ 而不是 C 开发?
- 为什么Android系统需要使用C、C++和Java语言共同开发
- 为什么Android开发使用Java而不是C++?
- 彻底告别Linux下没有C/C++好用 IDE 的时代———— 在 Fedora 9 下 使用 CodeBlocks 开发!
- 巧妙使用offsetof宏定义,在c,c++开发中解决问题
- 介绍几个C++开发人员常使用的小工具
- ubuntu下使用Eclipse搭建C++开发环境
- 使用wxWidgets进行跨平台的C++开发
- 【C/C++开发】C++之enum枚举量声明、定义、使用与枚举类详解与枚举类前置类型声明
- ios定位开发 当使用百度地图sdk没有启用object c++混编时就会出现如下错误
- LinuxC/C++编程基础(22) 使用thrift/rpc开发简单实例
- C++中为什么使用bool类型
- 为什么35岁的C++在“真实”开发中仍占主导
- Eclipse开发C/C++之使用技巧小结,写给新手
- Linux下使用Eclipse开发C\C++
- C++ 实现多语言程序开发研究与Xtreme ToolkitPro的使用(三)