写操作系统内核还是用c好，c++的特性太多，以至于不容易控制。这确实是一个问题，但是并不标明c++是失败的，呵呵。
虽然不适合写操作系统内核，但是写一些其他的程序还是可以的。但是，我个人感觉如果是写系统级别的程序而且偏重于算法，那么c确实比
c++简单。
个人使用的偏向还是c语言，然后才是c++。
c++并不是万能的，而且编译器的标准也不同。而c语言至少c89已经定型很长时间了，而且还不错。所以就语言来说c语言更加适合写操作系统的内核。而c++可以做一些api的封装或高一层次的应用。例如：mfc的应用，这是和成功的。
但是随着时间的推移，以及c++编译器和标准的完善与推广，c++也将成为芯片级开发的利器。但是他的简单性永远不会超过C语言。这也是c语言经久不衰的原因。例如：在一个8位的单片机中，如果用c++和c语言比较，c++的额外的东西实在太多了，而c语言却可以在保证简单性的情况下，达到汇编语言的效果。道理一看就明白。也怪不得linux之父的观点。下面是copy的原文，大家看看。回头有时间精解一下。
下面是原文：
anon2 (anon@anons.com) on 6/8/10 wrote:>>But productivity is a difference thing when it comes to>kernel code. Linux devs are working practically for free.>So the same amount of budget can get you whole lot work>done.
Actually, this is wrong.
People working for free still doesn’t mean that it’s fineto make the work take more effort – people still work forother compensation, and not feeling excessivelyfrustrated about the tools (including language) and gettingproductive work done is a big issue.
So if a language change were to make people much moreproductive, that would be a good thing regardless of howmuch people end up getting paid. It’s definitely not aboutthe money.
But the thing is, “lines of code” isn’t even remotely closeto being a measure of productivity, or even the gatingissue. The gating issue in any large project is pretty muchall about (a) getting the top people and (b) communication.
In the kernel, we have roughly a thousand people beingattributed for each and every kernel release (atabout three months apart). Now, there’s a long tail, andthe hundred (or even fifty) top contributors do most ofthe bulk work, but even then, the biggest issue that I endup worrying about is not even the code, but the “flow” ofcode and development.
For example, I personally don’t even write much code anymore, and haven’t for years. I mainly merge (and to alarge degree – don’t merge: a large portion of whatI do is telling people “No, I won’t take this, because ofxyz”. Even if rejection ends up being the rare case, it’sactually the main reason for me existing. Anybody can say”yes”. Somebody needs to say “no”).
And the best way to make things work is to not needto communicate at all. It’s exactly the same issue as inparallel programming – any communication inevitably is themain bottleneck.
And the best way to avoid communication is to have some”culture” – which is just another way to say “collection ofrules that don’t even need to be written down/spoken, sincepeople are aware of it”. Sure, we obviously have a lot ofdocumentation about how things are supposed to be done,but exactly as with any regular human culture, documentationis kind of secondary.
(Put another way: there are lots of books about culture,and you can get a PhD in anthropology and spend all yourlife just studying it – but for 99% of all people, youdon’t read a book about your culture, you learn it bybeing part of the community).
And there is a very strong “culture” of C (and UNIX, forthat matter). And this is also where it’s so important forthe language to be simple and unambiguous. One of theabsolute worst features of C++ is how it makes alot of things so context-dependent – which just meansthat when you look at the code, a local view simply seldomgives enough context to know what is going on.
That is a huge problem for communication. It immediatelymakes it much harder to describe things, because you haveto give a much bigger context. It’s one big reason why Idetest things like overloading – not only can you not grepfor things, but it makes it much harder to see what asnippet of code really does.
Put another way: when you communicate in fragments (think”patches”), it’s always better to see “sctp_connect()”than to see just “connect()” where some unseen context iswhat makes the compiler know that it is in the sctp module.
And you have to communicate in fragments in orderto communicate efficiently. And I don’t mean “efficiently”as in network bandwidth – I mean as in “in general”. Thereason we use patches instead of sending the whole project(or even just a couple of whole files) around is not becauseit’s denser in email – it’s because the only thing thatmatters is the change, not the end result.
So that is a very fundamental reason for development toavoid ambiguity and context. And that, btw, has absolutelynothing to do particularly with “kernel programming”. It’strue in general in any sw project, but it’s true in reallife too: speaking or writing ambiguously is not good innormal human communication either.
So a simple and clear language is a good thing. You don’twant to be unnecessarily verbose (meaningless syntacticfluff is always bad), but at the same time you do not wantto require too much context either.
[ Lots of implicit context is fine if everybody is anexpert on the subject. Which is why really esotericscientific literature is basically unreadable unlessyou’re an expert – it requires huge amounts of contextto make sense at all. But that is simply not possiblein a large project that has many different areas.
For example, I know the VM and core kernel really well,but I still need to be able to read the code of variousfilesystems and networking code. So even for somebodylike me, the code needs to be written without hiddencontext. ]
And C is a largely context-free language. When you see aC expression, you know what it does. A function call doesone thing, and one thing only – there will not be somesubtle issue about “which version” of a function it calls.
Of course, you can use the preprocessor and inline functionsto do that, but even then you have to be pretty explicit:you can still grep for that preprocessor symbol, and it’sall pretty “direct”.
Now, in other situations you do want more language support,and you do want the language to do memory allocation etcfor you (ie GC – I’m not talking about that idiotic“new” keyword in C++, or other crap). In the kernel, wecouldn’t do that anyway. Similarly, in the kernel, we doreally require very specialized locking and direct controlover memory ordering etc, so a language that exposes somemodel of concurrency would almost certainly be too limitedin that concurrency too.
So there are particular reasons why I think C is “as simpleas possible, but no simpler” for the particular case of anOS kernel, or system programming in particular. That’s whyI’m absolutely not saying that you should use C for allprojects.
But C++? I really don’t think the “good features” of itare very good at all. If you leave C behind, do it properlyand get some real features that matter. GC, someconcurrency support, dynamic code generation, whatever.
Linus
木已成舟便要顺其自然
