JK-Wiki edv:prg:c:tipp

edv:prg:c:tipp:big-endian_und_little-endian

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:15+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Big-Endian und Little-Endian ======

	+	Eine umfangreiche Beschreibung zum Thema findet man auf der Seite von Jürgen Wolf:\\ [[http://pronix.linuxdelta.de/C/standard_C/c_programmierung_19_3.shtml]]
	+
	+	Hier ist eine kleine Zitat aus dem durch den o.g. Link referenzierten Text:
	+
	+	Little-Endian und Big-Endian unterscheiden sich durch die Anordnung des most significant byte und des least significant byte. Bei einer Word-Größe der CPU von vier Bytes wird das rechte Ende als least significant byte und das linke Ende als most significant byte bezeichnet. Das least significant byte stellt dabei die niedrigeren Werte und das most significant byte die größeren Werte in einem Word dar.
	+
	+	Als Beispiel dient jetzt folgende Hex-Zahl:
	+
	+	22CCDDEE
	+
	+	Auf den unterschiedlichen Systemen wird diese Hex-Zahl im Speicher folgendermaßen abgelegt:
	+
	+	^Adresse ^0x12345^0x12346^0x12347^0x12348^
	+	\|Big-Endian \|22 \|CC \|DD \|EE \|
	+	\|Little-Endian \|EE \|DD \|CC \|22 \|
	+
	+	Wie man herausfindet, auf was für einem System das Programm ausgeführt wird, wird mit einem [[http://pronix.linuxdelta.de/C/standard_C/c_programmierung_19_3.shtml\|Beispiel]] (§19.17.3) unter dem o.g. Link erklärt.
	+
	+	Zu den Little-Endian-Systemen gehören z.B.:
	+
	+	* Intel CPUs (x86, x64 bzw. x86_x64)
	+	* DEC Alpha
	+	* VAX
	+
	+	Und einige Big-Endian-Systeme:
	+
	+	* Motorola MC68000 (Amiga, Atari)
	+	* SPARC CPUs (SUN)
	+	* IBM PowerPC
	+
	+	Quelle: [[http://pronix.linuxdelta.de/C/standard_C/c_programmierung_19_3.shtml]] (von Jürgen Wolf)
	+
	+	Byte- und Bit-Order, CPU IA-32 (little endian):\\
	+	{{:edv:prg:c:tipp:byte-_und_bit-order.cpu_ia-32_little_endian_.png\|Byte- und Bit-Order, CPU IA-32 (little endian)}}
	+	Quelle: [[http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-2a-manual.html]]
	+
	+	Hier ist ein Beispiel, wie man prüft welches Endianess das System hat (der Code muss auf dem Zielsystem übersetzt werden):
	+
	+	<code c>
	+	#include <stdio.h>
	+
	+	#define is_bigendian() (((char)&i) == 0)
	+
	+	int main (void)
	+	{
	+	const int i = 1;
	+
	+	printf("Endianess = %s-Endian\n", is_bigendian() ? "BIG" : "LITTLE");
	+
	+	return 0;
	+	} // main()
	+	</code>
	+
	+	----
	+	Stand: 06.09.2016
	+
	+	EOF

edv:prg:c:tipp:client-server_mit_threads

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:14+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Client-Server mit Threads ======

	+	Während der Programmierung eines SocketServers bin ich zu folgenden Schlüssen gekommen:
	+
	+	===== MultiThread SocketServer =====
	+
	+	Bei MultiThread SocketServern (und insbesondere bei mehreren gebundenen Ports) den Ablauf auf 4 statt 3 Phasen unterteilen:
	+
	+	* Init (Requests werden gar nicht angenommen)
	+	* Running (Requests werden normal beantwortet)
	+	* - FadeOut (neue Requests werden mit einer "soft"-Fehlermeldung beantwortet)
	+	* Done (Requests werden gar nicht mehr angenommen, Sockets geschlossen)
	+
	+	Die Unterphase FadeOut dauert solange, bis alle Threads komplett abgearbeitet bzw. nach dem TimeOut "gecancelt" sind.
	+
	+	===== Buffers =====
	+
	+	Buffers für Request, Response und Steuervariablen als eine ganze Struktur definieren um keine mehreren Speicherfunktionen (etwa malloc(), free(), etc.) behandeln zu müssen. Falls es mehrere Arten von Requests behandelt werden müssen, alle Einzelstrukturen in eine Union zusammenfassen. Somit ist jedesmal nur ein einziger Aufruf zur "Allocierung" und Freigabe vom Speicher nötig.
	+
	+	Hinweis 1: Bei einem MultiThread-Betrieb diese Struktur nicht als lokale Variablen einer Funktion definieren! Es sei denn, die Struktur ist ganz klein und somit vernachlässigbar.
	+
	+	Grund: Lokale Variablen werden im Stack zur Laufzeit abgelegt. Im MultiThread-Betrieb kann es zum Stacküberlauf führen, falls die Anzahl der Threads groß werden sollte. Man sollte die obere Grenze der Anzahl der Threads möglichst im voraus festlegen. Es wird bei 32-Bit CPUs im Stack standardmäßig 1MB Speicher pro Thread reserviert (bei 64-Bit CPUs - 2MB).
	+
	+	Hinweis 2: Innerhalb der Struktur sollen mehrere Statusfelder definiert werden, die den aktuellen Status der Nachricht widerspiegeln und zwar aus mehreren Sichten: technische (separat für Hard- und Soft-Fehlern) und inhaltliche. Hard-Fehler (z.B. statusHFC genannt) sind Fehler, wenn die Kommunikation nicht einwandfrei funktioniert (z.B. Requests ohne Daten, TimeOuts beim Empfang, etc.). Soft-Fehler (z.B. statusSFC genannt) sind Fehler, wenn die Kommunikation auf der physischen Ebene einwandfrei funktioniert, die Daten aber nicht zusammen passen, im falschen Format vorliegen, korrupt sind. Mit anderen Worten, die Daten sind zwar vorhanden, können aber nicht ausgewertet bzw. verarbeitet werden. Inhaltliche Statusinformationen stellen eine kurze Zusammenfassung des Datenzustandes bzw. des Ergebnisses dar.
	+
	+	===== Pool =====
	+
	+	Alle Threads zu einem Pool zusammenfassen (mit zu "pthread_t" zusätzlichen Attributen wie "active", "TimeStamp_Start", "TimeOut") und einige Funktionen zur Pool-Verwaltung definieren. Das wären etwa "getNextFreeThread()", "getActiveThreadsCount()", "setThreadAsActive()", "setThreadAsInactive()", "cleanInactiveThreads()", "cancelTimeoutedThreads()" und "killAllThreads()".\\
	+	Der Funktion "setThreadAsActive()" als Parameter TimeOut übergeben. Die "getNextFreeThread()" soll am Anfang (bei Bedarf) die "cleanInactiveThreads()" aufrufen um erst die inaktiven frei zu geben (sonst stehen sie nicht zur Verfügung). Die "cleanInactiveThreads()" soll am Anfang (bei Bedarf) die "cancelTimeoutedThreads()" aufrufen um erst die inaktiven zu ermitteln.
	+
	+	Hinweis 3: Die Pool-Verwaltung selbst soll aber nicht in einem Thread laufen, sondern im Mutterprozeß. Auch deren (Pool-Verwaltungs) Variablen dürfen nicht durch die Schreibzugriffe aus den Threads beeinflußt werden. Die Variablen selbst sollen als volatile deklariert werden.
	+
	+	Grund: Die meisten Prozeduren sind nicht atomar, was fatale Folgen haben kann, wenn sie aus den Threads aufgerufen werden. Die Pool-Verwaltung selbst als Thread würde Gefahr eingehen, zu Opfer einer DeadLock-Falle unter den Threads zu fallen.
	+
	+	Um die Effizienz der Speicherverwaltung eines SocketServers bedeutend zu erhöhen, ist es ratsam statt für jede einzelne Request Speicher zu reservieren, ein Pool für N Requests (soll dynamisch bzw. durch Parameter änderbar sein) zu reservieren (z.B. mit calloc() mit N+1 Elementen, wobei das Element 0 die Steuerstruktur der eigenen Speicherverwaltung selbst ist) und es selbst zu verwalten.
	+
	+	Grund: malloc() für jeden Requeset separat "kostet" viel Ressourcen. Wenn die Strukturen für alle Requests/Response gleich groß definiert werden (s. oben), lassen sie sich in einem Array zusammenfassen und leicht verwalten. Overhead dabei ist minimal: Block ist belegt / Block ist frei.
	+
	+	===== Senden =====
	+
	+	Beim Senden beachten, daß bei einem Sendevorgang nicht unbedingt alle Daten auf einmal gesendet werden müssen/können. Daher ist es ratsam, den Sendevorgang in eine Schleife einzuschließen:
	+
	+	<code c>
	+	int rc;
	+	int fdSocketOfPeer; // Socket (Filedescriptor) zur Gegenstelle
	+	int bytesZumSenden;
	+	int bytesGesendet;
	+	char * sendeBuffer; // Daten zum Wegschreiben
	+
	+	bytesGesendet = 0; // noch keine Bytes gesendet
	+	rc = 0;
	+	while ((bytesGesendet < bytesZumSenden) && !(rc == -1)) // solange noch nicht alle Zeichen gesendet
	+	{
	+	rc = send(fdSocketOfPeer, sendeBuffer + bytesGesendet, bytesZumSenden - bytesGesendet, 0);
	+	if (rc > 0) bytesGesendet += rc;
	+	} // while
	+	</code>
	+
	+	An dieser Stelle ist ein Versuchszähler oder eine Prüfung auf TimeOut natürlich ratsam.
	+
	+	===== Lesen =====
	+
	+	Das gilt auch fürs Lesen - nicht unbedingt alle Daten auf einmal gelesen werden müssen/können (es können noch welche unterwegs sein, die zum selben Request gehören).
	+
	+	Das TimeOut beim Lesen kann man beispielsweise so prüfen:
	+
	+	<code c>
	+	int fdSocketOfPeer; // Socket (Filedescriptor) zur Gegenstelle
	+	int timeOutSocket;
	+	time_t timeStamp1, timeStamp2;
	+	double vorgangsDauer;
	+
	+	readCount = 0; // es wurde noch nichts gelesen
	+	vorgangsDauer = 0;
	+	time(&timeStamp1); // TimeStamp davor ermitteln
	+	while ((readCount == 0) && (vorgangsDauer < timeOutSocket)) // nur bis zum TimeOut
	+	{
	+	readCount = recv(fdSocketOfPeer, tmpSocketBuffer, sizeof(tmpSocketBuffer), 0); // aus dem Socket lesen
	+	time(&timeStamp2); // TimeStamp danach ermitteln
	+	vorgangsDauer = difftime(timeStamp2, timeStamp1); // Dauer des Vorgangs
	+	} // while
	+	</code>
	+
	+	An dieser Stelle ist ein kurzes sleep() für den Fall, daß nicht alle Daten auf einmal gelesen worden sind, natürlich ratsam*.
	+
	+	** Vorsicht:* Bei sleep() unbedingt darauf zu achten bzw. zu klären, ob nicht der gesamte Prozeß samt aller Threads in den Schlaf versetzt wird. Bei einem sleep(), welches auf die Threads wartet, wäre es sinnlos.
	+
	+	Hinweis 4: Er ist ratsam, im Hauptprozeß eine allgemeine idle()-Funktion zu definieren, die bei erforderlichen kurzen Wartezeiten aufgerufen wird. Die Funktion selbst besitzt keine Funktionalität, außer sie soll weitere Funktionen aufrufen, die diverse Aufräum-Aktivitäten ausführen, insbesondere im Bezug auf Threads-Verwaltung (Suchen nach beendeten Threads, Beenden von Threads, deren TeimOut abgelaufen ist, Freigeben von Resssourcen, rtc.).\\
	+	Diese Funktion könnte auch regelmäßig in einem extra dafür erzeugten Thread (quasi GarbageCollector) aufgerufen werden. Aber Vorsicht (sehe den Hinweis 3)!
	+
	+	Hinweis 5: Er ist ratsam, bei den Funktionen, deren Laufzeit nicht vorhersehbar bzw. durch externe Ereignisse/Zustände beeinflußbar ist, das TimeOut und/oder den maximalen Versuchszähler als Parameter mit zu übergeben.
	+
	+	Beispiel:
	+
	+	<code c>
	+	int initSocket (int port, int backlogs, int * fdSocketOnServer, int maxTimeOut, int maxAttempt, int delayAttempt)
	+	</code>
	+
	+	wobei:
	+
	+	Eingabeparameter:\\
	+	"port" - die zu bindende Portnummer
	+	"backlogs" - Anzahl Requests, die gepuffert werden sollen, falls der Socket nicht leer ist
	+	"maxTimeOut" - maximale Dauer bis der Listener initialisiert worden sein soll (0 = unendlich)
	+	"maxAttempt" - maximale Versuchszahl den Port zu binden (0 = unendlich)
	+	"delayAttempt" - Verzögerung zwischen den Versuchen den Port zu binden (0 = keine Verzögerung)
	+
	+	Ausgabeparameter:\\
	+	"fdSocketOnServer" - FileDescriptor des geöffneten (Master-)Sockets (-1 = Fehler)
	+
	+	Hinweis 6: Beim Kompilieren unbedingt Direktiven und Compiler-Parameter für den Multithreadfähigen Code beachten. Stichwort REENTRANT, Reenterable.
	+
	+	Hinweis 7: Bei der Verwendung von Copy-Funktionen zwischen den Buffern ist Vorsicht wegen den Sonderzeichen geboten. Die sicherere Funktion ist memcpy() und nicht die strncpy(), da die letztere bei z.B. einem 0-Byte abbrechen würde. Beim Ermitteln der Größe des ausgelesenen Strings ist auf strlen() kein Verlaß (aus dem selben Grund).
	+
	+	Weitere Infos:
	+	man poll
	+
	+	===== Vor-/Nachteile: =====
	+
	+	Vorteil: Da die Requests parallel abgearbeitet werden, können keine Staus entstehen.\\
	+	Nachteil: Die Syncronisation (Semaphore), aber nur falls erforderlich, ist kompliziert. Gefahr von DeadLocks oder durch Zombie-Semaphore (von abgebrochenen Threads/Prozessen).
	+
	+	==== MultiThreads: ====
	+
	+	Vorteil: Threads können über gemeinsame Variablen miteinander kommunizieren. Ressourceschonender, da alles unter einer einzigen PID läuft.\\
	+	Nachteil: Threads können durch Nutzung von gemeinsamen Variablen in die Quere kommen. Der Hauptprozeß muß sich über die Thread-Verwaltung selber kümmern. Einzelne Threads kann man nicht (direkt) von außen steuern.
	+
	+	==== MultiProzeß: ====
	+
	+	Vorteil: Saubere Trennung unter den SohnProzessen. Die Prozeß-Verwaltung übernimmt das Betriebssystem.\\
	+	Nachteil: Interprozeßkommunikation ist umständlicher (z.B. per Shared Memory).
	+
	+	===== Weitere Schritte (ToDo): =====
	+
	+	Eine allgemeine SocketServer Vorlage erstellen.
	+
	+	Vorhaben:
	+	* Mehrere Ports binden.
	+	* Mehrere Threads oder Sohn-Prozesse.
	+	* Kein Warten durch accept(), sondern poll() oder select() verwenden. Dabei zu beachten, daß select() zwar bequemer ist, kann aber nur eine begrenzte Zahl (1024 :?:) von Sockets verkraften. Es liegt an der Steuerstruktur, die vom select() benutzt wird.
	+	* Unterstützung von IPv4 und IPv6.
	+
	+	===== Links zum Thema: =====
	+
	+	* Netzwerkprogrammierung mit Sockets (von Ulrich Vogel) - einfach: [[http://www.uvomatik.de/programmierung/sockdoc/]]
	+	* Client-Server Socketprogrammierung (von Arnold Willemer) - wertvoll: [[http://www.willemer.de/informatik/unix/unprsock.htm]]
	+	* Poll: Lesen von mehreren Filedeskriptoren (von Prof. Schweiggert und Dr. J.Mayer mit H.Braxmeier und C.Ehrhardt):\\ [[http://www.mathematik.uni-ulm.de/sai/ss04/soft/uebungen/blatt06/html/blatt06.ps]]
	+	* Parallele Programmierung mit Threads (Jürgen Wolf: Linux/Unix-Systemprogrammierung):\\ [[http://pronix.linuxdelta.de/C/Linuxprogrammierung/Linuxsystemprogrammieren_C_Kurs_Kapitel8.shtml]]
	+	* Die grundlegenden Funktionen zur Thread–Programmierung (Jürgen Wolf: Linux-UNIX-Programmierung, Das umfassende Handbuch – 2., aktualisierte und erweiterte Auflage 2006):\\ [[http://openbook.galileocomputing.de/linux_unix_programmierung/Kap10-004.htm]]
	+	* Mit den POSIX-Threads programmieren (Jürgen Wolf: C von A bis Z, Das umfassende Handbuch - 3., aktualisierte und erweiterte Auflage):\\ [[http://openbook.galileocomputing.de/c_von_a_bis_z/026_c_paralleles_rechnen_004.htm]]
	+
	+	----
	+	Stand: 20.04.2007 - in Arbeit\\
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF

edv:prg:c:tipp:einbetten_von_versionsinformationen

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:15+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Einbetten von Versionsinformationen ======

	+	FIXME
	+
	+	Es ist sinnvoll, die Versionsnummer in einem separaten h-File unterzubringen und dieses File nach dem Muster "programmname_version.h" zu benennen. Hier ein Beispiel für die Version "1.2.3.4":
	+
	+	<code c>
	+	#define VERSION_MAJOR 1
	+	#define VERSION_MINOR 2
	+	#define VERSION_REVISION 3
	+	#define VERSION_BUILD /@INCREMENT@/4
	+	</code>
	+
	+	Die Versionsnummer setzt sich wie folgt zusammen:
	+
	+	<code c>
	+	#define APP_VERSION VERSION_MAJOR.VERSION_MINOR.VERSION_REVISION.VERSION_BUILD
	+	</code>
	+
	+	Statt %%VERSION_REVISION%% kommt noch häufig %%VERSION_PATCH%% vor. Hier ein Beispiel für die Definition als Strings:
	+
	+	<code c>
	+	#define VERSION_MAJOR "1"
	+	#define VERSION_MINOR "2"
	+	#define VERSION_PATCH "3"
	+	#define VERSION_BUILD "4"
	+	</code>
	+
	+	Zusammensetzung als String:
	+
	+	<code c>
	+	#define APP_VERSION VERSION_MAJOR "." VERSION_MINOR "." VERSION_PATCH "." VERSION_BUILD
	+	</code>
	+
	+	Verwendung z.B. in "main.c":
	+
	+	<code c>
	+	static char app_version[] = APP_VERSION;
	+	</code>
	+
	+	FIXME
	+
	+	In MS VisualStudio steht eine Möglichkeit zur Verfügung, die Versionsnummers samt weiteren Angaben, die das Programm beschreiben, in die ".exe"- und ".dll"-Files einzubetten. Eine sehr anschauliche Beschreibung mit weiteren Tipps (z.B. wegen Unicode) findet man hier:\\ [[https://www.zachburlingame.com/2011/02/versioning-a-native-cc-binary-with-visual-studio/]]
	+
	+	Hier ist eine kurze Zusammenfassung aus der o.g. URL, welche Schritte dafür erforderlich sind. In VS:
	+	* Schritt 1: Hinzufügen von Version-Resource\\ 1. Rechtsklick (im Solution-Explorer) auf das Projekt.\\ 2. Auswählen: "Add" -> "Resource" -> "Version" -> "New"\\ Ergebnis: 2x Files: resource.h und <project_name>.rc.\\ (Es wird empfolen, das ".rc"-File umzubenennen in z.B. "version.rc" oder "<project_name>_version.rc".)
	+	* Schritt 2: Die "version.rc" editieren\\ 1. Rechtsklick (im Solution-Explorer) auf das version.rc.\\ 2. Auswählen: "Open With" -> "C++ Source Code Editor" -> nach unten skrollen bis zur Sektion "Version". Hier ist ein Beispiel für den Inhalt:<code>/////////////////////////////////////////////////////////////////////////////
	+	//
	+	// Version
	+	//
	+	VS_VERSION_INFO VERSIONINFO
	+	FILEVERSION VER_FILE_VERSION
	+	PRODUCTVERSION VER_PRODUCT_VERSION
	+	FILEFLAGSMASK 0x3fL
	+	FILEFLAGS VER_FILEFLAGS
	+	FILEOS VER_FILEOS
	+	FILETYPE VER_FILETYPE
	+	FILESUBTYPE 0x0L
	+	BEGIN
	+	BLOCK "StringFileInfo"
	+	BEGIN
	+	BLOCK "040904b0"
	+	BEGIN
	+	VALUE "FileDescription", VER_FILE_DESCRIPTION_STR "\0"
	+	VALUE "FileVersion", VER_FILE_VERSION_STR "\0"
	+	VALUE "InternalName", VER_INTERNAL_NAME_STR "\0"
	+	VALUE "LegalCopyright", VER_COPYRIGHT_STR "\0"
	+	VALUE "OriginalFilename", VER_ORIGINAL_FILENAME_STR "\0"
	+	VALUE "ProductName", VER_PRODUCTNAME_STR
	+	VALUE "ProductVersion", VER_PRODUCT_VERSION_STR "\0"
	+	END
	+	END
	+	BLOCK "VarFileInfo"
	+	BEGIN
	+	VALUE "Translation", 0x409, 1200
	+	END
	+	END</code>
	+	* Schritt 3: Version Header hinfügen\\ Als Nächstes wird ein File namens version.h erstellt, um einen Speicherort für die verschiedenen Versionsinformationen bereitzustellen. Dies ist besonders nützlich, wenn die Versionsinformationen über mehrere Projekte innerhalb einer Solution übergreifend sein sollen. <code c>
	+	#define STRINGIZE2(s) #s
	+	#define STRINGIZE(s) STRINGIZE2(s)
	+
	+	#define VERSION_MAJOR 1
	+	#define VERSION_MINOR 0
	+	#define VERSION_REVISION 0
	+	#define VERSION_BUILD 0
	+
	+	#define VER_FILE_DESCRIPTION_STR "Description"
	+	#define VER_FILE_VERSION VERSION_MAJOR, VERSION_MINOR, VERSION_REVISION, VERSION_BUILD
	+	#define VER_FILE_VERSION_STR STRINGIZE(VERSION_MAJOR) \
	+	"." STRINGIZE(VERSION_MINOR) \
	+	"." STRINGIZE(VERSION_REVISION) \
	+	"." STRINGIZE(VERSION_BUILD) \
	+
	+	#define VER_PRODUCTNAME_STR "c_version_binary"
	+	#define VER_PRODUCT_VERSION VER_FILE_VERSION
	+	#define VER_PRODUCT_VERSION_STR VER_FILE_VERSION_STR
	+	#define VER_ORIGINAL_FILENAME_STR VER_PRODUCTNAME_STR ".exe"
	+	#define VER_INTERNAL_NAME_STR VER_ORIGINAL_FILENAME_STR
	+	#define VER_COPYRIGHT_STR "Copyright (C) 2011"
	+
	+	#ifdef _DEBUG
	+	#define VER_VER_DEBUG VS_FF_DEBUG
	+	#else
	+	#define VER_VER_DEBUG 0
	+	#endif
	+
	+	#define VER_FILEOS VOS_NT_WINDOWS32
	+	#define VER_FILEFLAGS VER_VER_DEBUG
	+	#define VER_FILETYPE VFT_APP
	+	</code>
	+	* Schritt 4: "version.h" in "version.rc" einbinden\\ <code c>
	+	// Microsoft Visual C++ generated resource script.
	+	//
	+	#include "resource.h"
	+	#include "version.h"
	+
	+	#define APSTUDIO_READONLY_SYMBOLS
	+	</code>
	+
	+	:!: In der o.g. URL wird auch erklärt, wie man dabei mit Unicode-Strings umgeht.
	+
	+	----
	+	Stand: 24.10.2019
	+
	+	EOF

edv:prg:c:tipp:errno

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:14+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== errno ======

	+	Bei errno gibt es keinen einheitlichen Standard. In einigen Implementierungen ist es eine int-Variable, in den anderen ist es ein Makro.
	+
	+	Folgendes konnte ich beim Debuggen von Programmen feststellen:
	+
	+	Unter Sun Solaris hatte ich mit der Variable <code c>int errno;</code> zu tun. Die Funktionen, wie z.B. atoi(), legen dort den ErrorCode ab oder 0 bei Erfolg. D.h., durch die Auswertung der Variable %%errno%% kann man feststellen, ob die zuletzt aufgerufene %%atoi()%% (oder andere Funktion, die %%errno%% nutzt) erfolgreich war.
	+
	+	<code c>
	+	#include <errno.h>
	+
	+	int main()
	+	{
	+	char szEineZahlAlsString[] = "12345";
	+	int iEineZahlAlsInteger = 0;
	+
	+	iEineZahlAlsInteger = atoi(szEineZahlAlsString);
	+	if (errno == EINVAL \|\| errno == ERANGE) printf("Fehler beim atoi(), errno = [%d]\n", errno);
	+
	+	printf("szEineZahlAlsString = [%s], iEineZahlAlsInteger = [%d]\n", szEineZahlAlsString, iEineZahlAlsInteger);
	+
	+	return 0;
	+	} // main()
	+	</code>
	+
	+	Unter MS VisualStudio 2010 hatte ich mit dem Makro <code c>#define errno (*_errno())</code> zu tun. Falls eine "fehlgeschlagene" Funktion dort einen Fehlerwert abspeichert, setzt die nächste "erfolgreiche" Funktion diesen Fehlerwert u.U. nicht zurück! Als work around funktioniert, wann man vor den Funktionen wie %%atoi()%% manuell %%errno%% auf 0 zurücksetzt.
	+
	+	Auszug aus dem Kapitel ERRNO(3) (Linux Programmer's Manual): [[http://man7.org/linux/man-pages/man3/errno.3.html]]
	+	* //errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared; errno may be a macro. errno is thread-local; setting it in one thread does not affect its value in any other thread.//
	+	* //It was common in traditional C to declare errno manually (i.e., extern int errno) instead of including <errno.h>. Do not do this. It will not work with modern versions of the C library. However, on (very) old UNIX systems, there may be no <errno.h> and the declaration is needed.//
	+
	+	__Weitere Infos:__\\
	+	IBM: [[http://www.ibm.com/developerworks/aix/library/au-errnovariable/\|Errors: errno in UNIX programs]]\\
	+	MS: [[http://msdn.microsoft.com/de-de/library/t3ayayh1%28v=vs.100%29.aspx\|errno, _doserrno, _sys_errlist, and _sys_nerr]] (MSDN, Visual Studio 2010)\\
	+
	+	----
	+	Stand: 07.06.2016\\
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF

edv:prg:c:tipp:funktionen_mit_variabler_anzahl_von_parameter

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:16+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Funktionen mit variabler Anzahl von Parameter ======

	+	:?: Wie schreibe ich eine Funktion, die, wie z.B. die printf(), eine variable Anzahl von Parameter hat?
	+
	+	(Als Grundlage für dieses Beispiel wurde [[http://pronix.linuxdelta.de/C/standard_C/c_programmierung_21.shtml]] von [[http://pronix.linuxdelta.de/impressum/index.shtml\|Jürgen Wolf]] genutzt.)
	+
	+	Die printf() ist wie folgt deklariert:
	+
	+	<code c>
	+	int printf(const char *format, ...);
	+	</code>
	+
	+	Um solche Funktionen wie printf() zu schreiben sind folgende Makros aus %%<stdarg.h>%% nötig:
	+
	+	^Makro ^Syntax ^Kommentar ^
	+	\|va_list \|va_list name; \|Abstrakter Datentyp, mit dem die Liste der Parameter definiert wird. \|
	+	\|va_start \|va_start(va_list name, lastarg); \|Argumentliste wird initialisiert. \|
	+	\|va_arg \|typ = va_arg(va_list name,typ); \|Liest den nächsten Parameter in der Argumentliste. \|
	+	\|va_end \|void va_end(va_list name); \|Schließt die Argumentliste. \|
	+
	+	Als erstes Beispiel, eine Funktion, die das Ende der Parameterliste an einem bestimmten Wert erkennt.
	+
	+	<code c>
	+	#include <stdio.h>
	+	#include <stdarg.h>
	+
	+	int addInt (int iZahlen, ...) // Berechnet die Summe aller als Parameter angegebenen Zahlen
	+	{
	+	va_list pParameter;
	+	int iAktuelleZahl;
	+
	+	va_start(pParameter, iZahlen); // Pointer auf den 1. Parameter setzen
	+
	+	do
	+	{
	+	iAktuelleZahl = va_arg(pParameter, int);
	+	iZahlen += iAktuelleZahl;
	+	} while (iAktuelleZahl != 0); // Die Zahl 0 dient als Begrenzer der Zahlenreihe
	+
	+	va_end(pParameter);
	+	return iZahlen;
	+	} // addInt()
	+
	+	int main ()
	+	{
	+	int iSumme;
	+
	+	printf("1 + 3 + 8 = %d\n", addInt(1, 3, 8, 0));
	+
	+	iSumme = addInt(10, 15, 27, 0) + addInt(3, 13, 33, 0);
	+
	+	printf("(10 + 15 + 27) + (3 + 13 + 33) = %d\n", iSumme);
	+
	+	return 0;
	+	} // main()
	+	</code>
	+
	+	Als zweites Beispiel, eine Funktion, die die Anzahl der (restlichen) Parameter als Wert im ersten Parameter übergibt.
	+
	+	<code c>
	+	#include <stdio.h>
	+	#include <stdarg.h>
	+
	+	void printInt (int iAnzahl, ...)
	+	{
	+	va_list pParameter;
	+	int iAktuelleZahl;
	+	int i;
	+
	+	printf("Es werden %d Zahlen ausgegeben:\n", iAnzahl);
	+	va_start(pParameter, iAnzahl); // Pointer auf den 1. Parameter setzen
	+	for (i = 1; i <= iAnzahl; i++)
	+	{
	+	iAktuelleZahl = va_arg(pParameter, int);
	+	printf("%d\t", iAktuelleZahl);
	+	} // for
	+	printf("\n");
	+	va_end(pParameter);
	+	} // printInt()
	+
	+	int main ()
	+	{
	+	printInt(4, 1, 2, 3, 4); // 4 Zahlen ausgeben (1 + 4 Parameter)
	+	printInt(6, 11, 22, 33, 44, 55, 66); // 6 Zahlen ausgeben (1 + 6 Parameter)
	+
	+	return 0;
	+	} // main()
	+	</code>
	+
	+	In diesem Zusammenhang sind die Funktionen vprintf(), vsprintf() und vfsprintf() von Interesse.
	+
	+	FIXME
	+
	+	----
	+	Stand: 21.11.2012
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF

edv:prg:c:tipp:makros-kollisionen

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:15+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Makros-Kollisionen ======

	+	Häufig hat man die Situation, dass auf einer Seite sich einige Makros gegenseitig ausschließen, aber auf der anderen Seite eins davon obligatorisch ist.
	+
	+	Zum Beispiel, das Programm verwendet eine Datenbank - entweder die DB2 oder Informix oder MySQL oder Oracle oder geht über ODBC. Über die Makros (beispielsweise DB_DB2, DB_INFORMIX, DB_MYSQL, DB_ORACLE, DB_ODBC) steuert man, welche Code-Abschnitte je nach verwendete DB kompiliert werden sollen.
	+
	+	Das heißt:
	+	* Mindestens eins von diesen Makros muss definiert sein
	+	* Nur eins von diesen Makros gleichzeitig darf definiert sein und nicht mehr
	+
	+	Hier ist ein Beispiel, wie man zur Kompilierungszeit prüft, ob die o.g. Bedingungen erfüllt sind (Big- und Little-Endian schließen sich gegenseitig aus):
	+
	+	<code c>
	+	#undef BYTE_ORDER // 1 = big-endian, -1 = little-endian, 0 = unknown
	+
	+	#if defined ARCH_IS_BIG_ENDIAN
	+	#define BYTE_ORDER (ARCH_IS_BIG_ENDIAN ? 1 : -1)
	+	#elif defined ARCH_IS_LITTLE_ENDIAN
	+	#define BYTE_ORDER -1
	+	#else
	+	#define BYTE_ORDER 0
	+	#endif
	+
	+
	+	// ARCH_IS_BIG_ENDIAN und ARCH_IS_LITTLE_ENDIAN dürfen nicht beide gleichzeitig definiert sein.
	+	#if defined ARCH_IS_BIG_ENDIAN && defined ARCH_IS_LITTLE_ENDIAN
	+	#error Nur eine der beiden Definitionen (ARCH_IS_BIG_ENDIAN, ARCH_IS_LITTLE_ENDIAN) erlaubt
	+	#endif
	+
	+	// Eine davon muss jedoch definiert sein.
	+	#if !defined ARCH_IS_BIG_ENDIAN && !defined ARCH_IS_LITTLE_ENDIAN
	+	#error Mindestens eine der beiden Definitionen (ARCH_IS_BIG_ENDIAN, ARCH_IS_LITTLE_ENDIAN) muss definiert sein
	+	#endif
	+	</code>
	+
	+	----
	+	Stand: 27.01.2016
	+
	+	EOF

edv:prg:c:tipp:namenskonflikte_loesen_die_durch_die_verwendung_externer_libraries_mit_gleichbenannten_funktionen_entstehen

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:16+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Namenskonflikte lösen, die durch die Verwendung externer Libraries mit gleichbenannten Funktionen entstehen ======

	+	(Am Beispiel für eine Windows-Anwendung oder DLL, hier im Text als "APP-01" genannt.)
	+
	+	===== Ausgangssituation / Vorhaben: =====
	+
	+	Ursprünglich wurde der Windows-Zweig von APP-01 im Bezug auf die verwendete DB in 2x Ausprägungen gebaut: 1x für die DB-Verbindung über den DB2-Client und 1x über ODBC (wobei die Verbindung über ODBC wiederum über den DB2-Client abläuft, also "verkettet").
	+	Um die Anzahl der Ausprägungen zu reduzieren und auch für den Fall vorsorgen, wenn in Zukunft weitere/andere Datenbanken dazu kommen, wurde entschieden, die beiden DB-Zweige unter einem Dach unterzubringen. Der Anwendung soll es dann möglich sein, über Parameter/Konfiguration zu steuern, über welchen DB-Zweig die DB-Verbindung zustande kommen soll.
	+
	+
	+	===== Problem: =====
	+
	+	Bei dem 1. Versuch, das o.g. Vorhaben umzusetzen, ist ein schwerwiegendes Problem aufgetaucht, und zwar folgendes:
	+
	+	Die Import-Libraries von dem DB2-Client ("db2cli.lib") und ODBC ("odbc32.lib" und "odbccp32.lib") exportieren eine Großzahl an Funktionen, die sich im Namen teilweise überschneiden. Hier sind einige Beispiele:
	+	^DB2-Library ^ODBC-Library ^
	+	\|SQLAllocHandle() \|SQLAllocEnv()\\ SQLAllocConnect()\\ SQLAllocStmt() \|
	+	\|SQLConnect() \|SQLDriverConnect() \|
	+	\| <html><span style="color:red">SQLBindParameter()</span></html> \|\|
	+	\| <html><span style="color:red">SQLPrepare()</span></html> \|\|
	+	\| <html><span style="color:red">SQLExecute()</span></html> \|\|
	+	\| <html><span style="color:red">SQLFreeStmt()</span></html> \|\|
	+	\| <html><span style="color:red">SQLGetDiagRec()</span></html> \|\|
	+	\| <html><span style="color:red">SQLDisconnect()</span></html> \|\|
	+	\|SQLFreeHandle() \|SQLFreeConnect()\\ SQLFreeEnv() \|
	+	\|etc. \|\|
	+
	+	Wenn man versucht, die Anwendung zu kompilieren - das klappt, beim Linken kommen jedoch die Fehlermeldungen, dass einige Funktion-Calls nicht aufgelöst werden können. Es ist auch konsequent - bei den Funktionen, die in den beiden Libraries gleich heißen, weiß der Linker nicht, welche der Beiden er wohin "mappen" soll.
	+
	+
	+	===== 1. Lösungsansatz: =====
	+
	+	Der 1. Gedanke in dieser Situation ist, die im Konflikt stehende Libraries auseinander zu trennen, indem man sie in jeweils eine weitere Wrapper-Library auslagert und die Funktionsnamen innerhalb der Wrapper-Library mit den entsprechenden Präfixen ausstattet, damit sie singulär werden. Beim Kompilieren/Linken dieser ausgelagerten Wrapper-Libraries werden sie jeweils gegen eine einzige Ziel-Library verlinkt. Somit können alle Funktion-Calls der Wrapper-Libraries 1:1 aufgelöst werden.
	+
	+	:!: Dieser Ansatz funktioniert jedoch nur, wenn die Ziel-Libraries statische Libraries sind. Sind die Ziel-Libraries dagegen DLLs, scheitert dieser Ansatz, weil die Referenzierung aller Funktion-Calls (die nicht statisch sind) nach dem Linker-Vorgang noch nicht komplett vollzogen ist. Die abschließende Referenzierung wird durch den Loader vollzogen, nachdem er die erforderlichen DLLs in den Speicher geladen hat, noch bevor die Steuerung an die Anwendung (bzw. die Funktion "main()") übergeben wird.
	+
	+	An dieser Stelle steht der Loader vor dem Dilemma, gegen welche DLLs soll er die Funktion-Calls auflösen, für die es mehr als 1 Treffer auf der DLL-Seite gibt. Die Antwort ist einfach: die DLL, deren Import-Library in der Linker-Liste (beim Bauen der Anwendung) näher zum Anfang der Liste gestanden hat, bekommt "den Zuschlag".
	+
	+
	+	===== Endgültige Lösung: =====
	+
	+	Die endgültige Lösung lautet:
	+
	+	* Sind die Ziel-Libraries, die im Konflikt stehen, statisch - können sie in die statischen Wrapper-Libraries ausgelagert werden.\\ Die statischen Ziel-Libraries werden bereits beim Linken der Wrapper-Library vollständig eingebunden. Das Linken der Anwendung, in der die Wrapper-Library eingebunden werden, kann nichts mehr an den Ziel-Libraries ändern, weil sie in den Wrapper-Library bereits "fest" (statisch) enthalten sind.
	+
	+	* Sind die Ziel-Libraries, die im Konflikt stehen, dynamisch - müssen sie in die dynamischen Wrapper-Libraries (DLLs) ausgelagert werden.\\ Die dynamischen Ziel-Libraries werden beim Linken der dynamischen Wrapper-Libraries mit dem Datei-Namen referenziert. Das Linken der Anwendung, in der die Wrapper-Library eingebunden werden, kann deshalb nichts mehr an den Ziel-Libraries ändern. Es sei denn, die DLLs, die im Konflikt stehen, dazu auch noch den gleichen Namen tragen.
	+
	+	:!: Es ist wichtig, die fertigen Wrapper-DLLs nach dem Kompilieren/Linken zu kontrollieren, z.B. mit dem Dependency Walker, dass tatsächlich jeweils (nur) die richtigen Ziel-DLLs referenziert werden!
	+
	+	----
	+	Stand: 03.12.2019\\
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF

edv:prg:c:tipp:plattform-makros

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:14+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Plattform-Makros ======
	+
	+	...für Plattform- und Compilerübergreifende Programme (Stichwort: Portabilität)
	+
	+	:!: Zuerst kommt die Ermittlung/Bestimmung des Compilers und danach der Plattform, weil viele Makros vom Compiler selbst gesetzt werden und sind deshalb Compiler-abhängig.
	+
	+	Eine große Übersicht von Makros im Bezug auf Compiler und Plattforme sind hier zu finden:
	+	* "C/C++ tip: How to detect the operating system type using compiler predefined macros" (Stand: 03.01.2012): [[http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system]]
	+	* "C/C++ tip: How to list compiler predefined macros" (Stand: 07.12.2011): [[http://nadeausoftware.com/articles/2011/12/c_c_tip_how_list_compiler_predefined_macros]]
	+
	+
	+	===== Compiler =====
	+
	+	Anhand folgender Makros läßt sich feststellen, mit welchem Compiler der Quelltext übersetzt wird:
	+
	+	^Makro ^Kommentar ^
	+	\|%%__GNUC__%%\\ \\ %%__GNUC_MINOR__%%\\ %%__GNUC_PATCHLEVEL__%% \|Der GNU C-Compiler setzt diese Makros.\\ \\ Beispiel: <code c>
	+	// Test for GCC > 3.2.0
	+	#if __GNUC__ > 3 \|\| (__GNUC__ == 3 && (__GNUC_MINOR__ > 2 \|\| (__GNUC_MINOR__ == 2 && __GNUC_PATCHLEVEL__ > 0))
	+	#endif
	+	</code> ...oder: <code c>
	+	#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
	+	// Test for GCC > 3.2.0
	+	#if GCC_VERSION > 30200
	+	#endif
	+	</code> \|
	+	\|%%__GNUG__%% \|Der GNU C++-Compiler setzt dieses Makro.\\ Es ist equivalent zum Test auf %%(__GNUC__ && __cplusplus)%%. \|
	+	\|%%__CYGWIN__%%\\ %%__CYGWIN32__%% \|Der Cygwin-Compiler (POSIX, Portierung von GCC unter Windows) setzt diese Makros. \|
	+	\|%%__MINGW32__%%\\ %%__MINGW64__%% \|Der MinGW-Compiler (non-POSIX, minimalistische Portierung von GCC unter Windows) setzt diese Makros. \|
	+	\|%%_MSC_VER%% \|Der MS VisualStudio-Compiler (häufig "VC" oder "MSVC" genannt) setzt dieses Makro mit dem Wert, der gleichzeitig der internen Compiler-Version entspricht.\\ Hier ist die Auflistung, welche Werte welcher Version des MSVC-Compilers entsprechen:\\ [[https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering]] \|
	+
	+	Quelle: [[https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html]]
	+
	+	Weitere Compiler: FIXME
	+
	+	Sprach-Level:
	+
	+	^Makro ^Kommentar ^
	+	\|%%__cplusplus%% \|Definiert nur, wenn der Text von einem C++-Compiler übersetzt wird.\\ Einige Werte, die dieses Makro haben kann:\\ 201103L = "C++11",\\ 201402L = "C++14".\\ \\ Beispiel 1: Prüfung, ob der passende Compiler verwendet wird: <code c>
	+	// Es muss mindestens C++11 sein:
	+	#if (__cplusplus < 201103L)
	+	#error ---------- C++11 features not available - use the GCC-option -std=c++11 ----------
	+	#endif
	+	</code>\\ Beispiel 2: das Template make_unique gibt es erst ab GCC 4.9, deshalb bei Bedarf "nachrüsten": <code c>
	+	#if (__cplusplus < 201402L) // vor C++14
	+	#include <memory>
	+	namespace std
	+	{
	+	template<typename T, typename ...Args>
	+	std::unique_ptr<T> make_unique(Args&& ...args)
	+	{
	+	return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
	+	}
	+	}
	+	#endif
	+	</code> \|
	+
	+
	+	===== Plattform =====
	+
	+	:!: IN ARBEIT - Anfang FIXME
	+
	+	Unterscheidung auf HW-Ebene:
	+
	+	* Prozessorarchitektur (z.B. "x86" oder "sparc") - welche Kürzel?
	+	* Bit-Breite (z.B. 32- oder 64-Bit)
	+	* Endianes (z.B. Big-/Little-Endian)
	+
	+	HW = Prozessorarchitektur + Bit-Breite + Endianes
	+
	+	Folgende Makros können für die Bestimmung der HW-Ebene herangezogen werden:
	+
	+	* Prozessorarchitektur:
	+
	+	Dieses Makros werden durch den MS VisualStudio-Compiler gesetzt:
	+
	+	^Makro ^Kommentar ^
	+	\|%%_M_AMD64%% \|Definiert, wenn Target ein x64-Prozessor ist. \|
	+	\|%%_M_ARM%% \|Definiert, wenn Target ein ARM-Prozessor ist. \|
	+	\|%%_M_IX86%% \|Definiert, wenn Target ein x86-Prozessor ist. Bei dem x64-Prozessor ist dieses Makro __nicht__ definiert. \|
	+	\|%%_M_X64%% \|Definiert, wenn Target ein x64-Prozessor ist. \|
	+
	+	* Bit-Breite:
	+
	+	^Makro ^Kommentar ^
	+	\| \| \|
	+
	+	* Endianes:
	+
	+	^Makro ^Kommentar ^
	+	\|%%__BYTE_ORDER__%%\\ \\ Mögliche Werte:\\ %%__ORDER_LITTLE_ENDIAN__%%\\ %%__ORDER_BIG_ENDIAN__%%\\ %%__ORDER_PDP_ENDIAN__%% \|Das Makro "%%__BYTE_ORDER__%%" nimmt wahlweise den Wert den anderen 3 Makros, je nachdem welches Endianes das Target hat.\\ \\ Ein Beispiel: <code c>
	+	// Test for a little-endian machine:
	+	#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
	+	#endif
	+	</code> \|
	+
	+
	+	Unterscheidung auf SW-Ebene:
	+
	+	* OS-Familie (z.B. "unix", "linux", "windows")
	+	* OS-Name/-Derivat (innerhalb der Familie, z.B. "solaris", "debian")
	+	* Namenszusatz (z.B. Nummer 6 bei RHEL6 oder 10 bei Windows10)
	+	* Bit-Breite (z.B. 32- oder 64-Bit)
	+
	+	OS = OS-Familie + OS-Name + Namenszusatz + Bit-Breite
	+
	+	^Makro ^Kommentar ^
	+	^Windows-Familie ^MS VisualStudio-Compiler ^
	+	\|%%_WIN32%% \|Definiert für Win32- und Win64-Anwendungen. (Immer definiert.)\\ Hinweis:\\ Nicht mit "%%WIN32%%" (ohne Unterstrich) verwechseln! "%%_WIN32%%" wird durch den Compiler gesetzt, "%%WIN32%%" durch das SDK oder Build Environment. \|
	+	\|%%_WIN64%% \|Definiert nur für Win64-Anwendungen. \|
	+	^UNIXoide ^^
	+	\|%%__unix%%\\ %%__unix__%% \|Definiert auf allen / meisten UNIX-artigen Betriebssystemen. \|
	+	\|%%_AIX%% \|Definiert unter AIX. \|
	+	\|%%sun%%\\ %%__sun%%\\ %%__sun__%%\\ %%__SVR4%% \|:?: Definiert unter SunOS / Solaris. (:!: Klären: SunOS versus Solaris.) \|
	+	\|%%__FreeBSD__%% \|FreeBSD. \|
	+	\|%%__NetBSD__%% \|NetBSD. \|
	+	\|%%__OpenBSD__%% \|OpenBSD. \|
	+	\|%%__hpux%% \|HP-UX. \|
	+	\|%%__APPLE__%%\\ %%__MACH__%% \|Definiert unter OSX, iOS und Darwin.\\ Zur weiteren Unterscheidung werden Makros aus TargetConditionals.h herangezogen:\\ %%TARGET_OS_EMBEDDED%%, %%TARGET_OS_IPHONE%%, %%TARGET_OS_MAC%% und %%TARGET_IPHONE_SIMULATOR%% \|
	+	^Linux ^^
	+	\|%%__linux__%%\\ %%__gnu_linux__%% \|Definiert auf Linux-Derivaten.\\ Eigentlich gehört die Linux-Familie auch zu den UNIXoiden, wird hier jedoch übersichtshalber und aufgrund großer Anzahl verschiedener Distributionen separat behandelt.\\ :!: Die Makros "%%__unix%%" und "%%__unix__%%" sind unter Linux ebenfalls definiert. \|
	+
	+	%%_WINDOWS%%\\
	+	%%__i386%%\\
	+	%%__i386__%%\\
	+	%%i386%%\\
	+	%%x86%%\\
	+	%%x64%%\\
	+	%%_X64%%\\
	+	%%__x86_64%%\\
	+	%%__sparc%%\\
	+	%%__sparc__%%\\
	+	%%sparc%%\\
	+	%%_SPARC%%\\
	+
	+	^Makro ^Kommentar ^
	+	\|%%__ELF__%% \|Dieses Makro ist definiert, wenn Target nutzt das Object-Format ELF. \|
	+
	+	Fazit:
	+
	+	Plattform-ID (oder einfach Plattform) = HW + OS
	+
	+	:!: IN ARBEIT - Ende FIXME
	+
	+	:!: Viele Plattform-Makros sind im HeaderFile gtest-port.h (aus GoogleTest) enthalten und können sehr gut als Anhaltspunkte verwendet werden.
	+
	+
	+	----
	+	Stand: 27.09.2019\\
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF

edv:prg:c:tipp:tips_und_tricks_zu_threads

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:16+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Tips und Tricks zu Threads ======

	+	FIXME Text
	+
	+	===== Quelltext aufteilen =====
	+
	+	FIXME Text
	+
	+	===== Doppelte Prüfung von shared-Variablen =====
	+
	+	FIXME Text
	+
	+	<code c>
	+	void eineFunktion (void)
	+	{
	+	acquireSyncSection(hSync);
	+
	+	if (sharedGlobalVariable) eineAndereFunktion();
	+
	+	releaseSyncSection(hSync);
	+	} // eineFunktion()
	+	</code>
	+
	+	FIXME Text
	+
	+	<code c>
	+	void eineFunktion (void)
	+	{
	+	if (sharedGlobalVariable)
	+	{
	+	acquireSyncSection(hSync);
	+
	+	if (sharedGlobalVariable) eineAndereFunktion();
	+
	+	releaseSyncSection(hSync);
	+	} // if
	+	} // eineFunktion()
	+	</code>
	+
	+	===== Links zum Thema: =====
	+
	+	* Thread: [[http://de.wikipedia.org/wiki/Thread_(Informatik)]]
	+	* Mutex: [[http://de.wikipedia.org/wiki/Mutex]]
	+	* Semaphor: [[http://de.wikipedia.org/wiki/Semaphor_(Informatik)]]
	+
	+	* Parallele Programmierung mit Threads (Jürgen Wolf: Linux/Unix-Systemprogrammierung):\\ [[http://pronix.linuxdelta.de/C/Linuxprogrammierung/Linuxsystemprogrammieren_C_Kurs_Kapitel8.shtml]]
	+	* Die grundlegenden Funktionen zur Thread–Programmierung (Jürgen Wolf: Linux-UNIX-Programmierung, Das umfassende Handbuch – 2., aktualisierte und erweiterte Auflage 2006):\\ [[http://openbook.galileocomputing.de/linux_unix_programmierung/Kap10-004.htm]]
	+	* Mit den POSIX-Threads programmieren (Jürgen Wolf: C von A bis Z, Das umfassende Handbuch - 3., aktualisierte und erweiterte Auflage):\\ [[http://openbook.galileocomputing.de/c_von_a_bis_z/026_c_paralleles_rechnen_004.htm]]
	+
	+	----
	+	Stand: 16.10.2015 - in Arbeit\\
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF

edv:prg:c:tipp:vordefinierte_praeprozessor-direktiven

Anonymous (anonymous@undisclosed.example.com) — 2020-01-11T01:23:15+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Vordefinierte Präprozessor-Direktiven (ANSI C) ======

	+	===== Bedingtes Kompilieren =====
	+
	+	* #include
	+
	+	Sie binden die angegebene Datei in die aktuelle Source-Datei ein. Es gibt zwei Arten der #include-Direktive, nämlich:
	+
	+	#include <Datei.h>
	+
	+	und
	+
	+	#include "Datei.h"
	+
	+	Die erste Anweisung sucht die Datei im Standard-Includeverzeichnis des Compilers, die zweite Anweisung sucht die Datei zuerst im Verzeichnis, in der sich die aktuelle Sourcedatei befindet; sollte dort keine Datei mit diesem Namen vorhanden sein, sucht sie ebenfalls im Standard-Includeverzeichnis.
	+
	+
	+	* Weitere Direktiven:
	+
	+	#define SYMBOL
	+	#define KONSTANTE (Wert)
	+	#define MAKRO Ausdruck
	+	#undef SYMBOL
	+	#ifdef
	+	#ifndef
	+	#elif
	+	#else
	+	#endif
	+
	+	* #error
	+
	+	Die #error-Direktive wird verwendet, um den Kompilierungsvorgang mit einer (optionalen) Fehlermeldung abzubrechen. Syntax:
	+
	+	<code c>
	+	#error Fehlermeldung
	+	</code>
	+
	+	Die Fehlermeldung muss nicht in Anführungszeichen stehen.
	+
	+	* #if
	+
	+	Mit #if kann ähnlich wie mit #ifdef eine bedingte Übersetzung eingeleitet werden, jedoch können hier konstante Ausdrücke ausgewertet werden.
	+
	+	<code c>
	+	#if (DEBUGLEVEL >= 1)
	+	# define print1 printf
	+	#else
	+	# define print1(...) (0)
	+	#endif
	+
	+	#if (DEBUGLEVEL >= 2)
	+	# define print2 printf
	+	#else
	+	# define print2(...) (0)
	+	#endif
	+	</code>
	+
	+	Der Präprozessorausdruck innerhalb der Bedingung folgt den gleichen Regeln wie Ausdrücke in C, jedoch muss das Ergebnis zum Übersetzungszeitpunkt bekannt sein.
	+
	+	* defined SYMBOL
	+
	+	defined ist ein unärer Operator, der in den Ausdrücken der #if und #elif Direktiven eingesetzt werden kann.
	+
	+	<code c>
	+	#define FOO
	+	#if defined FOO \|\| defined BAR
	+	#error "FOO oder BAR ist definiert"
	+	#endif
	+	</code>
	+
	+	* #pragma
	+
	+	Bei den #pragma-Anweisungen handelt es sich um compilerspezifische Erweiterungen der Sprache C. Diese Anweisungen steuern meist die Codegenerierung. Sie sind aber zu sehr von den Möglichkeiten des jeweiligen Compilers abhängig, als dass man hierzu eine allgemeine Aussage treffen kann.
	+
	+	Quelle: [[http://de.wikibooks.org/wiki/C-Programmierung:_Präprozessor\|wikibooks]]
	+
	+	===== Vordefinierte Makros (Predefined Macros) =====
	+
	+	ANSI-kompatible Makros:
	+
	+	//(unvollständig)//
	+
	+	^ Makroname ^ Bedeutung ^
	+	\| %%__LINE__%% \| Zeilennummer der aktuellen Zeile in der Programmdatei (integer) \|
	+	\| %%__FILE__%% \| Name der Programmdatei (String) \|
	+	\| %%__DATE__%% \| Übersetzungsdatum der Programmdatei (String: //Mmm dd yyyy//) \|
	+	\| %%__TIME__%% \| Übersetzungszeit der Programmdatei (String: //hh:mm:ss//) \|
	+	\| %%__STDC__%% \| Erkennungsmerkmal eines ANSI C-Compilers. Ist die ganz-zahlige Konstante auf den Wert 1 gesetzt, handelt es sich um einen ANSI C-konformen Compiler. \|
	+	\| %%__func__%% \| Gibt den Namen der Funktion aus, in der dieses Makro verwendet wird.* \|
	+	\| %%__TIMESTAMP__%% \| "mtime" von dem source-File (String: //Ddd Mmm Date hh:mm:ss yyyy//) \|
	+
	+	GCC: [[https://gcc.gnu.org/onlinedocs/cpp/Predefined-Macros.html\|Predefined Macros]]
	+	* [[https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html\|Standard Predefined Macros]]
	+	* [[https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros\|Common Predefined Macros]]
	+
	+
	+	Pre-defined Compiler Macros: [[https://sourceforge.net/p/predef/wiki/Home/]]
	+
	+	Microsoft-spezifische Makros:
	+
	+	//(unvollständig)//
	+
	+	^ Makroname ^ Bedeutung ^
	+	\| %%__cplusplus%% \| C++-Code \|
	+	\| %%__FUNCTION__%% \| Gibt den Namen der Funktion aus, in der dieses Makro verwendet wird.* \|
	+	\| %%__FUNCDNAME__%%\| Gibt //Decorated function name// aus, z.B.: %%?exampleFunction@@YAXXZ%% \|
	+	\| %%__FUNCSIG__%% \| Gibt //Function signature// aus, z.B.: %%void __cdecl exampleFunction(void)%% \|
	+	\| %%_MFC_VER%% \| Gibt die Version von MFC aus. Zum Beispiel, 0x0700 entspricht MFC Version 7.\\ Hier ist die Auflistung, welche Werte welcher Version des MSVC-Compilers entsprechen:\\ [[https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering]] \|
	+	\| %%_WIN32%% \| Definiert für Win32- und Win64-Anwendungen (immer definiert) \|
	+	\| %%_WIN64%% \| Definiert für Win64-Anwendungen \|
	+	\| %%_M_AMD64%% \| Definiert für Kompilierungen, die auf x64-Prozessoren abzielen. \|
	+	\| %%_M_ARM%% \| Definiert für Kompilierungen, die auf ARM-Prozessoren abzielen. \|
	+	\| %%_M_IX86%% \| Definiert für Kompilierungen, die auf x86-Prozessoren abzielen. \|
	+	\| %%_M_X64%% \| Definiert für Kompilierungen, die auf x64-Prozessoren abzielen. \|
	+
	+	:!: Das Makro %%__func__%% funktioniert nicht mit allen (pre-)Compiler. Der Compiler von MS VisualStudio 2010 z.B. meldet dieses Makro als //undeclared identifier//. Stattdessen soll das Makro %%__FUNCTION__%% verwendet werden. (Hier gehts zu den MS VisualStudio 2010 [[http://msdn.microsoft.com/de-de/library/vstudio/b0084kay(v=vs.100).aspx\|Predefined Macros]], oder Predefined Macros in VisualStudio 2013 [[https://msdn.microsoft.com/de-de/library/b0084kay(v=vs.120).aspx\|deutsch]] bzw. [[https://msdn.microsoft.com/en-us/library/b0084kay(v=vs.120).aspx\|Originaltext]]. Weitere Infos unter [[http://blogs.msdn.com/b/reiley/archive/2011/08/12/macro-revisited.aspx\|MACRO Revisited]].)\\ Um übergreifenden Code zu schreiben kann man es beispielsweise mit folgender Definition umgehen:
	+
	+	<code c>
	+	#ifndef __func__
	+	#define __func__ __FUNCTION__
	+	#endif
	+	</code>
	+
	+	:!: Oder alternativ, damit die Makros einheitlich aussehen, ein übergreifendes Makro namens %%__FUNC__%% definieren, wie folgt:
	+
	+	<code c>
	+	#if defined _WIN32 \|\| defined _WIN64
	+	#define __FUNC__ __FUNCTION__
	+	#else
	+	#define __FUNC__ __func__
	+	#endif
	+
	+	#if !defined __FUNC__
	+	#error Define for __FUNC__ expected
	+	#endif
	+	</code>
	+
	+	Hier folgt ein Beispiel zur Verwendung dieser vordefinierten Makros:
	+
	+	<code c>
	+	/* direktiven.c */
	+	#include <stdio.h>
	+	#include <stdlib.h>
	+
	+	#if defined __STDC__
	+	#define isstd_c() printf("ANSI C Compiler\n")
	+	#else
	+	#define isstd_c() printf("Kein ANSI C Compiler\n")
	+	#endif
	+
	+	int main(void)
	+	{
	+	printf("Zeile %d in Datei %s\n",__LINE__,__FILE__);
	+	printf("Übersetzt am %s um %s\n",__DATE__,__TIME__);
	+
	+	#line 999 "asdf.c"
	+	printf("Zeile %d in Datei %s\n",__LINE__,__FILE__);
	+
	+	isstd_c(); /* Ist es ein ANSI C Compiler ? */
	+	return EXIT_SUCCESS;
	+	}
	+	</code>
	+
	+	Ein Beispiel für platformabhängiges Kompilieren:
	+
	+	<code c>
	+	#if defined _WIN64
	+	// Hier kommt Code für Windows 64 Bit (muß unbedingt vor dem "_WIN32"-Zweig stehen!)
	+	// ... Text ...
	+	#elif defined _WIN32
	+	// Hier kommt Code für Windows 32 Bit
	+	// ... Text ...
	+	#else
	+	// Restlicher Code
	+	// ... Text ...
	+	#endif
	+	</code>
	+
	+	Siehe auch: [[EDV:PRG:C:Tipp:Plattform-Makros]]
	+
	+
	+	===== String-Literal-Operator =====
	+
	+	:!: //Zitat (Quelle: [[http://wwwuser.gwdg.de/~kboehm/ebook/26_kap20_w6.html]])://
	+
	+	Noch flexibler wird die Makrodefinition durch die Verwendung des stringbildenden Operator (#), der manchmal auch String-Literal-Operator genannt wird. Wenn einem Makroparameter im Substitutionsstring ein # vorangestellt ist, wird das Argument beim Expandieren des Makros in einen String in Anführungszeichen umgewandelt. Wenn Sie also ein Makro wie folgt definieren:
	+
	+	<code c>
	+	#define AUSGEBEN(x) printf(#x)
	+	</code>
	+
	+	und es mit folgender Anweisung aufrufen:
	+
	+	<code c>
	+	AUSGEBEN(Hallo Mama);
	+	</code>
	+
	+	wird nach der Expansion daraus die Anweisung:
	+
	+	<code c>
	+	printf("Hallo Mama");
	+	</code>
	+
	+	Die vom stringbildenden Operator durchgeführte Umwandlung berücksichtigt auch Sonderzeichen. Wenn es im Argument ein Zeichen gibt, das normalerweise ein Escape-Zeichen benötigt, fügt der #-Operator vor diesem Zeichen einen Backslash ein. Greifen wir dazu noch einmal auf unser obiges Beispiel zurück. Der Aufruf:
	+
	+	<code c>
	+	AUSGEBEN("Hallo Mama");
	+	</code>
	+
	+	expandiert demnach zu
	+
	+	<code c>
	+	printf("\"Hallo Mama\"");
	+	</code>
	+
	+	Ein Beispiel für den #-Operator finden Sie in Listing 20.1. Doch zuvor möchte ich Ihnen noch einen anderen Operator vorstellen, der in Makros verwendet wird, der Verkettungsoperator (##). Dieser Operator verkettet oder besser verbindet im Zuge der Makro-Expansion zwei Strings. Er verwendet keine Anführungszeichen und sieht auch keine Sonderbehandlung für Escape-Zeichen vor. Er dient hauptsächlich dazu, C-Quelltext-Sequenzen zu erzeugen. Wenn Sie zum Beispiel folgendes Makro definieren und aufrufen:
	+
	+	<code c>
	+	#define HACKEN(x) funk ## x
	+	salat = HACKEN(3)(q, w);
	+	</code>
	+
	+	wird das Makro, das in der zweiten Zeile aufgerufen wurde, folgendermaßen expandiert:
	+
	+	<code c>
	+	salat = funk3 (q, w);
	+	</code>
	+
	+	Wie Sie sehen, ist es mit Hilfe des ##-Operators möglich, zwischen dem Aufruf verschiedener Funktionen auszuwählen. Sie programmieren praktisch die Erzeugung des C-Quellcodes.
	+
	+	Listing 20.1 zeigt eine Möglichkeit, den #-Operator zu verwenden.
	+
	+	__Listing 20.1:__ Der #-Operator in der Makro-Expansion.
	+
	+	<code c>
	+	/* Einsatz des #-Operators in einer Makro-Expansion. */
	+
	+	#include <stdio.h>
	+
	+	#define AUSGABE(x) printf(#x " gleich %d.\n", x)
	+
	+	int main(void)
	+	{
	+	int wert = 123;
	+	AUSGABE(wert);
	+	return 0;
	+	}
	+	</code>
	+
	+	Ausgabe:
	+
	+	wert gleich 123.
	+
	+	Durch die Verwendung des #-Operators in Zeile 5 wird der Variablenname wert bei der Expansion des Makros als String in Anführungszeichen an die Funktion printf() übergeben. Nach der Expansion sieht das Makro AUSGABE wie folgt aus:
	+
	+	<code c>
	+	printf("wert" " gleich %d.", wert );
	+	</code>
	+
	+	:!: Kompletes eBook habe ich unter [[http://wwwuser.gwdg.de/~kboehm/ebook/]] entdeckt.
	+
	+	----
	+	EOF

edv:prg:c:tipp:zeit-funktionen

Anonymous (anonymous@undisclosed.example.com) — 2020-01-23T13:04:34+00:00

	aktuell
Zeile 1:	Zeile 1:
	+	====== Zeit-Funktionen ======

	+	__Überblick:__
	+
	+	* [[zeit-funktionen#time()]] - Anzahl der Sekunden, die seit dem 01.01.1970, 00:00:00 Uhr, vergangen sind. (Evtl. das "Jahr 2038"-Problem, wenn "time_t" als "long" implementiert ist.)
	+	* [[zeit-funktionen#localtime_und_gmtime\|localtime()]] - Umwandeln von "time_t" (das Ergebnis von "time()") in "struct tm" (als lokale Ortszeit) unter der Berücksichtigung von Sommer- und Winterzeit.
	+	* localtime_s()
	+	* localtime_r()
	+	* [[zeit-funktionen#localtime_und_gmtime\|gmtime()]] - Wie localtime(), nur das Ergebnis ist nicht die lokale Ortszeit, sondern die UTC-Zeit.
	+	* [[zeit-funktionen#mktime()]] - Umwandeln von "struct tm" in "time_t" (Gegenstück der Funktionen localtime() und gmtime()).
	+	* [[zeit-funktionen#difftime()]] – Differenz zwischen zwei Zeitangaben.
	+	* asctime() und ctime() – Umwandeln von Zeitformaten ("struct tm" und "time_t") in einen String.
	+	* strftime() – Umwandeln vom Zeitformat "struct tm" in einen benutzerdefinierten String.
	+	* [[zeit-funktionen#clock()]] - Verbrauchte CPU-Zeit für ein Programm (seit dem Programmstart).\\ [[http://man7.org/linux/man-pages/man3/clock.3.html]]
	+	* clock_gettime() (CLOCK_MONOTONIC, CLOCK_MONOTONIC_PRECISE, CLOCK_REALTIME, CLOCK_PROCESS_CPUTIME_ID)\\ [[http://man7.org/linux/man-pages/man2/clock_gettime.2.html]]
	+	* TZ (Environment Variable) - Zeitzone (Beispiele: "localtime", "MESZ", "UTC", etc.)
	+	* FIXME
	+
	+	:!: UTC (Universal Time Coordinated) ist identisch mit GMT (Greenwich Mean Time).
	+
	+	__Datentypen:__
	+
	+	* clock_t - Die CPU-Zeit (Ganzzahl)
	+	* time_t - Datums- und Zeitangaben (Ganzzahl)
	+	* struct tm - Enthält alle zu einer (gregorianischen) Kalenderzeit relevanten Komponenten: <code c>
	+	struct tm
	+	{
	+	int tm_sec; // Sekunden (0–59)
	+	int tm_min; // Minuten (0–59)
	+	int tm_hour; // Stunden (0–23)
	+	int tm_mday; // Monatstag (1–31)
	+	int tm_mon; // Monate (0–11; Januar = 0)
	+	int tm_year; // Jahre ab 1900
	+	int tm_wday; // Tag seit Sonntag (0–6; Sonntag = 0)
	+	int tm_yday; // Tag seit 1. Januar (0–365; 1.Januar = 0)
	+	int tm_isdst; // Winter-/Sommerzeit (Winterzeit: tm_istdst == 0; Sommerzeit: tm_isdst > 0; wenn Info nicht verfügbar: tm_isdst < 0)
	+	long int tm_gmtoff; // (nur auf Linux) Gibt die Sekunden östlich von UTC bzw. den negativen Wert westlich von UTC für die Zeitzonen an.
	+	const char *tm_zone; // (nur auf Linux) Enthält den Namen der aktuellen Zeitzone.
	+	};
	+	</code>
	+	* struct timespec - Enthält (hoch aufgelöste) Zeit: <code c>
	+	struct timespec
	+	{
	+	time_t tv_sec; // Sekunden
	+	long tv_nsec; // Nanosekunden
	+	};
	+	</code>
	+
	+	Je nach OS verfügbare Funktionen (Quelle: [[http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking]]):
	+
	+	^ ^AIX ^BSD ^HP-UX ^Linux ^OSX ^Solaris^Windows^
	+	\|time() \| X \| X \| X \| X \| X \| X \| \|
	+	\|clock_gettime()\| X \| X \| X \| X \| \| X \| \|
	+	\|gethrtime() \| \| \| X \| \| \| X \| \|
	+	\|gettimeofday() \| X \| X \| X \| X \| X \| X \| \|
	+	\|mach_absolute_time()\| \| \| \| \| X \| \| \|
	+	\|GetSystemTimeAsFileTime()\\ GetSystemTimePreciseAsFileTime() \| \| \| \| \| \| \| X \|
	+
	+	Je nach OS verfügbare Clock-IDs:
	+
	+	^Clock-ID ^AIX ^BSD ^HP-UX ^Linux ^Solaris^Hinweis ^
	+	\|CLOCK_REALTIME \| X \| X \| X \| X \| X \|Reports a settable (by root) time that can be mapped to the current real-world date and time. The value is the elapsed time since "the Epoch", which is usually Jan 1st, 1970 at midnight GMT (this may vary among OSes and should not be counted on). %%CLOCK_REALTIME%% is the system time used for human time display, so it's subject to corrections whenever the system checks a time server or the system administrator updates the clock. If such adjustments are made during benchmarking, then the elapsed time between two queries of %%CLOCK_REALTIME%% will be wrong. One of the other clocks should be used instead, if available. \|
	+	\|CLOCK_MONOTONIC \| X \| X \| \| X \| X \|Reports an //unsettable// time that counts upwards starting at an unspecified time zero in the past that's typically the system's boot time. The time from %%CLOCK_MONOTONIC%% cannot be mapped to the current real-world date and time, but it's the right tool for benchmarking where we only need to find the elapsed time of an algorithm. \|
	+	\|CLOCK_MONOTONIC_PRECISE\| \| X \| \| \| \|Is a variant of %%CLOCK_MONOTONIC%% that aims at providing a more precise time. \|
	+	\|CLOCK_MONOTONIC_RAW \| \| \| \| X \| \|(Linux 2.6.28 or later) Is a variant of %%CLOCK_MONOTONIC%% that aims for sa more precise time by accessing the underlying "raw" hardware-based time. \|
	+	\|CLOCK_HIGHRES \| \| \| \| \| X \|Is equivalent to %%CLOCK_MONOTONIC%% and aims at returning a high-resolution time. The returned value is also available from gethrtime(). \|
	+
	+
	+	__Deklarationen, Beschreibungen und Beispiele:__
	+
	+
	+	===== time() =====
	+
	+	Deklaration in <time.h>
	+
	+	<code c>
	+	time_t time(time_t *ptr_TimeVar);
	+	</code>
	+
	+	FIXME
	+
	+
	+	===== localtime() und gmtime() =====
	+
	+	<code c>
	+	struct tm localtime(const time_t ptr_TimeVar);
	+	struct tm gmtime(const time_t ptr_TimeVar);
	+	</code>
	+
	+	Beide Funktionen liefern als Rückgabewert einen Pointer auf "ptr_TimeVar" vom Typ "struct tm".
	+
	+	Die Funktion localtime() wandelt die Kalenderzeit in die lokale Ortszeit um (unter der Berücksichtigung von Sommer- und Winterzeit), gmtime() dagegen - in die UTC-Zeit.
	+
	+
	+	===== mktime() =====
	+
	+	<code c>
	+	time_t mktime(struct tm *ptr_TimeVar);
	+	</code>
	+
	+	Auf diese Weise wird eine Zeit im "struct tm"-Format wieder in eine Zeit im "time_t"-Format umgewandelt ("tm_yday" und "tm_wday" in "ptr_TimeVar" werden ignoriert). Der zulässige Bereich für die Kalenderzeit liegt zwischen dem 01.01.1970, 00:00:00 Uhr, und dem 19.01.2038, 03:14:07 Uhr. Ist die Kalenderzeit nicht darstellbar, gibt diese Funktion –1 zurück. Befinden sich die Felder "tm_sec", "tm_min", "tm_hour", "tm_mday" und "tm_mon" nicht im korrekten Bereich, werden diese angepasst.
	+
	+
	+	===== difftime() =====
	+
	+	<code c>
	+	double difftime(time_t zeit_nachher, time_t zeit_vorher);
	+	</code>
	+
	+	Die difftime() liefert die Differenz von "zeit_nachher" minus "zeit_vorher" (in Sekunden) zurück (als double-Wert!).
	+
	+
	+	===== clock() =====
	+
	+	<code c>
	+	clock_t clock(void);
	+	</code>
	+
	+	Die clock() liefert die verbrauchte CPU-Zeit (:!: nicht in Sekunden!) seit dem Programmstart zurück (-1 im Fehlerfall). Um die CPU-Zeit in Sekunden zu berechnen, muss man der Rückgabewert durch CLOCKS_PER_SEC teilen.
	+
	+
	+	===== Beispiel: "class timeutils" =====
	+
	+	Klasse, um die (aktuelle) Zeit in verschiedenen Formaten auszugeben:
	+
	+	timeutils.h
	+	<code cpp>
	+	namespace utils
	+	{
	+	struct timeformats
	+	{
	+	static const char* FMT_ISO_DATE; // Equivalent to "%Y-%m-%d" (the ISO 8601 date format).
	+	static const char* FMT_ISO_TIME; // Equivalent to "%H:%M".
	+	static const char* FMT_ISO_TIME_SEC; // Equivalent to "%H:%M:%S" (the ISO 8601 time format).
	+	static const char* FMT_ISO_DATE_TIME_SEC; // FMT_ISO_DATE + FMT_ISO_TIME_SEC.
	+	static const char* FMT_FILENAME_DATE; // Equivalent to "%Y%m%d".
	+	static const char* FMT_FILENAME_TIME; // Equivalent to "%H%M%S".
	+	static const char* FMT_TIME_SEC_MS; // Equivalent to "%H:%M:%S.%ffff" (the ISO 8601 time format) + milliseconds.
	+	static const char* FMT_STOPWATCH_TIME; // Custom format "%k".
	+	static const char* FMT_DATE_TIME_SEC_MS; // FMT_ISO_DATE + FMT_ISO_TIME_SEC + ".%ffff".
	+	}; // struct timeformats
	+
	+	class timeutils // Helper rund um Zeitangaben.
	+	{
	+	public:
	+	timeutils() = delete;
	+	~timeutils() = delete;
	+
	+	public:
	+	static std::time_t now(); // now() liefert die Zeit sekundengenau (alterantiv hires_time() verwenden.
	+	static string to_string(const std::time_t& time, const string& format); // Formatiert nach http://en.cppreference.com/w/cpp/chrono/c/strftime".
	+	}; // class timeutils
	+
	+	// --- Inlines: ---
	+	inline std::time_t timeutils::now() { return std::time(nullptr); }
	+	} // namespace utils
	+	</code>
	+
	+	timeutils.cpp
	+	<code cpp>
	+	namespace utils
	+	{
	+	// Hinweis: %F, %R, %T werden von VS2012 nicht unterstützt.
	+	const char* timeformats::FMT_ISO_DATE = "%Y-%m-%d"; // Equivalent to "%Y-%m-%d" (the ISO 8601 date format).
	+	const char* timeformats::FMT_ISO_TIME = "%H:%M"; // Equivalent to "%H:%M".
	+	const char* timeformats::FMT_ISO_TIME_SEC = "%H:%M:%S"; // Equivalent to "%H:%M:%S" (the ISO 8601 time format).
	+	const char* timeformats::FMT_ISO_DATE_TIME_SEC = "%Y-%m-%d %H:%M:%S"; // FMT_ISO_DATE + FMT_ISO_TIME_SEC.
	+	const char* timeformats::FMT_FILENAME_DATE = "%Y%m%d"; // Equivalent to "%Y%m%d".
	+	const char* timeformats::FMT_FILENAME_TIME = "%H%M%S"; // Equivalent to "%H%M%S".
	+	const char* timeformats::FMT_TIME_SEC_MS = "%H:%M:%S.%ffff"; // Equivalent to "%H:%M:%S.%ffff" (the ISO 8601 time format) + milliseconds.
	+	const char* timeformats::FMT_STOPWATCH_TIME = "%k"; // Custom format "%k".
	+	const char* timeformats::FMT_DATE_TIME_SEC_MS = "%Y-%m-%d %H:%M:%S.%ffff"; // FMT_ISO_DATE + FMT_ISO_TIME_SEC + ".%ffff".
	+
	+	string timeutils::to_string(std::time_t const& time, string const& format) // Formatiert nach "http://en.cppreference.com/w/cpp/chrono/c/strftime".
	+	{
	+	char buffer[256];
	+	struct tm tm_struct;
	+
	+	#ifdef OS_WINDOWS
	+	localtime_s(&tm_struct, &time);
	+	#else
	+	localtime_r(&time, &tm_struct);
	+	#endif
	+	if (std::strftime(buffer, sizeof(buffer), format.c_str(), &tm_struct))
	+	return buffer;
	+	return string();
	+	} // timeutils::to_string()
	+	} // namespace utils
	+	</code>
	+
	+
	+	===== Weitere Beispiele =====
	+
	+	<code c>
	+	// IN ARBEIT
	+	void testFunktion()
	+	{
	+	time_t t = time(NULL);
	+	struct tm tm;
	+
	+	#ifdef OS_WINDOWS
	+	localtime_s(&tm, &t);
	+	#else // Unix, Linux
	+	localtime_r(&t, &tm);
	+	#endif
	+
	+	printf("Jahr = %d\n", tm.tm_year + 1900);
	+	printf("Monat = %d\n", tm.tm_mon + 1);
	+	printf("Tag = %d\n", tm.tm_mday);
	+	}
	+	// NICHT FERTIG
	+	</code>
	+
	+	:!: Zu beachten, daß Ergebniss, das die Funktionen localtime(), localtime_s(), localtime_r() liefern, von dem Wert der Environment Variable "%%TZ%%" abhängt. Hier beispielsweise die Einstellung für die mitteleuropäische Sommerzeit:
	+
	+	<code bash>
	+	export TZ=MESZ
	+	</code>
	+
	+	Ein Blogpost erklärt, warum das Setzen der Timezone-Variable TZ tausende von Syscalls erspart: [[https://blog.packagecloud.io/eng/2017/02/21/set-environment-variable-save-thousands-of-system-calls/]]
	+
	+	Weitere Infos hier: [[http://blog.quasardb.net/a-portable-high-resolution-timestamp-in-c/]]\\
	+	...oder hier: [[http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking]] - :!: Sehr ausführliche Analyse!
	+
	+	Fortgeschrittene Funktionen in der Zeitbibliothek von C++11: [[http://www.linux-magazin.de/Ausgaben/2016/06/C-11]]
	+
	+	----
	+	Stand: 23.01.2020\\
	+	--- //[[feedback.jk-wiki@kreick.de\|: Jürgen Kreick]]//
	+
	+	EOF