IMO, the runtime (as opposed to compile-time) costs of any given C++
construct is trivially easy to predict, since it all translates to C
fairly trivially.
Part of what your discussing is a style issue. When building a
kernel, performance is critical. Therefore, it's simply *bad*style*
for an overloaded function to have one implementation that's seriously
more expensive than another. It's just a matter of overloaded
functions being equivalent, and in the kernel, major runtime costs
simply must be considered in deciding equivalence.
> On the one hand, C++ advocates keep saying that "the compiler will
> make things easy, because then we won't have to think about it". Yet
> when folks argue about performance, the argument is "you just have to
> know what the compiler is doing".
No contradiction! You're simply observing that C++ is flexible enough
to support multiple programming styles well.
1. When optimizing for runtime performance, think about
implementation costs.
2. When optimizing for programmer productivity, don't.
No problem. No free lunch, either.
> This is why IMHO handing C++ to the average programmer seems roughly
> comparable to handing a loaded .45 to a chimpanzee.
You seriously expect average programmers to hack Linux? I don't.
--
Chip Salzenberg - a.k.a. - <chip@perlsupport.com>
"When do you work?" "Whenever I'm not busy."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/