| |||||||||||||
Not everything is a nail...Not everything is a nail...Posted Jan 14, 2011 9:43 UTC (Fri) by dwmw2 (subscriber, #2063)In reply to: Not everything is a nail... by HelloWorld Parent article: Sobotka: Why GIMP is inadequate The problem in the kernel is that we get a lot of drive-by contributions from people who don't really know what they're doing. A lot of driver code is pure crap. You are absolutely right that C++ can be used sparingly. Qt handles it fairly well, enforcing a sane use of a subset of C++ rather than the whole range of features. However, this does depend on restraint on the part of the developers. If we had C++ available, we would either spend a lot of time telling developers "no, you can't do that", or we'd accept a lot of use of C++ features that we would prefer not to use. It is often the case that certain developers don't have a full understanding of the cost of the code they're writing, even when they're using C. Not everyone is forced to spent part of their life looking at the compiler output from their code and seeing what it actually does, although they ought to be. While the "don't pay for what you don't use" principle has indeed worked out pretty well in general, the fact remains that people would be using more, and thus paying more. Unless you just want us to compile our existing C code with a C++ compiler? :) Which wouldn't work today because we make heavy use of C99 structure initialisation, and I don't believe that works in C++?
(Log in to post comments)
Not everything is a nail... Posted Jan 21, 2011 15:56 UTC (Fri) by daglwn (subscriber, #65432) [Link]
It is often the case that certain developers don't have a full understanding of the maintenance cost of the code they're writing,
I am sick and tired of kernel people spouting ignorance about C++. They look like fools. Every single project I've followed that places restrictions on the use of C++ ends up with bugs and misdesigns that could have been avoided had the leadership opened its minds to the idea that C++ is a cohesive language. Stripping parts of it out just means you're throwing away safety, code reuse or both.
Not everything is a nail... Posted Jan 21, 2011 20:31 UTC (Fri) by xilun (subscriber, #50638) [Link]
And only work with C++ experts in any cases (restrictions or not). Who are even more difficult to find than C experts, and C experts are already difficult enough to find...
Not everything is a nail... Posted Jan 21, 2011 23:41 UTC (Fri) by daglwn (subscriber, #65432) [Link]
I really question whether competent C++ developers are hard to find. There are lots of C++ jobs out there so it's not as if the language isn't being used. You really have to try _not_ to learn something about a language after using it for a while.
In my experience the problem is resistance to the unknown, no matter how much that unknown might improve one's productivity.
Not everything is a nail... Posted Jan 21, 2011 21:46 UTC (Fri) by Spudd86 (guest, #51683) [Link]
The problem is that many C++ features would need additional support code that doesn't currently exist in the kernel (for example, exception handling with zero overhead in the case of no exceptions thrown would need both new kernel code to support it and tighter coupling between the kernel and compiler).
In the kernel restrictions are more than just style or taste, they are also because the user space code that the compiler relies on being present in the final executable may not work in kernel space, if it doesn't that feature either cannot be used or replacement support code must be written, the latter option ties the kernel more tightly to the compiler and increases the chances that a new compiler version will break the kernel.
Not everything is a nail... Posted Jan 21, 2011 23:52 UTC (Fri) by daglwn (subscriber, #65432) [Link]
Of course something like exceptions would require support code in the kernel and I'm not advocating that exceptions are necessarily the best way to do error handling in the kernel. I'm not an expert in the kernel domain so I don't feel qualified to judge either way. The same goes for rtti, which can often be avoided anyway.
What I am advocating is that the kernel people unplug their ears, uncover their eyes and think about what benefits C++ might bring. It would help tremendously with writing code that uses callbacks. The whole filesystem architecture with the VFS layer and implementation layers is crying out for an inheritance model. RAII would help a lot with resource cleanup.
Heck, RAII *alone* should be enough to seriously consider C++ in any project.
Now rewriting the filesystem architecture is too much to expect (I'm just giving it as a well-known example) but these kinds of patterns abound in most code. C++ really can save a lot of lines of code and that usually means fewer bugs and often better performance.
But the trick is, you have to use the multi-paradigm features of the language. Multiple inheritance, templates, operator overloading and constructors/destructors complement each other in surprisingly beautiful ways. I have heard strong arguments against all of those features and I just shake my head in sadness every time I have to address them.
Not everything is a nail... Posted Jan 22, 2011 0:52 UTC (Sat) by jmm82 (guest, #59425) [Link]
The VFS already has an inheritance model in c, it is called function pointers.
Not everything is a nail... Posted Jan 22, 2011 1:25 UTC (Sat) by daglwn (subscriber, #65432) [Link]
Which is, of course, my whole point. Why go through the pain and bugs involved with function pointers when the compiler will generate it for you? It baffles me why anyone who advocates using tools to automate tasks (i.e. anyone who writes code) would abandon that principe at some arbitrary level of the development stack.
Not everything is a nail... Posted Jan 25, 2011 9:38 UTC (Tue) by paulj (subscriber, #341) [Link]
You can do RAII in C just fine...
Not everything is a nail... Posted Jan 25, 2011 16:06 UTC (Tue) by jrn (subscriber, #64214) [Link]
I suppose it depends what RAII means. But no, I am not aware of a simple way to, say, free memory on the heap when a pointer to it falls out of scope (especially when a "return" statement exits that scope).
Not everything is a nail... Posted Jan 25, 2011 16:41 UTC (Tue) by etienne (subscriber, #25256) [Link]
Maybe you do not have the problem of freeing memory when a local structure goes out of scope in C (outside of kernel space), because in that case the local structure is declared in the stack and will be freed automatically...
Maybe the real problem is that your "autoptr" is not able to manage an object in the stack, but you need an "autoptr" because one method has such an argument.
Not everything is a nail... Posted Jan 25, 2011 22:18 UTC (Tue) by daglwn (subscriber, #65432) [Link]
Will that local structure also close files for me when it goes out of scope? Or does that local structure free memory pointed to by members of that structure when it goes out of scope? Or does that local structure release a lock it holds when it goes out of scope?
RAII is about MUCH more than memory.
Not everything is a nail... Posted Jan 26, 2011 12:32 UTC (Wed) by paulj (subscriber, #341) [Link]
For me RAII in the abstract is an object/resource-lifetime management strategy, such that creation and destruction of composite objects appear atomic wrt resources/objects held internally, as far as users of the object are concerned. Obviously it's good programming to try make objects atomic in this way when designing code.
C++ has implicit calls to constructors and destructors, which tie in to scoping. C doesn't have that, true, and requires explicit construction and destruction (you can still hide destruction behind refcounting, obv). It's often bad practice and/or a sign of a (quick)? hack when C code uses automatic allocating for non-trivial, composite objects.
Whether language support for implicit ctor/dtors tied with scoping is required for a practice to be called RAII, I don't know. I guess to a C++ person it does. Still, the general sentiment of RAII seems more widely applicable than C++.
Not everything is a nail... Posted Jan 26, 2011 19:52 UTC (Wed) by daglwn (subscriber, #65432) [Link]
Implicit destruction (finalization, uninit or whatever you want to call it) seems to me integrally tied to the concept of RAII. Without it, one ends up having to cover all exit points of a scope with explicit calls to cleanup code. Either this means there are several such calls scattered around parts of the enclosing scope or there's a big ugly goto to a common piece of cleanup code. Neither is particularly attractive or maintainable.
This gets to be impossible if the exit points are not known statically. C++ exceptions are a classic example but since some seem to think the C++ exception model is broken, I will emphasize that the problem is NOT solved by eliminating exceptions. One still has to cover all exit points with cleanup code.
Perhaps a better term for this would have been "resource ownership is object lifetime."
Not everything is a nail... Posted Jan 30, 2011 0:37 UTC (Sun) by nix (subscriber, #2304) [Link]
*Closures* would help tremendously in writing code that uses callbacks. But they require quite a lot of runtime support which is not available in the kernel.
C++'s syntactic sugar is insignificant in comparison. (At least, in this area. I agree that RAII is really nice, but the kernel seems to be surviving without it.)
|
|||||||||||||