Fragen und Antworten zum C-Kurs

[Paul]

Das würde man in C ähnlich wie in TurboPascal mit gotoxy(10, 14); machen - normalerweise...

Code: Alles auswählen

#include <stdio.h>

void gotoXY(unsigned int x, unsigned int y) {
    putchar(27);        // ESC
    putchar('Y');       // cursor to position
    putchar(y + 32);    // row + 32
    putchar(x + 32);    // column + 32
}

int main(void) {
    gotoXY(10, 14);
    putchar('O'); // oder printf("%s", "O");
}

Ganz ganz herzlichen Dank Bernd!!!

[kurt]

Dieses Pointer-Geschäft bei C ist ein echtes Minenfeld. Im Grunde nicht kompliziert, aber man muß aufpassen, sonst platz die Bombe.

Ich habe ein ganz anderes Problem: HTC kennt die Kommentar-Einleitung mit den 2 '//' nicht. Kann man dem Preprozessor per Makro irgendwie verklickern, diese Art von Kommentar bei der Vorverarbeitung des Programms/include-Dateien einfach zu löschen ? Noch sind die Beispiele kurz, aber sobald sie länger werden ist es mühsam, diese Korrektur jedesmal von Hand zu erledigen. Weiterer Grund: Bei meiner eigenen Grafik-Bibliothek sind diese Art der Kommetare in den Files reichlich vorhanden, was die Übertragung nach HTC recht mühsam werden läßt.

[bbock]

Ja, die Pointer haben's in sich; deswegen sind sie in manchen modernen Programmiersprachen wie Java - ein C-Abkömmling - gar nicht erst verfügbar. Man kann viel Unheil mit ihnen anrichten. Aber sie sind eben auch ein mächtiges Werkzeug.

Die Umwandlung der Kommentare via Präprozessor ist meines Wissens nicht möglich. Man könnte aber ein (gar nicht mal so kompliziertes) Programm schreiben, das nach "//" sucht, durch "/*" ersetzt, dann den darauffolgenden Zeilenumbruch sucht (Achtung: betriebssystemabhängig!) und vor diesem ein "*/" einfügt. Das können wir mal aufgreifen, wenn wir zur Dateiverarbeitung kommen.

[kurt]

>>Das können wir mal aufgreifen, wenn wir zur Dateiverarbeitung kommen.
Ja, wäre super. Dann kann man sich mit eigenen 'Verbesserungen' daran austoben.

Das Thema ließe sich richtig ausbauen. Z. B., was ist zu tun, wenn ein mehrzeiliger Kommentar eröffnet, aber nicht bis zum Ende der eröffnenden Zeile durch ein '*/' geschlossen wird und zu allem Überfluß innerhalb des Kommentares '//' am Textanfang auftreten. Das ermöglicht es, alle bisher angesprochenen Kontrollstrukturen etc. auf den Plan zu rufen. Das wird interessant werden.

[Paul]

Nur zur Info: ich habe nicht das Handtuch geworfen.
Durch meine Krankheit bedingt hinke ich etwas hinterher, hole das aber nach sobald mein Kopf wieder klarer ist!

[bbock]

Hallo Paul,
ich wünsche dir gute Besserung! Schade, das wir uns dieses Wochenende nicht sehen werden.

[Paul]

Ja, das ist echt bitter.

[kurt]

Ups, mein letztes Lebenszeichen ist auch schon 7 Tage her, trotzdem kein Müßiggang: Mein Sohn will sich unbedingt für sein Mini-ITX Board per 3D-Druck ein eigenes Gehäuse bauen, ist beim 3D-CAD aber Neueinsteiger. Ihm die notwendigen Tipps per Schnellkurs zu vermitteln hält halt auf. Daneben hängt jetzt an meiner 2ten Velleman-Joyce eine Joyce Original-Tastatur. Das hat mich 2 Tage an gefrickel gekostet, da in den Serviceunterlagen die Pin-Belegung des DIN-4 Steckers nicht mit der Realität üereinstmmt, mal davon abgesehen, das die vor einem Jahr beschafften DIN-4 Kupplungen auf wundersame Weise verschwunden sind und neu beschafft werden mußten. Ich hoffe mal, das ich die Doku dazu heute abend noch fertig bekomme und ins Forum stellen kann (ansonsten im Laufe des Wochenendes). Alles Kleinkram, hält aber erstaunlich lange auf.

Ich gelobe Besserung - soweit möglich ...

[kurt]

Eine Frage zu den Aufzählungstype und der Art wie TRUE u. FALSE als logisches Flag erzeugt werden. Man sieht auch häufig die Zu.-Fuß-Methode:

Code: Alles auswählen

