← Back to context

Comment by josteink

7 years ago

> The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code.

How is "val = PEEK adr" and "POKE adr, val" any less polluting than allowing "val = &adr" and "&adr = val" in select places?

7 comments

josteink

Reply
eterps  7 years ago

It makes it easier to analyze code (i.e. greppable), and it allows for a distinction between operations that do direct memory modification and regular application code (pass by reference is accomplished with an entirely different syntax in Oberon, same for pointer types).

pjmlp  7 years ago

It shouts to you, "Take care something dangerous going on".

Hieroglyphs are easy to pass by.

  • josteink  7 years ago

    Lots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe.

        void DoSomeUnsafeStuffHere()
    {
        // regular code here. pointers verboten.
        
        unsafe
        {
             // pointery stuff here
        }
    }

    I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.

    • pjmlp  7 years ago

      That is true, my point was that for C and C++ that is not clear at all.

      You cannot simply search for & and * regarding point operations because those are also valid numeric operators, thus with context dependent meaning.

      Being able to search for PEEK/POKE, SYSTEM.PUT/SYSTEM.GET, or just unsafe blocks makes all the difference tracking down unsafe code.

      Also note that unsafe code blocks is older than C almost for 10 years, as ESPOL/NEWP already had such feature in 1961.

      1 reply →

    • eterps  7 years ago

      What makes it unclear is exactly this 'pointery stuff'. There's nothing inherently unsafe about strongly typed pointers, but that's not the same as direct memory modification (which is obviously unsafe).

      1 reply →