🚀 go-pugleaf

Eric Obermuhlner (erico@cnmat.berkeley.edu) wrote:

>How do I do the ugly things that C programmers like so very much in Modula 2?
>Like getting a pointer to a var, pointer arithmetic, bit operations (shift, and, or, exor).

All of these things are possible (but see below).
(a) p := ADR(v) makes p point to v;
(b) Pointer arithmetic: support varies from one compiler to another,
    but in the libraries you'll likely find procedures like
    SYSTEM.AddOffset and the like.  Early versions of Modula-2
    even allowed arithmetic on variables of type ADDRESS, but
    this mistake has since been corrected.
(c) Bit operations: usually supported in some low-level library
    module.  If not, you can fake them by type-casting to
    BITSET, though this is a messy solution.

The obvious question, though, is why you would want to do this.
Such operations are common in C programming because C lacks
more elegant ways to get the job done.  In Modula-2, there are
certainly situations where you want to do weird hardware-dependent
things and break the type system, but those situations should
arise only when writing very low-level modules.  In most other
cases, there's almost always a better way to do the job.

Why, then, do C programmers like the ugly style so much?
I can think of two main reasons:
 1. For whatever reason, C does not support the concept of an
    "array".  (The syntax makes it look as if arrays are
    supported, but when you dig deeper you discover that it's
    just a shortcut notation for certain pointer operations.)
    Thus C programmers get used to the idea of doing things
    like stepping a pointer through an array, even when it
    would be easier and clearer - and often more efficient -
    to use subscripts.
 2. Student programmers are often misled into thinking that
    low-level programming leads to greater efficiency.
    (Especially when they've graduated from using Basic to
    C; there's no doubt that C is faster than Basic, but then
    anything's faster than Basic.)  Often they're wrong, but
    they're so convinced that this conclusion is "intuitively
    obvious" that they simply refuse to make the comparison.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html