From: hartmut@oberon.nbg.sub.org (hartmut Goebel)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: SAS/C Compiler, Stacksize errechnen
Date: Thu, 21 Jan 1993 13:02:51 GMT
 <4059.0701931007@bluemoon.GUN.de> <F+hgs*n45@zikzak.in-berlin.de> <skQgs*Bs0@forge.franken.de>
 <cb2hs*540@oberon.nbg.sub.org> <1993Jan12.125439.5361@mpifr-bonn.mpg.de> <1993Jan12.154149.29982@cs.tu-berlin.de>
 <1993Jan12.221100.9449@ibr.cs.tu-bs.de> <Bilis*b40@oberon.nbg.sub.org> <1993Jan18.152440.29470@ibr.cs.tu-bs.de>
Organization: home of the hard brave man
X-Newsreader: Arn V1.00 pre

In article <1993Jan18.152440.29470@ibr.cs.tu-bs.de>, Lars Duening writes:

 [es geht darum, ob man Pointer einfach incrementieren kann]

 >Mag sein, dass es im Sinne des Spracherfinders 'unsauber' ist, aber ab
 >und zu lassen sich solche Konstrukte entweder gar nicht vermeiden,
 >oder bieten Effizienzvorteile. Und dann sag ich dem Compiler lieber

Mir sind eigentlich keine Flle bewut, in denen solche Konstruke
wirklich unvermeidlich wren. Und die Effizienzsteigerung ist ein zu
schwaches Argument: besser ein korrektes Programmes als
eines, das nur auf Effizens getrimm ist und vor Fehlern (gefundene
und nicht gefundene) strotzt.

 >einmal "Dieses Programm sieht zwar unsauber aus, ist aber wirklich so
 >gemeint.", als dass ich durch n-maliges Neueintippen der aetzenden
 >Konstruktion die Anzahl der Tippfehler erhoehe (wieso hat Oberon

Um das einem Modula-2 oder Oberon[-2] Compiler zu sagen, mut Du hat
etwas Aufwand treiben. Schlielich soll es einfacher sein, saubere
Programme zu schreiben, als Hacks.

Das mit dem Vertippen ist Schwachsinn. Das findet der Compiler ohne
Probleme und wozu hat man den Tastaturmakros, wenn man das schon
verwenden will?

 >eigentlich keinen Preprozessor?).

Wei isch nicht mehr genau, aber es war ein gutes Argument. Frag hat
mal in comp.lang.modula nach.

 >IMHO ist das INC() verstaendlicher als der .ADR()-Ausdruck.

IMHO nicht. Zumal der SYSTEM.ADR()-Ausdruck deutlich mahct, da es
sich um eine systemabhngige Sache handelt.

 >addressierten als naechstes ueber diesen Zeiger erreichen (da mein
 >Oberon-2 noch nicht komplett ist, konnte ich die 'Zeiger auf offene

??? soll das einer verstehen?
Schreibst Du einen eigenen Compiler, oder was, oder wie?

AmigaOberon 3.0 untersttzt das jedenfalls.

 >der Definition der Rechenoperatoren. 'string + string' ist auch kein
 >arithmetischer Ausdruck, aber dennoch sinnvoll.

INC(prt) ist aber ein arithmetischre Ausdruck, das ist der
Unterschied. Oder wasrum denkst Du wohl, ist INC(char) nicht mglich?

 >Wieso? Der GC kann sich ja auf die beschraenken, mit denen ich nicht
 >rechne (Amiga-Oberon 3 hat ja extra die UNTRACED POINTER eingefuehrt,
 >da nicht alles vom GC ueberwacht werden kann).

Wobei die UNTRACED POINTERS eine eiweiterung von AO sind, die nur
mit der norwendigkeit begrndet ist, da halt nicht alle Objekte von
Oberon erzeugt werden (z.B. Fenster). Ansonsten ist UNTRACED _nicht_
standard. (Wenn Du jattz anfangen willst, ber Oberon Standard oder
nicht zu diskutieren, dann wende Dich erstmal an
G_DOTZEL@ame.zer.sub.org -- Nein, das sollte keine Flame sein!)

 >Eine Option a la (* $Sloppy+ *) waere ja schon ausreichend.

Und was soll die machen? Und wie willst Du solche Programme dann auf
anderen Rechenern kompilieren?

 >Ich finde es halt nur nicht gut, dass vor lauter
 >Highlevel-OOP-Abgehobenheit die Lowlevel-Programmierung unnoetig
 >schwer gemacht wird (und umgekehrt).

Es wird nicht schwer gemacht. Schau in das Buch "Project Oberon",
dort wird das ganz Oberon-System entwickelt und erklrt. Das, was Du
low-level nennst, findet man dort nicht (oder nut kaum, ich hab das
Buch nicht auswednig gelernt :-)

 >Lars Duening; duening@ibr.cs.tu-bs.de

+++hartmut

| Hartmut Goebel | UseNet: hartmut@oberon.nbg.sub.org              |
| Amiga Software | Z-Netz: HARTMUT@ASN.ZER           // Only Amiga |
| Manufactur     | Fido: 2:246/81.1  IRC: Essich   \X/ Oberon  ZOC |