Hallo Besucher, der Thread wurde 9,6k mal aufgerufen und enthält 23 Antworten

letzter Beitrag von sauhund am

C-Kurs, Verbesserungsvorschläge für Abend 2

  • Ich mach den Thread mal auf, damit sich (eventuell/hoffentlich) kommende Fragen von Schülern nicht mit den Diskussionen vermischen. Der C-lernende ist wahrscheinlich nicht sonderlich an unserem technomechanisch-philosophioschen Gedankenaustausch interessiert, sondern eher an den Ergebnissen davon.


    Wenn man die Hämmungen abbauen möchte, C zu lernen um vom schrecklichen BASIC wegzukommen, können solche Diskussionen vielleicht sogar demotivierend sein. Also tun wir's hier:


    Die Anmerkungen von sauhund:
    > fussnoten sollten jeweils nach jedem abschnitt und nicht gaaaaaaaaaaaaaaanz weit
    > unten auf der seite stehen. das nervt :)
    Ja, ich bin mit der Wiki-Engine auch noch nicht ganz zufrieden. Dazu mache ich nacher einen anderen Thread auf. Inzwischen kann der Leser ja auf die Fußnote klicken, kommt an's Ende der Seite, klickt da nochmal, kommt wieder zurück zum Text. Oder zeigt mit der Maus auf die Fußnote und liest das aufpoppende Textdingelchen. Besser als nüscht.


    > bezüglich kommentaren fehlt mir der hinweis das c++-style kommentare zwar von
    > vielerlei compilern geschluckt werden, ABER es oft trotzdem sinnvoll ist auf diese
    > zu verzichten, sofern man auf portabilität wert legt.
    Du hast aber genau die Stellen gefunden, über die ich auch eine Weile nachgedacht habe.
    Bei dem Thema kann man ganz klar (mindestens) die zwei Standpunkt identifizieren:


    a) C90 & co kennt noch keine "//"-Kommentare. Es gibt viele Projekte, die C90 annehmen und deshalb C99-Kommentare verbieten. Man sollte der Portierbarkeit halber auf sie verzichten.


    b) C99 standardisiert "//"-Kommentare. Schon vor 1999 haben sehr viele Compiler (oder darf ich sagen: die meisten?) diese Kommentare erlaubt, wenn man es ihnen nicht explizit per Schalter verboten hatte. Bei kurzen Kommentaren ist "//" einfach praktischer.


    Ich persönlich halte b) nicht für schlechten Stil. Bei fremden Projekten passe ich mich allerdings auch auf a) an (z.B. in meiner Firma).


    Wenn Du Dir zum Beispiel den Linux-Kernel ansiehst: In dem ist IIRC "//" auch verboten, andererseits ist der nur auf GCC und auf sehr wenigen anderen Compilern übersetzbar (und auch nur weil die sich viel Mühe dafür geben). Ist doch Heuchelei.


    Beim Vice hingegen kann ich es verstehen, weil der auch auf Plattformen kompilierbar ist, wo es nur Steinzeitcompiler gibt.


    Aber nichts desto trotz ist an dem Einwurf was dran. Ich werde mal versuchen, den Text so anzupassen, dass dem Leser das klar wird.


    > "Zwischen Anweisungen mitten in einem Block können beim cc65 keine weiteren Definitionen folgen."
    > würde ich anders formulieren, besagtes verhalten hat nämlich nichts mit cc65 sondern dem unterstützten
    > c standard zu tun. (allgemein sollte es selten bis nie nötig sein auf cc65 spezifisch bezug zu nehmen, das
    > verwirrt nur)
    Auch ein gutes Thema.


    Ich persönlich definiere meine Variablen in C immer an Anfang der Funktion. Ist bei mir eine Sache des Stils. (Bei C++ ggfs. am Anfang des jeweiligen Blocks, damit Konstruktoren von Objekten nur ausgeführt werden, wenn sie auch tatsächlich benutzt werden)


    Andere sagen, die Definition sollte aus Stilgründen so dicht wie möglich an der ersten Verwendung sein.


    Ehrlich gesagt war ich echt überrascht, dass die Definitionen fast an beliebiger Stelle stehen dürfen. Dachte immer, das sei nur in C++ so, und in C nur am Blockanfang (und for(...)). Fazit: So ganz glücklich bin ich mit dem Absatz auch noch nicht. Jetzt werde ich doch tatsächlich mal in die Standards sehen. Die älteren sind aber schwer zu finden. Und selbst im C99 habe ich noch nicht die richtigen Stellen gefunden.


    Ich war übrigens der Meinung, mich mit C gut auszukennen. Aber in den letzten Tagen bestätigt sich wiedermal: Man lernt immer was dazu. So lohnt sich der Kurs auch für mich.

  • Erstes Indiz gefunden, ich zitiere Wikipedia:

    Zitat


    Zu den wichtigsten Neuerungen [von C99] gehören:
    [...]
    Frei platzierbare Deklaration von Bezeichnern (in C90 durften diese nur am Anfang eines Blocks stehen).


    Aber verlässlicher ist natürlich der Standard. Den nehme ich mir jetzt vor.

  • Aber verlässlicher ist natürlich der Standard. Den nehme ich mir jetzt vor.


    nach http://david.tribble.com/text/cdiffs.htm#C90-mixed-decl-stmt ist [C99: §6.8.2] relevant


  • Bleibt doch beim ersten Standart und wühlt nicht immer wieder was neue-altes heraus was alles wieder über den Haufen wirft.
    Sonst steigt da bald keiner durch. Es gibt in "C" keinen einheitlichen Standart mehr. :nixwiss:


    Macht diesen Kursus so, wie ihr ihn für richtig haltet nach euren Standart. :winke: und bleibt endlich bei einem Kurs.


    mfg

  • Da fängt einer mal an, endlich gut diesem cc65 zu erkären...und schon nach 2 Tagen ist der ganze Kursus schon wieder zerissen und zerbeutelt. Gebt doch eure Kommentare als PN weiter an dem Autor. :bia


    Es wird nur immer über diese Syntax geredet und diese Syntax vom "C-Standart", aber wenige haben sich mal damit befasst das dieses "C" was wir behandeln auch mal mit guten Beispielen gefüllt wird für den c64/c128/Plus4.


    Schaut euch hier um, wieviel zahlreiche funktionelle Beispiele es hier im Forum gibt für den cc65... :nixwiss:


    ftp://ftp.musoftware.de/pub/uz/cc65/contrib/


    3 Programme 2007, 4 Programme 2008 .....das spricht für sich.


    Soll das alles sein, vielleicht sollte man garnicht weitermachen, es gibt mit mir 3 weitere Anfänger die sich dafür brennend interessieren.


    In 5 Tagen Redet keiner mehr vom cc65 . Wenn der Schnee weg ist, ist auch das interesse weg.


    Heut ist wegen dem Sauwetter die Interessenlage gross, wir sprechen uns wieder.
    Morgen stell ich noch Fragen vielleicht noch ein 2ter oder 3.ter


    mfg

  • Zitat

    Da fängt einer mal an, endlich gut diesem cc65 zu erkären...und schon nach 2 Tagen ist der ganze Kursus schon wieder zerissen und zerbeutelt. Gebt doch eure Kommentare als PN weiter an dem Autor.


    guck doch mal was in der überschrift dieses threads hier steht


    Zitat

    Es wird nur immer über diese Syntax geredet und diese Syntax vom "C-Standart", aber wenige haben sich mal damit befasst das dieses "C" was wir behandeln auch mal mit guten Beispielen gefüllt wird für den c64/c128/Plus4.


    das wird sicher noch kommen. aber an "tag 2" eines kurses zu erwarten das es schon tolle beispielprogramme gibt die wohlmöglich gar noch was sinnvolles machen ist vielleicht *etwas* zu viel erwartet.


    Zitat

    3 Programme 2007, 4 Programme 2008 .....das spricht für sich.


    in wiefern? was hat diese ftp bzw die downloads da mit dem kurs hier zu tun?

  • Moment mal, schnucke


    Ich glaub, Du blickst nicht ganz durch: In diesem Thread wurde konstruktiv über Verbesserungsvorschläge gesprochen, die zum größten Teil auch auf die eine oder andere Art im Kurs eingeflossen sind. Noch vorhandene Wissenslücken z.B. über die Unterschiede zw. den StandarDs sind untersucht und geklärt worde. Auch die sind dann in den Kurs mit eingeflossen.


    Ein Dankeschön an ogd, sauhund und unseen, die dazu beigetragen haben.


    Nur wegen deinen merkwürdigen Bemerkungen kratzt sich sicher noch der eine oder andere am Kopf.

  • Etwas kürzer fassen im Beschreibungstext.
    Es wird sich zu sehr an dem Nebensächlichkeiten aufgehalten.


    Die Vorbereitungsgrundsätze um den Speicherbereich zu versetzen.
    Eine Lib-datei erstellen und die c64-lib damit erweiten.
    ASM einbinden....Inline...


    Also Grundsätzlich mehr auf die spezialitäten vom cc65 eingehen. Laden/Speichern von Programmen usw mit den Befehlen der Computertypen.


    Funktionen auslagern, Definitionen auslagern, Header anlegen. Nicht alles in einem Programm reinstopfen. Grundvorraussetzung.

  • Der geneigt Leser möchte sicher erstmal ein paar solide Grundkenntnisse erwerben, bevor er sich mit Halbwissen auf's eingemachte stürzt. Wer noch nie C-Syntax gesehen hat, wird kaum eine Lib erstellen wollen.


    > Etwas kürzer fassen im Beschreibungstext.
    Genau den Eindruck hinterlässt Du bei mir. Möglichst nur ein paar Worte, ja nichts genau durchlesen...