C-Kurs, Abend 4 - Verbesserungsvorschläge

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

- deutsch variablen- oder funktionsnamen. ihbähpfui.

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. Nach dem Motto: ....auch wir können etwas...und es wird mehr....

mfg

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

mfg

Zitat

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.

Zitat

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.

Zitat

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.

Zitat von sauhund

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.

Zitat von sauhund

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.

Zitat von sauhund

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.

Zitat

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

Zitat von sauhund

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:

Zitat von C99-Standard, S. 60 (72 im PDF)

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.

Zitat

Also, der C99-Standard sagt dazu:

der ist irrelevant, denn cc65 ist kein c99 compiler

Zitat

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)

Zitat von sauhund

der ist irrelevant, denn cc65 ist kein c99 compiler

Wenn Du ihn mit "--standard c99" aufrufst, schon. (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?

Zitat

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

Zitat

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

stimmt

Zitat

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).

Zitat

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

Zitat

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.

Zitat

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.

Zitat

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.

Zitat von sauhund

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:

Zitat von cc65-Homepage

The compiler is almost ISO C compatible, ...

Zitat von sauhund

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.

Zitat von sauhund

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.

Zitat von skoe

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.

Zitat von skoe

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

Zitat

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 :))

Zitat

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

Zitat von sauhund

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. ...

Zitat von sauhund

ö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."