UNIXwork

Im Gegensatz zu C++ oder vielen anderen Sprachen unterstützt C keine Default Values für Funktionsparameter. Auch ein Sprachkonstrukt wie Named Parameters, welches es z.B. in Python gibt, kennt C nicht.

Häufig wird als Workaround dafür Variadic Parameters verwendet, z.B. laut Linux-Manpage gibt es den open-Syscall in zwei Varianten:

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);

In Wahrheit sieht die Signatur allerdings so aus:

int open(const char *pathname, int flags, ...);

Das funktioniert grundsätzlich, hat jedoch den Nachteil, dass für alle zusätzlichen optionalen Parameter keine Typüberprüfung stattfindet.

Es gibt jedoch eine Alternative die sich Compound Literale für structs bemächtigt. Die Idee ist, dass alle Parameter an die Funktion per struct übergeben werden. Damit es wie ein normaler Funktionsaufruf aussieht, wird das ganze als Makro hübsch verpackt, welches die Makro-Parameter zu einem Compound Literal macht.

#include <stdio.h>

typedef struct {
	int a;
	int b;
	int c;
} TestFuncArgs;

#define testfunc(...) testfunc_f((TestFuncArgs){ __VA_ARGS__})

void testfunc_f(TestFuncArgs args) {
	printf("a: %d   b: %d   c: %d\n", args.a, args.b, args.c);
}

int main(int argc, char** argv) {
	testfunc(1, 2, 3);
	testfunc(4, 5);
	testfunc(.a = 10, .c = 20);

	//testfunc("hello"); //warning

	return 0;
}

Hier findet für alle Parameter eine Typüberprüfung statt und zusätzlich gibt es auch die Option, Designated Initializers zu verwenden, daher anstatt die struct-Werte als einfache Liste in richtiger Reihenfolge anzugeben, kann auch einfach der Feldname angegeben werden.

Es gibt im Jahr 2021 absolut keinen Grund mehr, Latin-1 bzw. ISO 8859-1 und dergleichen zu benutzen. Verwendet gefälligst UTF-8 oder eine der anderen Kodierungen für Unicode. Wer noch Latin-1 oder ähnliches benutzt, der macht etwas falsch. Es gibt keinen Verwendungszweck dafür. Unicode wird dieses Jahr 30 Jahre alt. UTF-8 gibt es seit 1996. Unterstützung dafür gibt es in Betriebsystemen und Anwendersoftware dafür bestimmt seit 20 Jahren. Wenn irgendwelche Software heutzutage kein Unicode kann, dann ist das ein schwerwiegender Mangel. Wer auf solche Software angewiesen ist, der sollte sich mal nach Alternativen umsehen.

Es ist besorgniserregend, wie oft ich bei XNEdit irgendwelche Anfragen kriege, ob ich nicht irgendwelche Encoding-Features implementieren könnte. Zum Beispiel passt manchen Leuten offenbar UTF-8 als Default nicht. Auch wenn ich sowas jetzt immer implementiert habe, finde ich das einfach nur falsch. Einfach für alle Textdateien UTF-8 benutzen oder UTF-16 mit Byte Order Mark, wenn es sich anbietet.

Damit dies nicht ein völlig unkonstruktiver Rant ist, gibt es hier noch eine kleine Hilfe, um falsch kodierte Dateien zu finden.

find . -type f -name "*" -exec file --mime-encoding {} \; | grep -v "utf\|ascii\|binary"

Bei Bedarf statt * einen Filter einsetzen, damit nicht zu viele Dateien unnötig überprüft werden. Das ganze liefert euch eine Liste der Dateien, die ihr besser umkodieren solltet. Das Umkodieren macht dieser Oneliner jedoch nicht, das muss manuell oder mit einem extra Script gemacht werden, das ich jetzt hier nicht mitliefern wollte, da die Liste hoffentlich eh nur aus bedauerlichen Einzelfällen bestehen wird.

Finde den Syntax-Fehler in folgendem C-Code:

#include <stdio.h>

int main(int argc, char **argv) {
	int a = 3;
	switch(a) {
		case 1:
			printf("1\n");
			break;
		case 2:
			printf("2\n");
			int c2 = 0;
			break;
		case 3:
			int c3 = 3;
			printf("%d\n", c3);
			break;
	}
	return 0;
}

Ein ähnlicher Fall wie hier im Beispiel hatte sich bei mir zugetragen. Der Compiler bemängelte die Variablendeklaration nach dem Case. Das heißt, hier im Beispiel ist die fehlerhafte Zeile die Variablendeklaration im Case 3.

Ich gebe zu, dass mich dies erstmal verwirrt hat und ich dachte, ich hätte versehentlich im C90-Modus kompiliert. Der Grund, wieso dies einen Fehler wirft, ist, dass ein Case nichts anderes als ein Label ist und Variablendeklarationen in C nicht mit einem Label versehen werden können.

Für das gelegentliche Rechnen liefern die meisten Desktops irgendeine Art von Calculator-Anwendung und aus irgend einem Grund imitieren diese meistens Taschenrechner aus dem Real-Life, und zwar immer diese billigen Teile die nichts können. Besonders nervig ist, dass diese immer nur Zwischenergebnisse anzeigen und man nicht eine längere Expression eingeben kann die dann auch mathematisch korrekt ausgewertet wird.

Neben all den unbrauchbaren Rechnern, wie der von Windows oder macOS, aber auch diverse aus dem Open Source Lager, gibt es auch einige positive Beispiele, z.B. war ich eigentlich ganz zufrieden mit dem Gnome Calculator. Da ich allerdings Gnome nicht mehr benutze musste Ersatz her. Meinen inneren Drang alles selbst zu programmieren konnte ich glücklicherweise unterdrücken und meine Wahl viel auf SpeedCrunch.

SpeedCrunch ist eine QT-Anwendung und auf allen gängigen Plattformen verfügbar. Das Interface ist eher minimalistisch, standardmäßig werden gar keine Buttons für die Ziffern und Operatoren angezeigt, weil man das ja auch nicht braucht, die Berechnung kann wesentlich effizienter direkt über die Tastatur eingegeben werden.

Praktischerweise hat man dann auch einen Verlauf der bisherigen Berechnungen.

Natürlich hat SpeedCrunch dann auch alle möglichen erweiterten Features: Variablen, Konstanten, Funktionen, Einheiten und eine Formelsammlung. Natürlich kann man auch Binär-, Oktal und Hexadezimalzahlen ein- und ausgeben.

Also insgesammt alle Features die man so braucht und mehr, verpackt in einem wesentlich sinnvolleren GUI-Konzept.

Installieren kann man SpeedCrunch auf vielen Distributionen direkt über die Paketverwaltung, ansonsten gibt es auf der Webseite Downloads.

Dieser Empfehlung kann ich mich nur anschließen.

Kontext