C-Kurs, Abend 4 - Verbesserungsvorschläge


    • skoe
    • 6082 Aufrufe 59 Antworten

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • mir fallen vor allen dingen stylistische probleme auf...

      - wie du ja auch im text schon erwähnt hast birgt das nicht-klammern von blöcken nach zb if die gefahr das man schnell fehler macht. genau aus dem grund steht in vielen styleguides diverser projekte das solche blöcke immer geklammert werden *müssen*. einem anfänger sollte man das ruhig einfach komplett verschweigen das es auch ohne geht, wie schonmal gesagt: den stil kann man sich auch später noch versauen :)
      - deutsch variablen- oder funktionsnamen. ihbähpfui. auch das sollte man garnicht erst zeigen, denn sonst wird das zur gewohnheit. es gibt nichts schlimmeres als in einem source rumguckn zu müssen wo die funktionen nach irgendeiner landessprache benannt sind die man nicht beherrscht. darum von anfang an: englisch.
      - gleiches gilt für kommentare, vielleicht sogar noch wichtiger. auch da tut man sich nur selber einen gefallen wenn man die einfach konsequent immer in englisch macht.

      zu guter letzt aber auch noch ein wirkliches problem: string- und character literals übersetzt cc65 so wie es der standard vorsieht beim kompilieren vom zeichensatz des hostsystems in den zeichensatz des zielsystems. dh petscii steuerzeichen in strings sind problematisch (die funktionieren zwar oft, weil cc65 beim übersetzen nur druckbare zeichen behandelt im moment - das kann sich in zukunft aber durchaus ohne vorherige ankündigung ändern). der hinweis auf die petscii tabelle ist daher auch eher suboptimal, denn im sourcecode wird ausschliesslich ascii benutzt (bzw erwartet).

    • das kann sich in zukunft aber durchaus ohne vorherige ankündigung ändern

      Den Satz habe ich schon zur genüge gelesen.

      Es spielt sich beim cc65 auf diesem Spielfeld nicht mehr viel ab. Das kannst du dir abschminken. Es werden grundsätzlich zur Zeit nur noch Mängel abgestellt gem Aussage von Bassewitz. Dementspreched war auch seine Antwort auf meine cgi-Frage.

      Man soll hier keine falschen Verspechungen machen.

      mfg

    • Der Codestyle ist etwas, worüber man sich keine Gedanken mehr machen muss, wenn man Eclipse benutzt.
      Man kann ganz detaillierte Vorgaben für den Code-Style einstellen:

      Grundtyp: K&R, BSD/Allmann, GNU, Whitesmith
      Und im Detail:
      • wo sollen die Klammern stehen
      • wann wird wie eingerückt
      • wann wird eine Zeile umgebrochen
      • sind Spaces oder Tabs zu verwenden
      • wo dürfen Variablen deklariert werden
      • wie sollen Array-Definitionen formatiert sein
      • u.v.a.m.
      Das reicht so weit, dass man den Code bedenkenlos komplett über den eingebauten Formatter formatieren kann. Ich propagiere das sogar.

      Und selbstverständlich kann man Eclipse auch mit CC65 zusammen verwenden.

      Schaut's euch mal an, wenn Ihr Interesse an guten Tools habt.

    • - deutsch variablen- oder funktionsnamen. ihbähpfui.

      Bist du kein deutscher..., bisschen mehr tut gut. :winke:

      Diese Aussage drängt uns mehr an den Abgrund, wie uns vorwärts zu bringen in der deutschen Sprache. :prof:

      Also Kameraden: Wer das Programm durch die deutschen Variablen/Text besser versteht, soll sein Programm auch mit deutschen Varibalennamen schreiben. Nach dem Motto: ....auch wir können etwas...und es wird mehr....

      mfg

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von schnucke ()

    • Und selbstverständlich kann man Eclipse auch mit CC65 zusammen verwenden.


      Kann ich für dieses cc65 abraten in dieser Lernphase, wer Eclipse nicht kennt wird sich dran festbeissen.
      Also wir wissen jetzt das du es kannst.
      Man könnte auch Babylon nehmen als IDE.

      ...muss ich noch lernen :winke:

      mfg

    • Es spielt sich beim cc65 auf diesem Spielfeld nicht mehr viel ab. Das kannst du dir abschminken. Es werden grundsätzlich zur Zeit nur noch Mängel abgestellt gem Aussage von Bassewitz. Dementspreched war auch seine Antwort auf meine cgi-Frage.

      Man soll hier keine falschen Verspechungen machen.


      ich mache keine versprechungen, ich sage nur wie es ist (und das wird dir auch Uz bestätigen das das so ist). ausserdem glaube ich das du garnicht verstanden hast was ich gesagt habe, was dich aber wiedermal nicht davon abhielt irgendeinen unsinn zu cc65 zu kommentieren. bitte lass das doch einfach, echt jetzt.

      Und selbstverständlich kann man Eclipse auch mit CC65 zusammen verwenden. Schaut's euch mal an, wenn Ihr Interesse an guten Tools habt.

      ich persönlich rate von eclipse ab, und zwar dringend :) mir ist selten so ein aufgeblasenes monster dahergekommen :)
      (und automatisch einrücken und klammern usw können viele editoren, tools zum formatieren gibts auch ohne ende etc... eclipse benutzt dafür auch nur das commandline tool "indent" wenn ich mich recht erinner)

      wenn ich mit irgendwelchen SDKs arbeiten muss ist in der regel das erste was ich tue diesen eclipsemist loszuwerden und normale makefiles zu schreiben =P aber klar, soll jeder benutzen was er für richtig hält =) ich finde aber das man solch ein mächtiges tool wie eclipse erst dann in erwägung ziehen sollte wenn man das was man tut grundlegend verstanden hat, was für die zielgruppe eines anfänger kurses wohl eher nicht zutreffen dürfte :) für den anfang sollte ein beliebiger editor mit syntax-highlighting mehr als reichen.

      Bist du kein deutscher..., bisschen mehr tut gut.

      Diese Aussage drängt uns mehr an den Abgrund, wie uns vorwärts zu bringen in der deutschen Sprache.

      Also Kameraden: Wer das Programm durch die deutschen Variablen/Text besser versteht, soll sein Programm auch mit deutschen Varibalennamen schreiben. Auch die anderen Menschen jenseits der Grenze sollen wissen das wir es auch können.


      wenn du in der deutschen sprache weiterkommen willst solltest du mal ein gutes buch lesen (und weniger quatsch schreiben). jeder der programmiert und es nicht schon in der anfangsphase wieder hinwirft kommt irgendwann dahin das er mit anderen zusammenarbeiten will, den source von andren lesen oder seinen eigenen source anderen zum lesen geben möchte. und spätestens an der stelle ist es ein unschlagbarer vorteil wenn du deinen source auch jemandem zeigen kannst der kein deutsch kann. oder das du nicht erst polnisch lernen musst um einen source zu lesen der dich interessiert.

    • sauhund schrieb:

      zu guter letzt aber auch noch ein wirkliches problem: string- und character literals übersetzt cc65 so wie es der standard vorsieht beim kompilieren vom zeichensatz des hostsystems in den zeichensatz des zielsystems. dh petscii steuerzeichen in strings sind problematisch (die funktionieren zwar oft, weil cc65 beim übersetzen nur druckbare zeichen behandelt im moment - das kann sich in zukunft aber durchaus ohne vorherige ankündigung ändern). der hinweis auf die petscii tabelle ist daher auch eher suboptimal, denn im sourcecode wird ausschliesslich ascii benutzt (bzw erwartet).
      Das scheint mir so nicht ganz zu stimmen: Die "lustigen" Zeichen in PetSCII kann man eh nicht direkt eingeben, sondern nur als Integer. Und letztere sollte kein C-Compiler in irgendetwas konvertieren.

      sauhund schrieb:

      ich persönlich rate von eclipse ab, und zwar dringend :) mir ist selten so ein aufgeblasenes monster dahergekommen :)
      So aufgeblasen ist Eclipse gar nicht, wenn man es ein bisschen zurechtstutzt. Verwende meines im Wesentlichen für LaTeX und CVS, aber jedem Tierchen sein Pläsierchen.
      Für Anfänger würde ich aber auch erst mal zu Editor und Kommandozeile raten.

      sauhund schrieb:

      Bist du kein deutscher..., bisschen mehr tut gut.
      wenn du in der deutschen sprache weiterkommen willst solltest du mal ein gutes buch lesen (und weniger quatsch schreiben). jeder der programmiert und es nicht schon in der anfangsphase wieder hinwirft kommt irgendwann dahin das er mit anderen zusammenarbeiten will, den source von andren lesen oder seinen eigenen source anderen zum lesen geben möchte. und spätestens an der stelle ist es ein unschlagbarer vorteil wenn du deinen source auch jemandem zeigen kannst der kein deutsch kann. oder das du nicht erst polnisch lernen musst um einen source zu lesen der dich interessiert.
      Es kommt erschwerend hinzu, dass die C64-Gemeinde ja nicht mehr groß ist. Wenn man mit landessprachlichen Sourcen dann gleich mal drei Viertel oder mehr davon ausschließt, ist das äußerst blöde.

    • Das scheint mir so nicht ganz zu stimmen: Die "lustigen" Zeichen in PetSCII kann man eh nicht direkt eingeben, sondern nur als Integer. Und letztere sollte kein C-Compiler in irgendetwas konvertieren.


      du kannst string literals ja auch zb als hexcodes eingeben ( "\x00\x02\x05\x30" ) ... für den compiler macht das keinen unterschied, auch ein solcher string wird in den zielzeichensatz konvertiert. sprich:

      putchar(255); <- das wird natürlich NICHT konvertiert, da es kein string literal ist
      puts("\xff"); <- das wird sehr wohl konvertiert, da es sehr wohl ein string literal ist

    • genau aus dem grund steht in vielen styleguides diverser projekte das solche blöcke immer geklammert werden *müssen*.


      u.a. in unserer Firma

      einem anfänger sollte man das ruhig einfach komplett verschweigen das es auch ohne geht

      Das wäre etwas "unfair". Aber ich werde den Hinweis noch etwas verschärfen und die Beispielprogramme ab jetzt immer so verfassen (auch wenn ich es selbst nicht immer so mache).

      deutsch variablen- oder funktionsnamen. ihbähpfui. auch das sollte man garnicht erst zeigen, denn sonst wird das zur gewohnheit. es gibt nichts schlimmeres als in einem source rumguckn zu müssen wo die funktionen nach irgendeiner landessprache benannt sind die man nicht beherrscht. darum von anfang an: englisch.

      Sehe ich eigentlich ganauso. Private Sachen habe ich früher auch noch auf Deutsch kommentiert (aber natürlich schon immer englische Bezeichner!). Als ich aber dann von Zeit zu Zeit Teile davon doch weiter verwendet und veröffentlicht habe, musste ich die Kommentare übersetzen. Deshalb mache ich jetzt auch "private" Quelltexte durchgehend in Englisch.

      Bevor Schnucke wieder reinhaut: Ja, ich steht durchaus hinter einer gepflegten deutschen Sprache, was man hoffentlich an meinen Beiträgen hier sieht. Aber das Schlimmste ist ein wirres Sprachgemisch, wie es unweigerlich entsteht, wenn man deutsche Bezeichner und Kommentare in eine (englische) Programmiersprache einbaut.

      Der Kurs sollte am Anfang auch den Englisch-schwachen Leser entlasten wo es nur geht. Ich wollte auf Englisch umsteigen, sobald es die ersten "richtigen" Programme gibt. Nun, ohne Englisch kommt man in der C-Welt ohnehin nicht weit. Sonst sagt man wirklich noch solche Sachen wie "Kellerspeicher" :) Also werde ich das schon ab der nächsten Lektion so machen.

      Die vorhandenen Lektionen werde ich in der Hinsicht aus Zeitgründen erstmal so lassen.

      string- und character literals übersetzt cc65 so wie es der standard vorsieht beim kompilieren vom zeichensatz des hostsystems in den zeichensatz des zielsystems.

      Daran hatte ich nicht gedacht. Ich werde das prüfen und ändern.

      Der Codestyle ist etwas, worüber man sich keine Gedanken mehr machen muss, wenn man Eclipse benutzt.

      Ein Zimmermann wird auch erstmal lernen, mit dem Fuchsschwanz zu sägen, bevor er die Handkreissäge nimmt (das war ein schnucke-artiger Vergleich). Ich finde Eclipse inzwischen auch ganz gut (aber nur auf Rechnern mit viiiiiiiiiiiieeeel RAM), aber für einen Anfänger wirklich viel zu komplex. Ein einfacher Editor mit Syntax-Coloring sollte erstmal reichen, die meisten unterstützen die Formatierung auch rudimentär (z.B. nach <Enter> an die richtige Stelle zu springen) bis sehr gut (indent).

      eclipse benutzt dafür auch nur das commandline tool "indent" wenn ich mich recht erinner)

      Früher vielleicht. Jetzt nicht mehr. Früher konnte man Eclipse auch echt noch nicht wirklich benutzen, aber jetzt geht's langsam (wenn man sich eingearbeitet hat).

      wenn ich mit irgendwelchen SDKs arbeiten muss ist in der regel das erste was ich tue diesen eclipsemist loszuwerden und normale makefiles zu schreiben

      Das ist allerdings war. Ich benutze Eclipse auch nur mit selbstgeschriebenen Makefiles. M$ dsp u.s.w. nerven mich auch.

      Bist du kein deutscher..., bisschen mehr tut gut.

      Buaa, wiederlich.

      Wenn man mit landessprachlichen Sourcen dann gleich mal drei Viertel oder mehr davon ausschließt, ist das äußerst blöde.

      full ACK

      Danke für Eure Kommentare!
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

    • sauhund schrieb:

      Das scheint mir so nicht ganz zu stimmen: Die "lustigen" Zeichen in PetSCII kann man eh nicht direkt eingeben, sondern nur als Integer. Und letztere sollte kein C-Compiler in irgendetwas konvertieren.
      du kannst string literals ja auch zb als hexcodes eingeben ( "\x00\x02\x05\x30" ) ... für den compiler macht das keinen unterschied, auch ein solcher string wird in den zielzeichensatz konvertiert. sprich:

      putchar(255); <- das wird natürlich NICHT konvertiert, da es kein string literal ist
      puts("\xff"); <- das wird sehr wohl konvertiert, da es sehr wohl ein string literal ist
      OK, das mit den Hex- und Oktal-Escape-Sequenzen hatte ich irgendwie nicht mehr auf der Pfanne. Ich glaub' die habe ich noch nie gebraucht.

      Aber fürs Cross-Compiling auf den C64 wären sie schon ganz praktisch, wenn man mit den PetSCII-Eigenheiten arbeiten möchte (Farbe ändern, Grafikzeichen, etc.). Gerade das Zeichnen wird ja mit putchar für jedes einzelne Zeichen sehr anstrengend (ganz abgesehen davon, dass das jedesmal ein relativ teurer Funktionsaufruf ist).

      Also, der C99-Standard sagt dazu:

      C99-Standard, S. 60 (72 im PDF) schrieb:

      With a few exceptions detailed later, the elements of the sequence are any members of the source character set; they are mapped in an implementation-defined manner to members of the execution character set.
      Der cc65 darf das also machen, wie er will. Wäre nur nett, wenn das irgendwo dokumentiert wäre, damit man sich sicher sein kann, dass das eben nicht plötzlich geändert wird.

    • Also, der C99-Standard sagt dazu:


      der ist irrelevant, denn cc65 ist kein c99 compiler :)

      Der cc65 darf das also machen, wie er will. Wäre nur nett, wenn das irgendwo dokumentiert wäre, damit man sich sicher sein kann, dass das eben nicht plötzlich geändert wird.


      du kannst die zuordnung mittels #pragma charmap selber festlegen bzw ändern... wenn du derartige sachen machen willst empfiehlt sich genau das zu tun und sich nicht darauf zu verlassen was der compiler von sich aus macht. (auf die art kann man sogar dann das program - in grenzen - zwischen verschiedenen systemen portabel halten)

    • sauhund schrieb:

      Also, der C99-Standard sagt dazu:
      der ist irrelevant, denn cc65 ist kein c99 compiler :)
      Wenn Du ihn mit "--standard c99" aufrufst, schon. :P (Außerdem steht's IIRC in den alten Standards fast wörtlich genau so drin.)

      Was raten wir skoe nun, was er in den Kurs schreiben soll? Die pragma-Variante, obwohl der cc65 ja auch ohne macht, was gewünscht ist? Fette Warnung, dass es möglich wäre, dass irgendwann eine cc65-Version erscheint, die glaubt, dass wären schräge ISO- oder ASCII-Zeichen? Oder PetSCII ganz verschweigen und hoffen, dass die BASIC-Programmierer ihre Sonderzeichen, Farbumschaltungen, etc. schon nicht vermissen?

    • Wenn Du ihn mit "--standard c99" aufrufst, schon.


      ne, dann werden lediglich eine paar wenige c99 features erlaubt :) ein c99 compiler kann und will cc65 nicht sein

      Außerdem steht's IIRC in den alten Standards fast wörtlich genau so drin.


      stimmt =)

      Was raten wir skoe nun, was er in den Kurs schreiben soll? Die pragma-Variante, obwohl der cc65 ja auch ohne macht, was gewünscht ist? Fette Warnung, dass es möglich wäre, dass irgendwann eine cc65-Version erscheint, die glaubt, dass wären schräge ISO- oder ASCII-Zeichen? Oder PetSCII ganz verschweigen und hoffen, dass die BASIC-Programmierer ihre Sonderzeichen, Farbumschaltungen, etc. schon nicht vermissen?


      gute frage... ich würde aber dazu tendieren darauf hinzuweisen das man solche zeichen nicht benutzen sollte, schon weil sie höchst unportabel sind. und für alles andere gibt es auch bessere lösungen als steuerzeichen (wie zb die conio bibliothek).


    • putchar(255); <- das wird natürlich NICHT konvertiert, da es kein string literal ist
      puts("\xff"); <- das wird sehr wohl konvertiert, da es sehr wohl ein string literal ist


      Eigentlich sollten beide konvertiert werden (wenn für 255 eine sinnvolle Konviertierung implementiert ist). Folgende zwei Absätze aus dem Standard:

      Quellcode

      1. In a character constant or string literal, members of the execution character set shall be
      2. represented by corresponding members of the source character set or by escape
      3. sequences consisting of the backslash \ followed by one or more characters.


      Quellcode

      1. An integer character constant has type int. The value of an integer character constant
      2. containing a single character that maps to a single-byte execution character is the
      3. numerical value of the representation of the mapped character interpreted as an integer.


      Der Zweite ist etwas verworren. Das bedeutet, wenn ich im Source 'i' schreibe (ASCII 105) und in einem imaginären bekloppten Zielsystem ein i den Zeichencode 73 hat, dass dieses 'i' im Programm den Wert 73 verkörpert.

      Quellcode

      1. With a few exceptions detailed later, the elements of the sequence are any members of the source character set; they are mapped in an implementation-defined manner to members of the execution character set.


      Ich stimme zu, dass eine genaue Dokumentation dieses Mappings sinnvoll wäre. Das einzige, was kein Spielraum lässt, ist der basic character set aus dem Standard (a-z, A-Z, 0-9, ein paar wichtige Sonderzeichen und wenige Steuerzeichen). Da bleiben aber noch genügend andere Zeichen übrig.

      Solange sich noch niemand die Zeit genommen hat, mal nachzuschauen, was die cc65-Libs tatsächlich genau machen und solange das noch nicht dokumentiert ist (also "fest"), werde ich die Aussage im Kurs etwas zurücknehmen müssen.

      Für Steueraufgaben (Cursor-Bewegungen, Farben etc.) sind die Funktionen aus der conio sowieso besser geeignet, wenn auch mit ein paar Tücken. Die werden wir in einer der folgenden Episoden mal benutzen.

      Ich sehe gerade, während ich das schreibe, seit ihr zum gleichen Schluss gekommen :)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

    • Eigentlich sollten beide konvertiert werden (wenn für 255 eine sinnvolle Konviertierung implementiert ist).


      nene, da verstehst du was falsch. konvertiert werden nur zeichen- bzw stringkonstanten, also "abc" und 'a' ... integer bleiben natürlich immer wie sie sind, wie soll der compiler auch wissen das die 255 in dem obigen fall ein zeichencode ist? entweder ALLE integer werden konvertiert (was fatal wäre) oder keine :)

      Ich stimme zu, dass eine genaue Dokumentation dieses Mappings sinnvoll wäre. Das einzige, was kein Spielraum lässt, ist der basic character set aus dem Standard (a-z, A-Z, 0-9, ein paar wichtige Sonderzeichen und wenige Steuerzeichen). Da bleiben aber noch genügend andere Zeichen übrig.


      ich glaube der standard definiert das so das alle zeichen die in einem c source (ausserhalb von strings versteht sich) vorkommen können übersetzt werden. in etwa so macht es auch cc65.

      Solange sich noch niemand die Zeit genommen hat, mal nachzuschauen, was die cc65-Libs tatsächlich genau machen


      das machen nicht die libs sondern der compiler :) übersetze mit -t none und es findet keine derartige übersetzung statt.

      solange das noch nicht dokumentiert ist (also "fest"),


      Uz wird sich hüten das weiter als nötig zu dokumentieren, denn wie gesagt, das ist "Implementation defined". ein program das sich darauf verlässt ist.... kaputt =) und wer sich dennoch auf eine spezielle übersetzungstabelle verlassen will kann die mit dem pragma festnageln, dafür gibts diese option ja.

    • sauhund schrieb:

      Wenn Du ihn mit "--standard c99" aufrufst, schon.
      ne, dann werden lediglich eine paar wenige c99 features erlaubt :) ein c99 compiler kann und will cc65 nicht sein
      Das liest sich aber auf der cc65-Seite doch ein bisschen anders:

      cc65-Homepage schrieb:

      The compiler is almost ISO C compatible, ...

      sauhund schrieb:

      ich würde aber dazu tendieren darauf hinzuweisen das man solche zeichen nicht benutzen sollte, schon weil sie höchst unportabel sind.
      Nur als Verständnisfrage: Meinst Du Portabilität auf andere 8-Bit-Systeme? Weil, Portabilität von und zu Linux oder Windows ist kaum erreichbar, schon weil C-Programme dort in der Regel eine mächtige Kommandozeile oder Grafik voraussetzen. Bei Demos etc. ist mit Portieren sowieso Sense.

      sauhund schrieb:

      und für alles andere gibt es auch bessere lösungen als steuerzeichen (wie zb die conio bibliothek).
      Das ist das viel stärkere Argument: Macht man nicht mit Steuerzeichen, wenn das viel besser über in Assembler implementierte Bibliotheken geht.

      skoe schrieb:

      Der Zweite ist etwas verworren. Das bedeutet, wenn ich im Source 'i' schreibe (ASCII 105) und in einem imaginären bekloppten Zielsystem ein i den Zeichencode 73 hat, dass dieses 'i' im Programm den Wert 73 verkörpert.
      So bekloppt muss das Zielsystem gar nicht sein. Der CeVi reicht völlig aus. Bei dem sind nämlich im lowercase/uppercase-Modus (den cc65 ja benutzt) Groß- und Kleinbuchstaben gegenüber ASCII/ISO/UTF vertauscht. Aus 'i' (ASCII/ISO/UTF $69) muss also $49 in PetSCII gemacht werden.

      skoe schrieb:

      Das einzige, was kein Spielraum lässt, ist der basic character set aus dem Standard (a-z, A-Z, 0-9, ein paar wichtige Sonderzeichen und wenige Steuerzeichen).
      Übrigens ein Punkt, wo der cc65 keine Möglichkeit hat, wirklich standardkonform zu sein. Der Standard verlangt unter anderem {, } und \ im "execution character set" (für einen C-Standard eigentlich sehr verständlich). Die hat der CeVi aber gar nicht.

      Grüße,
      heptasean

    • So, ich hab mal die nötigen Änderungen in Abend3 und Abend4 eingebaut. Wer die Änderungen sehen möchte, kann auf "Ältere Versionen" für ein diff klicken.

      Ach, jetzt sehe ich es erst:

      putchar(255); <- das wird natürlich NICHT konvertiert, da es kein string literal ist


      Mensch, sorry! Hatte irgendwie '\xff' "gelesen" und im Kopf gehabt. Also da das eine "Ganzzahkonstante" ist, wird natürlich nichts konvertiert.

      Das ist mir aber peinlich, werde oben noch einen Hinweis dazuschreiben, wenn ich noch kann. edit: Huaaa, ich kann das nicht mehr editieren. Jetzt muss der Quatsch de bis in alle Ewigkeit stehen bleiben :( /edit

      nene, da verstehst du was falsch. konvertiert werden nur zeichen- bzw stringkonstanten, also "abc" und 'a' ... integer bleiben natürlich immer wie sie sind


      Sowas traust Du mir zu?! :) Nein, das hab ich nicht falsch verstanden sondern missverständlich erklärt. Es hätte heißen müssen: "Ein String oder eine Zeichenkonstante, die ein Zeichen mit dem Code 255 enthalten".

      das machen nicht die libs sondern der compiler :)


      Stimmt, ist logisch. Hab ich schneller getippt als gedacht.

      Übrigens ein Punkt, wo der cc65 keine Möglichkeit hat, wirklich standardkonform zu sein. Der Standard verlangt unter anderem {, } und \ im "execution character set" (für einen C-Standard eigentlich sehr verständlich). Die hat der CeVi aber gar nicht.


      Da sind wir zum gleichen Schluss gekommen: So in etwa habe ich es gerade im Kurs geändert.
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

    • Das liest sich aber auf der cc65-Seite doch ein bisschen anders: Zitat von »cc65-Homepage«
      The compiler is almost ISO C compatible, ...


      ISO-C != C99 :) (auch ältere standards sind "iso-c". c99 fordert zb auch so sachen wie wchar, was auf den 8bittern mal total sinnfrei ist :))

      Nur als Verständnisfrage: Meinst Du Portabilität auf andere 8-Bit-Systeme? Weil, Portabilität von und zu Linux oder Windows ist kaum erreichbar


      öh, klar ist die erreichbar. das man dann keine sachen benutzen darf die irgendwelche systemspezifischen dinge (wie grafik oder sound) benutzen ist klar :) aber zb mein schonmal erwähntes tetris lässt sich für alles mögliche kompilieren, c64 oder windows oder auch gamecube, total egal :) ein anderes beispiel wo derartige portabilität erreicht wurde wäre contiki. oder der texteditor von "wings". oder oder oder... da gibts schon einige beispiele :)

    • sauhund schrieb:

      Das liest sich aber auf der cc65-Seite doch ein bisschen anders: Zitat von »cc65-Homepage«
      The compiler is almost ISO C compatible, ...
      ISO-C != C99 :) (auch ältere standards sind "iso-c". c99 fordert zb auch so sachen wie wchar, was auf den 8bittern mal total sinnfrei ist :))
      Dann wäre es nett zu erfahren, auf welches ISO-C sich Uz da bezieht. Da an Parametern für "--standard" nur "cc65" (das ist nicht ISO ;)), "c89" (das ist ANSI, nicht ISO) und "c99" (das einzige ISO-C in der Reihe) zur Verfügung stehen, war ich davon ausgegangen, dass er letzteres meint. ...

      sauhund schrieb:

      öh, klar ist die erreichbar. das man dann keine sachen benutzen darf die irgendwelche systemspezifischen dinge (wie grafik oder sound) benutzen ist klar :) aber zb mein schonmal erwähntes tetris lässt sich für alles mögliche kompilieren, c64 oder windows oder auch gamecube, total egal :) ein anderes beispiel wo derartige portabilität erreicht wurde wäre contiki. oder der texteditor von "wings". oder oder oder... da gibts schon einige beispiele :)
      OK, OK, OK, habe mich (mal wieder) geirrt. Die einfachsten Dinge, die ich so in C geschrieben habe, waren ganz einfache Filter. Die scheitern auf dem CeVi schon an der Shell, um die entsprechenden Pipelines zu definieren. An solche Beispiele wie Deine hatte ich jetzt nicht gedacht.

      Trotzdem würde ich im Kurs eher über die "geht schöner (conio o.ä.)"-Schiene argumentieren. Sonst kommt tatsächlich einer an und sagt: "Will doch nur Demos proggen. Die sind eh nicht portabel."