home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / de / comp / sys / amiga / misc / 7724 < prev    next >
Encoding:
Text File  |  1993-01-26  |  4.8 KB  |  118 lines
  1. Newsgroups: de.comp.sys.amiga.misc
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!sol.ctr.columbia.edu!ira.uka.de!Sirius.dfn.de!tubsibr!duening
  3. From: duening@ibr.cs.tu-bs.de (Lars Duening)
  4. Subject: Re: SAS/C Compiler, Stacksize errechnen
  5. Message-ID: <1993Jan25.114817.17018@ibr.cs.tu-bs.de>
  6. Sender: postnntp@ibr.cs.tu-bs.de (Mr. Nntp Inews Entry)
  7. Reply-To: duening@ibr.cs.tu-bs.de (Lars Duening)
  8. Organization: TU Braunschweig, Informatik (Bueltenweg), Germany
  9. References: <nUNfs*K05@zikzak.in-berlin.de> <KqOfs*P05@zikzak.in-berlin.de> <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> <bUCks*s40@oberon.nbg.sub.org>
  10. Date: Mon, 25 Jan 1993 11:48:17 GMT
  11. Lines: 105
  12.  
  13. In <bUCks*s40@oberon.nbg.sub.org> schreibt Hartmut Goebel:
  14.  
  15. > In article <1993Jan18.152440.29470@ibr.cs.tu-bs.de>, Lars Duening writes:
  16. > 
  17. >  [es geht immer noch darum, ob man Pointer einfach incrementieren kann]
  18. > 
  19. >> Mag sein, dass es im Sinne des Spracherfinders 'unsauber' ist, aber ab
  20. >> und zu lassen sich solche Konstrukte entweder gar nicht vermeiden,
  21. >> oder bieten Effizienzvorteile. Und dann sag ich dem Compiler lieber
  22. > 
  23. > Mir sind eigentlich keine Faelle bewusst, in denen solche Konstruke
  24. > wirklich unvermeidlich waeren. Und die Effizienzsteigerung ist ein zu
  25. > schwaches Argument: besser ein korrektes Programmes als
  26. > eines, das nur auf Effizens getrimm ist und vor Fehlern (gefundene
  27. > und nicht gefundene) strotzt.
  28.  
  29. Und was ist mit korrekten Programmen, die dennoch auf Effizienz
  30. getrimmt sind?
  31.  
  32. >> "Dieses Programm sieht zwar unsauber aus, ist aber wirklich so
  33. >> gemeint."
  34. >
  35. > Um das einem Modula-2 oder Oberon[-2] Compiler zu sagen, musst Du hat
  36. > etwas Aufwand treiben. Schliesslich soll es einfacher sein, saubere
  37. > Programme zu schreiben, als Hacks.
  38.  
  39. Es ist nur deshalb ein Hack (und von daher _wirklich_ und zwangsweise
  40. systemabhaengig), weil es die Sprache nicht definiert.
  41.  
  42. >> addressierten als naechstes ueber diesen Zeiger erreichen (da mein
  43. >> Oberon-2 noch nicht komplett ist, konnte ich die 'Zeiger auf offene
  44. > 
  45. > ??? soll das einer verstehen?
  46. > Schreibst Du einen eigenen Compiler, oder was, oder wie?
  47.  
  48. Soll ich? *schelmisch grins*
  49.  
  50. > AmigaOberon 3.0 unterstaetzt das jedenfalls.
  51.  
  52. Sorry, es war wirklich missverstaendlich: Ich wollte nur ausdruecken,
  53. dass ich immer noch auf eine lesbare Disk-2 des neuen Amiga-Oberon 3
  54. warte.
  55.  
  56. >> der Definition der Rechenoperatoren. 'string + string' ist auch kein
  57. >> arithmetischer Ausdruck, aber dennoch sinnvoll.
  58. > 
  59. > INC(prt) ist aber ein arithmetischre Ausdruck, das ist der
  60. > Unterschied. 
  61.  
  62. Dann ist er halt arithmetisch - je nach Argument Zahlarithmetisch oder
  63. Pointerarithmetisch.
  64.  
  65. > Oder wasrum denkst Du wohl, ist INC(char) nicht moeglich?
  66.  
  67. NICHT??? Nur gut, dass ich's bisher nicht brauchte.
  68.  
  69. >> Wieso? Der GC kann sich ja auf die beschraenken, mit denen ich nicht
  70. >> rechne (Amiga-Oberon 3 hat ja extra die UNTRACED POINTER eingefuehrt,
  71. >> da nicht alles vom GC ueberwacht werden kann).
  72. > 
  73. > Wobei die UNTRACED POINTERS eine eiweiterung von AO sind, die nur
  74. > mit der norwendigkeit begruendet ist, dass halt nicht alle Objekte von
  75. > Oberon erzeugt werden (z.B. Fenster). Ansonsten ist UNTRACED _nicht_
  76. > standard. 
  77.  
  78. Hab ich auch nicht behauptet :-)
  79.  
  80. > (Wenn Du jattz anfangen willst, ueber Oberon Standard oder
  81. > nicht zu diskutieren, dann wende Dich erstmal an
  82. > G_DOTZEL@ame.zer.sub.org -- Nein, das sollte keine Flame sein!)
  83.  
  84. Schon klar. Aber keine Sorge, den Standard wollte ich eigentlich nicht
  85. diskutieren.
  86.  
  87. >> Eine Option a la (* $Sloppy+ *) waere ja schon ausreichend.
  88. > 
  89. > Und was soll die machen? 
  90.  
  91. Sie koennte Warnungen/Fehlermeldungen a la 'possibly non-portable
  92. pointer expression' abschalten.
  93.  
  94. > Und wie willst Du solche Programme dann auf anderen Rechenern kompilieren?
  95.  
  96. Genauso, wie ich Programme, die SYSTEM verwenden, kompiliere.
  97. In der Regel also gar nicht.
  98.  
  99. >> Ich finde es halt nur nicht gut, dass vor lauter
  100. >> Highlevel-OOP-Abgehobenheit die Lowlevel-Programmierung unnoetig
  101. >> schwer gemacht wird (und umgekehrt).
  102.  
  103. Dabei habe ich noch nicht mal den fehlenden Inline-Assembler
  104. angemeckert ;-), na, das neue Binaer-Include tut's auch.
  105.  
  106. > Es wird nicht schwer gemacht. Schau in das Buch "Project Oberon",
  107. > dort wird das ganz Oberon-System entwickelt und erklaert. Das, was Du
  108. > low-level nennst, findet man dort nicht (oder nut kaum, ich hab das
  109. > Buch nicht auswednig gelernt :-)
  110.  
  111. Nur dass halt der Amiga eben nicht von Grund auf in Oberon
  112. programmiert wurde. Von daher ist ein bisschen low_level nicht ganz
  113. unnoetig, will man Oberon als alleinige Sprache verwenden.
  114.  
  115.   Lars
  116. --
  117. Lars Duening; duening@ibr.cs.tu-bs.de
  118.