TRUE  = 0;
FALSE = ~TRUE;

Ich nehme mal an, daß das persönlicher Programmierstil ist. Mir würde dieser Weg auch mehr zusprechen, da der logische Zusammenhang klarer ausformuliert ist (bin halt mehr Hardware-Fritze, FALSE ist nun mal das inverse von TRUE).

Im Kapitel Strukturen bein ersten Code-Beispiel steht:

Code: Alles auswählen

struct struct Book {

Da ist sicherlich ein "struct" zu viel. Gemeint ist sicherlich:

Code: Alles auswählen

struct Book {

denn sonst würde "struct" als Struktur "Book" definiert werden, was sicherlich nicht beabsichtigt ist (wie im 2ten Code-Beispiel gezeigt).

Ich habe im 3ten Code-Beispiel zur Buch-Struktur einmal den ersten Text-String verdreifacht. Der HT-C Compiler meckert jedenfalls nicht, wenn die zuzuweisende (statische) Zeichenkette länger ist wie der dafür resevierte Speicher. Ist das generell so, das vom Compiler hier nichts kommt, obwohl er das erkennen könnte ? ist im Grunde kein Beinbruch, ist sicher besser Eingabetexte auf max. Länge zu kontrollieren, aber bei statische Sachen sollte der Compiler aufmucken (also gewissenmaßen Copy-und-Paste Fehler abfangen, denn statische Zeichenketten zählt man selten nach).

[bbock]

Eine Frage zu den Aufzählungstype und der Art wie TRUE u. FALSE als logisches Flag erzeugt werden. Man sieht auch häufig die Zu.-Fuß-Methode:

Code: Alles auswählen

TRUE  = 0;
FALSE = ~TRUE;

Ich nehme mal an, daß das persönlicher Programmierstil ist. Mir würde dieser Weg auch mehr zusprechen, da der logische Zusammenhang klarer ausformuliert ist (bin halt mehr Hardware-Fritze, FALSE ist nun mal das inverse von TRUE).

In C gibt es einen Datentyp bool erst ab C99. Er ist in stdbool.h als Makro definiert; der eigentliche Datentyp heißt _Bool. Die boole'schen Werte true und false (wohlgemerkt klein geschrieben) sind in derselben Header-Datei definiert. Vor C99 kann man prinzipiell nach Gusto vorgehen. false oder FALSE werden üblicherweise als 0 definiert, true oder TRUE als 1 oder -1 - Hauptsache ungleich 0. Deine Variante ist ausgesprochen unüblich. Eher würde man FALSE = 0 und TRUE = ~FALSE definieren. Damit wäre TRUE die bitweise Negation von 0, was einer -1 gleichkommt.

Im Kapitel Strukturen bein ersten Code-Beispiel steht:

Code: Alles auswählen

struct struct Book {

Da ist sicherlich ein "struct" zu viel. Gemeint ist sicherlich:

Code: Alles auswählen

struct Book {

denn sonst würde "struct" als Struktur "Book" definiert werden, was sicherlich nicht beabsichtigt ist (wie im 2ten Code-Beispiel gezeigt).

Danke für den Hinweis; ich habe es korrigiert.

Ich habe im 3ten Code-Beispiel zur Buch-Struktur einmal den ersten Text-String verdreifacht. Der HT-C Compiler meckert jedenfalls nicht, wenn die zuzuweisende (statische) Zeichenkette länger ist wie der dafür resevierte Speicher. Ist das generell so, das vom Compiler hier nichts kommt, obwohl er das erkennen könnte ? ist im Grunde kein Beinbruch, ist sicher besser Eingabetexte auf max. Länge zu kontrollieren, aber bei statische Sachen sollte der Compiler aufmucken (also gewissenmaßen Copy-und-Paste Fehler abfangen, denn statische Zeichenketten zählt man selten nach).

In C wird bei der Array-Indizierung keine Prüfung durchgeführt - weder beim Kompilieren noch zur Laufzeit. Die Verantwortung liegt hier beim Programmierer, was zu einer häufigen Fehlerquelle führt. Pascal prüft standardmäßig die Indexgrenzen, was aber zu Lasten der Performance geht (deshalb kann man die Prüfung auch per Compiler-Schalter deaktivieren). Es sei noch darauf hingewiesen, dass es in string.h neben strcpy auch die Funktion strncpy gibt, die über einen zusätzlichen Parameter eine Begrenzung der Anzahl kopierter Zeichen sicherstellt. Sie ist insbesondere dann wichtig, wenn man nicht sicherstellen kann, dass der zu kopierende String die Länge des Ziel-Arrays nicht überschreitet. Beim Kopieren von String-Konstanten benutzt man aus Effizienzgründen lieber strcpy.