LWN: Comments on "Re: [RFC] Convert builin-mailinfo.c to use The Better String Library."

Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

PierreG — 2010-11-04T10:44:26+00:00

I wrote G-WAN, a 160 KB Web app. server with ANSI C scripts.
G-WAN is (by far) faster than anything else ever published (in user-mode or in the kernel).

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"
(Bjarne Stroustrup, proud MICROSOFT Windows user)

Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

jafl — 2009-10-18T17:09:43+00:00

I completely agree with the weed-out factor, and avoiding inefficient pass-by-value for objects requires fanatical dedication to using references. But I disagree with the claim about object models. Any time you define a struct and functions to operate on that struct, you have an object model. It's probably true that the object models in C tend to be much simpler than in C++, because C++ lets you go hog wild, but if two years down the road, you realize that your C structs need adjustments, it may still require a lot of refactoring.

Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

charris — 2009-01-15T06:15:28+00:00

- 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.

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.

Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

vomlehn — 2009-01-14T23:41:07+00:00

Here's an interesting exercise: try to find the definition of the function buffer_eopnotsupp() in the kernel. Hint: it's defined by using a macro, along with the functions set_buffer_eopnotsupp() and clear_buffer_eopnotsupp(). This is the kind of thing that object-oriented languages should be good at.

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]

Mostly but not totally agree..

Flameeyes — 2008-12-19T13:53:18+00:00

See there are some particular issues though that you can't workaround by limiting yourself to C syntax in C++.

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.

Mostly but not totally agree..

Solifugus — 2008-12-17T19:21:04+00:00

I actually live in a no-man's land of being a very C-like C++ programmer. I completely agree with Linus about the problems in C++. But I take C++ as a version of C, then use what parts of C++ I do like on top of it. I basically have C but I can pick and choose to use other things, too.

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