Benjamin Leon Russell wrote:
>
> [example of an unsafe method in C#]
>
> Taken to an extreme, this ability could encourage some programmers to
> ignore the spirit of higher-level abstraction and focus back on The Old
> Way (TOW): rampant pointer-level optimization to squeeze out that extra
> iota of performance at the expense of clarity.
But Java also has a way to do "rampant pointer-level optimization": You declare
a method as "native" and then implement it in C.
Any sensible programmer will recognize the loss of portability, safety and
abstraction when writing a native method in Java, and will only do so when
absolutely necessary. The same should go for "unsafe" methods in C#, UNSAFE
modules in Modula-3, and "unsafePerformIO" in various Haskell implementations.
C# simply provides a mechanism to write native methods within the C# language
directly instead of dropping down to C. I haven't looked too closely at C#, but
I would imagine that even unsafe C# has less "implementation defined" pitfalls
than C and other features useful for systems hacking (e.g. exceptions), and
therefore even "unsafe" C# might be a better language for doing the kinds of
low-level systems hacking that Java only permits you to do in C. This was
certainly true for "unsafe" modules in Modula-3.
Remember, too, that not every program is written as an application on a PC. The
requirement in Java that native methods be implemented in another language
caused serious problems for the JavaOS and embedded / JVM-on-a-chip efforts.
How do you write a device driver for a memory-mapped device in 100% pure Java?
You can't. The "unsafe" provision in C# might make C# a more viable language
for such systems.
-antony
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
[EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
