In article <3e85uk$4o7@news.parc.xerox.com>,
John Ellis <ellis@parc.xerox.com> wrote:
>Brian Hawley writes:
>
>    These languages [Eiffel, Scheme, Oberon] place restrictions on the
>    behavior of pointers, do not allow integers to be used as pointers
>    (or don't trace them) ... C++ does not have these restrictions ...
[deleted]
>     I had to make the same restrictions on C++ behavior that Oberon
>     has. Unfortunately, since these restrictions couldn't be
>     enforced, the C++ code was slower than the corresponding Oberon
>     code (although it was at least as fast as code made in the normal
>     C++ style).
>
>Can you give details about which restrictions on C++ code caused its
>garbage collection to be slower than the corresponding Oberon code?

Can you give details on the 'restrictions' on pointers in Oberon?

Taylor Hutt (thutt@clark.net) wrote:

: Can you give details on the 'restrictions' on pointers in Oberon?

Taylor asked John Ellis, but the answer can be found simply in the standard
references, e.g. Reiser & Wirth, Programming in Oberon, pp. 134.

Pointers point only to heap objects. You can't do &x for a stack or
static object x.

Pointers point only to the BEGINNING of heap objects. You can't do
&(p->f) to get to the address of a data field inside an object. Also, there
is no multiple inheritance in Oberon.

There is no pointer arithmetic, i.e. you can't do p + n to point into the
middle of an array if p points to its beginning.

There is no void* pointer and no pointer cast.

Except for the possibility of pointer conversion from derived to base
class in Oberon, I believe these are the same restriction as in standard
Pascal.

Cay
horstman@cs.sjsu.edu

Taylor Hutt (thutt@clark.net) wrote:
: In article <3e85uk$4o7@news.parc.xerox.com>,
: John Ellis <ellis@parc.xerox.com> wrote:
: >Brian Hawley writes:
: >
: >    These languages [Eiffel, Scheme, Oberon] place restrictions on the
: >    behavior of pointers, do not allow integers to be used as pointers
: >    (or don't trace them) ... C++ does not have these restrictions ...
: [deleted]
: >     I had to make the same restrictions on C++ behavior that Oberon
: >     has. Unfortunately, since these restrictions couldn't be
: >     enforced, the C++ code was slower than the corresponding Oberon
: >     code (although it was at least as fast as code made in the normal
: >     C++ style).
: >
: >Can you give details about which restrictions on C++ code caused its
: >garbage collection to be slower than the corresponding Oberon code?

: Can you give details on the 'restrictions' on pointers in Oberon?

Hey I know you :)

There are certain operations that are commonly performed on pointers in C
that can't be done in Oberon without using SYSTEM.ADR and LONGINT. For
example, pointers to statically allocated variables, to arbitrary
addresses in memory, arithmetic computation of addresses (explicit) and
such. LONGINT variables are not typically traced as pointers by the
collector and operations on them that enable them to be used as pointers
require the import of SYSTEM in all implementations of Oberon that I have
used, including yours (as far as I know). The advantages that the
restrictions on POINTER variables have for safer programming (that I have
experienced) are:
- No 'dispose' of static variables or of data at arbitrary addresses
  (like 0000:4000 in DOS)
- No errors caused by bad arithmetic when calculating pointer addresses
  (like derefrencing a pointer to a float that is pointing to a string)

I consider these to be 'restrictions' in the same way that a railing on a
bridge is a restriction: I can jump over it if I want to, but normally I
don't, and I don't expect the bridge-maker to guarantee my safety if I
do. I didn't mean the word to sound like a criticism.

By the way, are you working towards making Logic Magicians Oberon use the
V4 API, now that the V4 source is available, or are you going to continue
extending the V2?

Brian Hawley
bhawley@orion.it.luc.edu and math.luc.edu