Actually, I sort of am. When someone says something is written in C++, I assume they took advantage of most of it's features, including said ones. If you take OOP, polymorphism, RAII, and exceptions away from C++, then you have nothing more than a slightly improved C. I don't think it would be fair to call a project written in said manner, a "C++ project".Originally Posted by Elysia
But why? What is it about C++ that makes it unsuitable for kernel development? And also, I've already asked you this two pages ago, in what way is exception handling broken in C++?
But why would you take RAII away? That makes no sense.
EDIT: In fact, I don't even see the point in taking polymorphism away. If you have a need for runtime polymorphism, why not just use virtual methods and be done with it? What exactly is the advantage of coming up with some obscure function pointer table approach and basically reinventing what C++ gives you for free?
Last edited by antred; 07-04-2012 at 03:13 PM.
Perhaps, perhaps not (C++ consists of way more than that). But the fact still remains that you would be using C++ as the programming language.
Considering Yarin's latest posts, I'd assume at least polymorphism and exceptions are considered unsuitable by Yarin.
[QUOTE=Elysia;1114243Considering Yarin's latest posts, I'd assume at least polymorphism and exceptions are considered unsuitable by Yarin.[/QUOTE]
I can't imagine why. why would it be disadvantageous to have classes like SCSIHardDisc, derived from HardDisc, derived from BlockDevice, derived from StorageDevice, etc? it seems very straightforward to me, not to mention readable and maintainable.
Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
Yes, you're technically right (but not necessarily so), but I've been talking in practical terms.
Those provided by C++, for kernel development, I would say that's right.
Mmm. I've successfully built and run a "hello world" kernel, that admittedly had more code that wasn't mine that was. I don't think that really counts. The kernel you've built, is it an actual, somewhat functional kernel? (Note: If you have, I would actually like to see what you came up with)
Yes, but (obviously) not in the language itself. Design polymorphism and language polymorphism isn't the same thing.
Please, educate me.
Isn't that the point we're debating? You're just repeating yourself.
Sticking your head in the sand and pretending that Linus knows what he is talking about with respect to C++ is apparently more draining on the intellect than I thought.Said abstractions can very easily be implemented in C without using the OOP features provided by C++.
Such abstractions can't be implemented in any language in the family without using the "OOP" features provided by C++. The only difference is how much the C++ compiler does versus how much the programmer must code.
Make no mistake, the polymorphisms and other abstractions that make the foundation of the "Linux" kernel is built on the same concepts a C++ compiler uses to provide those facilities. There is no magic here.
"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."Isn't that the point we're debating?
Is a statement containing no actual criticisms of C++ (There are plenty of real complaints about C++ to consider.), no valid argument (If a statement of prejudice was a valid argument the world would be a terrible place.), and no supporting rationale (There can be no supporting rationale for this because it is such a mindbogglingly stupid sweeping generalization.).
There is no debate.
You are just a silly fan with a foolish mentality.
Soma
Last edited by phantomotap; 07-05-2012 at 03:31 AM.
Tell me how to implement classes in C without wasting lots of memory and execution time with function pointers.
I would be very interested.
Mmm. So describe to me how you would implement these features in C, in such a way that they would be better than the code generated by a C++ compiler.Those provided by C++, for kernel development, I would say that's right.
Well, I can see why exceptions might not be something you want in a kernel, but I cannot for the life of me find anything wrong with built-in runtime polymorphism.
I'm starting to think that there is a serious fundamental misunderstanding, in a lot of minds, about the way C++ works. after compilation, it's all just machine code. equivalent programs in both C and C++ will produce equivalent machine code. both will likely perform and function identically, within a certain tolerance, assuming they were both built with compilers from the same vendor (gcc/g++, etc). the only difference is in the interface that the programmer sees. I really don't understand why people think that C++ is some bloated, inefficient language.
one of the guiding principles of C++'s implementation is the concept there should be no penalty for an optional feature that you don't use. so even if you think that C++ exceptions are bad to use in a kernel, then just don't use them. if you don't have code that throws exceptions, you'll never need to catch them, and therefore there's no overhead. and if you're really anal about it, most compilers have an option to disable features like RTTI and exceptions.
C++ offers many features of value to kernel programmers, even if you throw out polymorphism, object orientation, and exception handling. strict type safety is a huge benefit of using C++, and should be enough just by itself to justify the use of the language.
I find it hard to believe that it's as simple as that. Of course I may be wrong, the Linux kernel is much bigger than it ought to be. You'll have to show me one of these commonplace instances you speak of.
I wouldn't agree with this statement. But then, it wasn't included in the post that I said I found respectable, either. You act as if though I take everything Linus says as gold.
That makes me feel like I'm talking to the wind... ?
Now you're just resorting to insults. That doesn't help your argument any.
Maybe you're missing my point. I'm not suggesting that one implement C++ features for use in C, but rather implement less generic, more specialized solutions for the kernel. Remember, when developing a kernel, there's hardly a such thing as premature optimization.
[ ^ ]
But who says you can't implement these specialized solutions using C++?
If you want to object-orient your kernel code, or embrace abstractions and encapsulation, how is it that C can do it, but not C++?
There is always premature optimization, in kernels above all due to their incredible overall complexity.Remember, when developing a kernel, there's hardly a such thing as premature optimization.
If one wants their kernel to run according to their envisioned C++ paradigm, then of course they should code it in C++.
I think though, that the kernel should run closer to the bare metal than literally any other software in the OS, including drivers. And to best do that, one should avoid the C++ mindset. Embedded devices and kernels are where C shines the brightest, I think, for the very bare bones qualities that you ridicule.
I really don't think so. Literally the whole system relies on it, and I imagine it's routines are traversed way more than any other in a normal computing session. You'd want it to be fast.
agreed. all of the most common compilers are made to know how to optimize for a given processor, and they do a very impressive job of it. trying to circumvent that is just wasting the compiler's time and yours. that being said, if, after profiling a block of code, you find an area that could be optimized better, because certain assumptions can be made that the compiler cannot make, then it may be appropriate to fine tune it with some inline assembly or some other type of optimization. only after profiling compiler-generated machine code reveals a bottleneck should you consider hand optimization.
