From: gimmini@myour.in-berlin.de (Olaf Gimmini)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: SAS/C Compiler, Stacksize errechnen
Distribution: world
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
Date: 27 Jan 93 20:48:42 MET
Organization: Private UUCP-Site

In article <1k0nthINNakt@nz12.rz.uni-karlsruhe.de> ry53@rz.uni-karlsruhe.de (Angela Schmidt) writes:
>
> In article <2hgls*D40@oberon.nbg.sub.org>, hartmut@oberon.nbg.sub.org (hartmut Goebel) writes:
>>

>[...]

> Nun aber zu Deiner Frage:
> Sieh' es einfach mal so: Mir ist die Geschwindigkeit und die Krze
> meines Programmes einfach _viel_ wichtiger als die paar Vorteile, die
> mir Oberon gbe. Feldberschreitungen und hnliches kommen so selten
> vor, da ich keine Lust habe, mir fr die paar Flle, die ich notfalls
> mit Mungwall debuggen kann, eine runtime-library and den Hals hngen
> zu lassen.

Es gibt bei modernen Compilern und Linkern die Moeglichkeit, vielen
Ballast nach einer Test-Phase einfach wegzulassen.
Trotz sicherem Debuggen haben die Programme dann durch Setzen einiger
Optionen keine Kloetze mehr, welche unnoetig bremsen, bzw. Speicher
verschwenden. (Assembler bleibt natuerlich in diesem Punkt ungeschlagen!)

> Ich brauche auch keine Garbage-Collection, denn allein
> _ich_ wei, wann ich etwas allociert habe und wann ich es wieder loswerden
> will. Und wenn ich mein Public-Mem einem anderen Task vererbe, kann
> ich sicher sein, da mein Compiler es nicht besser gewut hat.
>
> [...]
>
> Wenn ich auf meine letzten paar Jahre C-Erfahren zurckblicke,
> mu ich feststellen, da die _wenigsten_ Bugs aus Fehlern bestanden,
> die ein Compiler gefunden htte. Ok, es waren durchaus Fehler dabei,
> die ein Compiler htte vermeiden knnen - meist lag es dann aber
> an der _Implementierung_ des Compilers und nicht an der Sprache
> "C". DICE steckt halt noch etwas in den Kinderschuhen und hat an
> einigen Stellen noch so seine Macken. Das mu man halt akzeptieren,
> dafr hat man einen preiswerten Compiler. Ob Dein Oberon sooo viel
> besser ist, kann ich leider nicht beurteilen.
> [...]

> Um es kurz zu sagen: ich _will_ mich auf einer tieferen Ebene
> bewegen, weil ich die Kontrolle ber mein Programm selber haben
> will (ja, ich traue nicht mal meinem Comliper - nur mir selbst :-) und
> weil ich von der hheren Geschwindigkeit, dem kleineren Code und
> hnlichem profitieren will.

Modula 2 bietet dieses uebrigens auch.
Das ist eine Verbesserung gegenueber Pascal.
Oberon, als eine Programmiersprache, auf der ein ganzes Betriebssystem
aufbaut, wird also auch Maschinennaehe bieten muessen.

> [...]

C ist eine Programmiersprache, welche Computergeschichte geschrieben hat
und immer noch schreibt.
Ganze Betriebssysteme sind durch C entstanden. Genau wie durch Oberon.
Wie Bonzo schon gesagt hat, hat jede Programmiersprache sein Plus und
Minus fuer die unterschiedlichen Anwendungen und Programmierstile.
Aber bei der Betrachtung bitte objektiv bleiben, und nicht
nur alte Klischees wieder aufwaermen.

>
>      V v
>   @/@@=\   Und hr' bitte auf, uns Oberon einreden zu wollen,
>     00 &=-      Angela
> oOoO_/` \\_
>     \ /&\   Angela Schmidt cand. inf. (Nessy@IRC) | Amiga //
>   |>O<|         EMail: Angela@rz.uni-karlsruhe.de | 1000 //
>    / \_/\/\/v,  Weekend: +49 731 712316 (9am-9pm) |  \\ // since
>   /___________\ Weekdays: 721 6904263 (10am-11pm) |   \X/ 1986

--
Olaf Gimmini (ECG117)
 Weitbrucher Str. 31
  D-1000 Berlin 47
   UUCP: gimmini@myour.in-berlin.de
Newsgroups: de.comp.sys.amiga.misc