Am Mittwoch, 1. Dezember 2004 18:23 schrieb Falk Döring:
[falk@Voyager C]$ gcc -lreadline read.c /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/../../../libreadline.so:
(...)
Was wollen mir diese Fehlermeldungen sagen? Muss ich noch weitere Bibliotheken beim compilieren mit angeben? Die Beispiele zu readline lassen sich erst recht nicht compilieren, können mir also auch nicht weiterhelfen. (readline.h ist in diesem Ordner zu finden!)
Die libreadline benötigt libncurses. Generell gilt, daß Bibliotheken die ihrerseits genutzten Bibliotheken mit verlinkt haben müssen, da man als Nutzer die Details nicht kennen müssen will. Das ist bei Debian auch der Fall, also wohl ein Mandrakefehler.
Frage 2: Wie bekomme ich bei Funktionen optionale Parameter (in C) hin?
Den Prototyp als foo() deklarieren ohne void dazwischen - dann ist laut C-Standard alles erlaubt. Wenn du aber im Stil von printf() variable Argumente möchtest, dann geht das über Ellipsen.
void foo(const char *fmt, ...) { va_list ap; va_start(ap, fmt); mache_was_mit_fmt_und_ap(); va_end(ap); }
Frage 3: Worin besteht der Unterschied zwischen den Standard-C-Funktionen (bzw. den Basistypen) gegenüber denen von glib? (Einer meiner Profs hat ein C-Programm geschrieben, in dem er diese Bibliothek genutzt hat, obwohl alles auch in "normal"-C verfügbar wäre.) Gibt es solche auch bei KDE (würde mich wundern, da KDE m.e. in C++ geschrieben ist)?
GLib-Datentypen sind komisch ineinander gecastete structs, welche erst global mit g_type_init() initialisiert werden müssen, sonst gibt es einen bösen Absturz. Oftmals aber haben die structs nur einen Datentyp in sich, welcher dann wieder ein C-Standardtyp wie int oder char* ist (gint, gchar*). Bei KDE gibt es so einen Schotter bestimmt nicht. Entweder man nimmt in Kauf, daß C-Implementierungen über Systemgrenzen hinweg inkompatibel sind, und konzentriert sich auf Basistypen wie int oder char. Oder man programmiert in einer Sprache, die nicht 30+ Jahre mit diversen venderspezifischen Eigenheiten auf dem Buckel hat. Skriptsprachen sind sehr empfehlenswert.
Beispiel: Auf PowerPC ist 'char' unsigned, während er auf x86 'signed' ist. Das ist eine gcc-Konvention, andere Compiler können das anders handhaben. Es gibt einen gcc-Schalter um das abzuändern (-fsigned-char). Alternativ kann man auch immer explizit 'signed'/'unsigned' davorschreiben.
Beispiel 2: Mesa (OpenGL-Implementierung) nutzt GLfloat, GLint etc. Das sind aber nur Bezeichnungen, so wie es auch im Kernel ulong_t, uchar16 oder ähnliches gibt. Wer's braucht... :) Auf Anwendungsebene finde ich so etwas Quatsch.
Frage 4: Gibt es eine gute Internet-Adresse, wo ich mich im Falle solcher Fragen informieren kann? (Die ANSI-C-Bestimmungen werden ja bestimmt nicht offen im Web verfügbar sein, zumindest hat mein gegoogle nichts gefunden.)
http://www.python.org/ http://www.ruby-lang.org/ http://www.smalltalk.org/ http://www.haskell.org/ etc.
Josef