Re:Writing a Simple Linux Kernel Module
by alxlaz on Thursday November 30, 2017 @03:30PM
(#15819228)
I was referring only to the parts of that rant that are/were of some objective value, e.g.:
> anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny
> the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.
You can certainly write C++ code without overabstracting it. Maybe Torvalds only ran into C++ programmers who liked overabstracting their code -- as it is usually the case with opinions of some people about other people, that part of the rant is best discarded :-).
But as my memory serves me, back when "portability" meant x86, SPARC, Alpha, ARM, MIPS, PPC, PA-RISC and m68k, the only way to do "good, efficient, and system-level and portable C++" was to limit yourself to the (relatively small) subset of C++ that was well-implemented by widely-available compilers (particularly GCC) across all these architectures -- not as a matter of discipline and code elegance, but because writing non-trivial C++ code back then usually resulted in very unpleasant trips down the standard library's source code and poring over objdump outputs trying to figure out what the hell broke this time.
> anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny
> the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.
You can certainly write C++ code without overabstracting it. Maybe Torvalds only ran into C++ programmers who liked overabstracting their code -- as it is usually the case with opinions of some people about other people, that part of the rant is best discarded :-).
But as my memory serves me, back when "portability" meant x86, SPARC, Alpha, ARM, MIPS, PPC, PA-RISC and m68k, the only way to do "good, efficient, and system-level and portable C++" was to limit yourself to the (relatively small) subset of C++ that was well-implemented by widely-available compilers (particularly GCC) across all these architectures -- not as a matter of discipline and code elegance, but because writing non-trivial C++ code back then usually resulted in very unpleasant trips down the standard library's source code and poring over objdump outputs trying to figure out what the hell broke this time.