Imagine how I feel; you've been asked several times for anything that supports your view and you've posted nothing beyond "I think", "I feel", and "Linus says".That makes me feel like I'm talking to the wind... ?
*shrug*
Still, troll slaying is best left to "Orcs Must Die"...
Soma
Oh, but this isn't about the C++ mindset. Obviously going awry with OOP design with heavy reliance on virtual functions and temporary objects is going to hurt performance. No, I agree with you that one has to be careful inside a kernel.
However, we are trying to convey the message of C++ as the language. C++ is a better C in many ways. As long as one is aware that one is working with hardware, one can use any language suited to the task.
Heard of Microsoft's little research project Singularity? It's not written in C. And yet, it works, and it works well, I'd probably say. For a research OS anyway.
The point is that you must separate the mindset from the language. Separate design from language. Just because you use C++ doesn't mean you have to use OOP, exceptions, polymorphism, etc.
You can just use, say, templates and the better type system. What you need, or should, use depends on the requirements of the project. Naturally you also base the choice of language around this.
But that doesn't mean you have to squeeze every little imaginable piece of speed out of it. Many functions are rarely called.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.
The principle of avoiding premature optimization is a good one, even in kernels.
First you build your system so that it works. Then you start profiling it. Then you start optimizing.
Heh, I have given reasons, including asking for examples contrary to what I'm saying, and you've failed to produce as well. So you're argument is the pot calling the kettle back.
End point: C++ is a higher level paradigm language than C, by enough that makes it less suitable for kernel development than C. I don't know if I can make it any more succinct than that.
If you code C++ like it's C, then of course it will, and then what's the point of using C++ in the first place? The debate of C++ vs C for the kernel, is assuming both languages are used normally, so your point is off track.
Well, with that thought, one could use pretty much any compilable language. And sure, you're right about that. I'm simply arguing that using C instead of C++ is that more appropriate choice (by "C", I'm including using "C++ written like it's C" )
Your 3 steps sound sound to me. There's no reason though, that the last step shouldn't include extreme optimization, specifically on the heavily traveled routines, obviously there's little need to squeeze performance out of rarely called routines.
Well, if you are using that definition, then we are in agreement.
Obviously, yes, you are right. If the profiler shows that it is a heavily traveled path, then by all means, you should try squeezing out as much performance as possible.Your 3 steps sound sound to me. There's no reason though, that the last step shouldn't include extreme optimization, specifically on the heavily traveled routines, obviously there's little need to squeeze performance out of rarely called routines.
No, you really haven't. What you did do is regurgitate the same thing over and over, namely that you feel C++ is not worth it if you strip off many of its features. You have never even attempted to explain in which way the built-in support for runtime and compile-time polymorphism, RAII and better type safety provided by C++ __ISN'T__ a massive improvement over C.