《我是大侦探》首播 “头脑的演技”震撼荧屏
From: | Linus Torvalds <torvalds-AT-linux-foundation.org> | |
To: | Dmitry Kakurin <dmitry.kakurin-AT-gmail.com> | |
Subject: | Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. | |
Date: | Thu, 6 Sep 2007 18:50:28 +0100 (BST) | |
Message-ID: | <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org> | |
Cc: | Matthieu Moy <Matthieu.Moy-AT-imag.fr>, Git <git-AT-vger.kernel.org> | |
Archive‑link: | Article |
On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > When I first looked at Git source code two things struck me as odd: > 1. Pure C as opposed to C++. No idea why. Please don't talk about portability, > it's BS. *YOU* are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with. C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap. So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage. If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess. But I'm sure you'd like it more than git. Linus
Posted Dec 17, 2008 19:21 UTC (Wed)
by Solifugus (guest, #55639)
[Link] (1 responses)
The promise of class hierarchies making development faster and easier with more code reuse came as a double-edged sword. Not only does every class you make create a lot of overhead to manage (in the underlying machine code) but the common practice of requiring and returning complex objects from methods can requires a Ph.D in any library you want to use. And although the STL has safeguards greatly eliminating buffer overflows (common in C), it's very inflexible. Unless you are doing very simple coding, it can be more complex than recursive layers of pointers.
I spent a lot of time learning C++ only to learn that for every good idea, there were 10 bad ones. Theory ignores a lot of reality.
I do, however, think that C++ libraries can be well designed. This usually involves using a lot fewer C++ features but it isn't all bad. References, for example. Classes and instantiation, used minimally with only a basic set of data types passed in and out of methods can be very efficient at performance, memory footprint, and ease of learning/understanding/debugging. Sadly, this ideal is rarely the case.
Even making good use of C++ (which is rare), I think C is better for kernels and C++ better for desktop systems. With kernels, you are working damn close to bare metal and with desktop systems, you are working on a higher level and need to work with much larger scale philosophies in design.
Matthew
Posted Dec 19, 2008 13:53 UTC (Fri)
by Flameeyes (subscriber, #51238)
[Link]
Since virtual classes require you to use vtables, those will always get in the way of reducing to a minimum the Copy-on-Write memory waste of your software, the amount of symbols to bind increase tremendously, and you probably have to sacrifice most of the builtins from the compiler.
The result is that C++ code can be very inefficient for fire-and-forget tools, like git is. For higher level software (like KDE) they might not be noticeable, but Linus is right in his reasoning.
Posted Jan 14, 2009 23:41 UTC (Wed)
by vomlehn (guest, #45588)
[Link]
Another example that is quite common: the use of function pointers is frequently accomplishing the exact same goal as having derived objects, but less cleanly. It also limits the ability of the compiler to optimize cases where the actual function is known, and therefore could be inlined or even eliminated entirely.
Does that mean that C++ is the answer? No. And, in spite of having actually used a number of other languages for real world projects, I don't know of anything better. I do think, however, that Linux is out-growing C and that we have an opportunity and a need to figure out something better.
[Answer to the exercise: See the macro BUFFER_FNS in include/linux/buffer_head.h]
Posted Jan 15, 2009 6:15 UTC (Thu)
by charris (guest, #13263)
[Link]
I think this is a valid point. Trying to reuse bits of code from a project that has been extensively designed around an object hierarchy is a pain and requires tearing things apart and a lot of recoding. Some code isn't meant to be reused outside of the original project, desktops may be an instance of this. But suites of algorithms should be designed so that the individual parts are easily separated from the whole.
Posted Oct 18, 2009 17:09 UTC (Sun)
by jafl (guest, #36401)
[Link]
Posted Nov 4, 2010 10:44 UTC (Thu)
by PierreG (guest, #71005)
[Link] (1 responses)
I wrote G-WAN, a 160 KB Web app. server with ANSI C scripts.
Compared to G-WAN, the BOOST C++ library is bloated, slow and its code is promoting obscurity to new heights.
That's probably for a reason:
"Within C++, there is a much smaller and cleaner language struggling to get out"
Posted Oct 22, 2018 4:02 UTC (Mon)
by Sir_Dogoven (guest, #128065)
[Link]
Mostly but not totally agree..
Mostly but not totally agree..
Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
G-WAN is (by far) faster than anything else ever published (in user-mode or in the kernel).
(Bjarne Stroustrup, proud MICROSOFT Windows user)
Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.