|
![](/i/fill.gif) |
clipka wrote:
> Anyway, we're talking about a thing here that is very simple to identify
> automatically.
Certainly. And for that matter, it *was* identified automatically. It's just
that the wrong solution was taken. :-)
> For a project like the Linux kernel that is aimed at high portability,
Well, no. The Linux kernel wasn't started aimed at high portability. Just
the opposite, really.
> - The most common C compilers for the most common platforms are used so heavily
> that even compiler bugs related to unconventional cases are still quite likely
> to manifest soon.
True.
> Another reason is speed, of course, but just like with Assembler it could be
> argued that only the most heavily-used portions of a project should resort to C
> for speed these days.
Mmmm.... Debatable. :-) It really depends on the rest of the system. If
you're writing in some language fundamentally different from C, you might
spend more time translating into C data structures than you do to run it.
Nobody says "Wow, this SQL query is really slow. Let's rewrite it in C."
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
![](/i/fill.gif) |