Veröffentlicht am

#include<> oder #include““

Ich ärgere mich immer wieder, wenn ich auf GitHub eigentlich interessante Libraries finde und dann feststelle, dass darin die „falschen“ Include-Anweisungen verwendet werden. Aber was ist eigentlich richtig und was ist falsch? Dazu müssen wir erst einmal den Standard bemühen. Da heißt es (frei übersetzt)

#include <...> sucht an den vom System festgelegten Orten nach dem genannten Header.

#include "..." sucht nach der genannten Datei. Wenn diese Suche nicht erfolgreich ist, wird die Suche so fortgesetzt als hätte man den Dateinamen in #include <...> angegeben.

Als erste fällt auf, dass einmal von einem Header und das andere Mal von einer Datei die Rede ist. Ein Grund dafür ist, dass sich der Standard nicht darauf festlegen will, wie die Standard-Header (wie iostream oder cmath) bzw. die darin enthaltenen Definitionen gespeichert werden sollen. In der Praxis sind das meistens Dateien, aber das ist nicht zwingend.

#include <…> heißt also nicht unbedingt „füge an dieser Stelle den Inhalt der genannten Datei ein“, sondern eher „füge hier alle Definitionen ein, die vom Standard in dem genannten Header sein sollten“. Es ist also durchaus möglich, dass der Compiler alle Definitionen aus den Standard-Headern kennt, diese aber erst dann verwendet, wenn der entsprechende Header aktiviert wurde.

Es kann daher nicht falsch sein, wenn man es sich zur Angewohnheit macht, die im Standard definierten Header immer mit #include <…> verwendet. Es ist aber definitiv falsch, wenn man eigene Header-Dateien, also die .h, .hpp oder .hxx Dateien, die im Projekt selbst definiert und verwendet werden, auch mit #include <…> einfügt. Für diese Dateien ist #include „…“ die einzige richtige Lösung.

Aber wie sieht es mit den ganzen anderen Header-Dateien aus, die mit der Entwicklungsumgebung bzw. einem SDK (z.B. die ganzen Windows Header) oder anderen Bibliotheken (z.B. denen von GitHub) aus?

Für die ist #include „…“ jedenfalls nicht falsch. Denn es sind keine Header im Sinne des Standards, sondern Dateien, also ein Fall für #include „…“. Das kann aber bei der großen Zahl von Header-Dateien schnell zu einem Problem werden. Was passiert denn, wenn man zufällig zwei verschiedene Header-Dateien mit gleichen Namen hat. Ich bin einmal, als der cstring Header noch string.h hieß), fast daran verzweifelt, dass der Compiler strlen nicht kannte. Bis sich herausstellte, dass ich #include „string.h“ geschrieben hatte und im Projekt auch eine Datei string.h war, und der Compiler meine Datei statt des Standard-Headers eingefügt hat.

Daraus habe ich meine Schlüsse gezogen und (für mich) Regeln für den Umgang mit #include <…> und #include „…“ aufgestellt. Aber vorher galt es herauszufinden wie mein Compiler (Visual C++) nach Headern und Header-Dateien sucht.

Für #include <…> sucht dieser Compiler

  1. In den mit /I angegebenen Verzeichnissen in der angegebenen Reihenfolge.
  2. In den in der INCLUDE Environment Variablen angegebenen Verzeichnissen in der angegebenen Reihenfolge.

Für #include „…“ wird es etwas komplexer

  1. In dem Verzeichnis, in dem sich die Datei, die das #include Anweisung enthält, befindet.
  2. In den Verzeichnissen der offenen Include-Dateien rückwärts zur Reihenfolge der #include Anweisungen.
  3. In den mit /I angegebenen Verzeichnissen in der angegebenen Reihenfolge.
  4. In den in der INCLUDE Environment Variablen angegebenen Verzeichnissen in der angegebenen Reihenfolge.

Für mich habe ich die folgenden Regeln aufgestellt.

  1. Die Include-Verzeichnisse des Compilers und des Windows SDK werden nicht verändert. Ich überlasse es dem Compiler bzw. dem SDK wie die Dateien gefunden werden (/I Option oder INCLUDE Variable). Für den Zugriff wird immer #include <…> verwendet.
  2. Includes anderer Bibliotheken kommen, wenn möglich, in Unterverzeichnisse eines weiteren Include-Verzeichnisses (C:/ho/dev/inc). Dieses Verzeichnis (nicht die Unterverzeichnisse) kommt ebenfalls in den Suchpfad. Für den Zugriff wird immer #include <library/…> verwendet, wobei library der Name des Unterverzeichnisses von C:/ho/dev/inc ist.
  3. Includes des Projekts selbst oder von Bibliotheken, die Teil des Projekts sind, bleiben, wo sie sind. Auf sie wird mit #include „…“ mit einem relativen Pfad vom Verzeichnis der Datei, die das #include enthält, zugegriffen.
  4. Innerhalb einer Bibliothek in einem Unterverzeichnis von C:/ho/dev/inc wird auf die eigenen, geschachtelten Header mit #include „…“ (evtl. mit einem relativen Pfad) zugegriffen.

Punkt 4 ist bei der Entwicklung eigener Bibliotheken wichtig. Dadurch wird sichergestellt, dass beim erstellen der Bibliothek die aktuellen Header im Source-Verzeichnis verwendet werden und nicht die evtl. veralteten im globalen Include-Verzeichnis.

Veröffentlicht am

GIT Server unter Linux installieren

Die vergangenen Tage habe ich mich damit beschäftig, einen GIT Server unter Linux zu installieren. Nach ein paar Fehlschlägen ist es mir schließlich irgendwie gelungen. Um das so gelernte beim nächsten Mal (falls es denn ein solches gibt) nicht erst mühsam im Internet zusammensuchen zu müssen, habe ich mich entschlossen, meinen Weg zu diesem kleinen Erfolg hier aufzuschreiben. Vielleicht hilft es ja nicht nur mir, sondern auch anderen Linux-Neulingen.

Voraussetzungen

Was ich vorgefunden habe, war ein funktionierender Linux-Rechner (Mint 20) mit SSH Zugang und ein Benutzer mit den erforderlichen Rechten für sudo.

Server einrichten

Ich wollte mir möglichst wenig Arbeit machen. Daher wollte ich auf einen Server mit Web-Oberfläche verzichten. Einfach sollte es sein und funktionieren. Daher habe ich mich für GIT über SSH entschieden. Der SSH Zugang war schon vorhanden und GIT war auch schon installiert. Also musste ich nur noch den GIT Server einrichten. Dabei war dieserArtikel von Andrew Hoog sehr hilfreich.

GIT installieren

sudo apt install git

Neuen Benutzer für GIT anlegen

sudo adduser --disabled-password git
sudo su git
cd ~
mkdir repos
mkdir .ssh && chmod 700 .ssh
touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys

Zur Sicherheit sollte das normale Login für den git User unterbunden werden. Dieser Benutzer sollte nur die git-shell verwenden dürfen. Evtl. muss die git-shell vorher noch „installiert“ werden. Sehen wir also nach, ob sie bereits installiert ist.

cat /etc/shells

Wenn git-shell irgendwo in der angezeigten Liste erscheint, ist sie bereits installiert. Wenn sie fehlt, müssen wir sie zur Liste hinzufügen.

which git-shell
sudo nano /etc/shells

Der erste Befehl zeigt den vollständigen Pfad der Shell an. Wir merken uns den Pfad und fügen ihn mit dem zweiten Befehl zu /etc/shells hinzu. Eine Alternative zu diesen beiden Befehlen wäre wohl

sudo which git-shell >> /etc/shells

Ich habe es aber nicht ausprobiert und gebe daher darauf auch keine Garantie.

Zum Schluss muss der git User noch gezwungen werden, git-shell zu verwenden.

sudo chsh git -s $(which git-shell)

Benutzer hinzufügen

Für jeden Benutzer des GIT Servers muss ein öffentlicher Schlüssel hinterlegt werden. Nehmen wir einmal an, diese Schlüssel befinden sich bereits in den Dateien git-user1.pub, git-user2.pub usw. im Verzeichnis /tmp. Mit diesen Befehlen ordnen wir die Schlüssel (und deren Besitzer) dem git Account zu.

sudo cat /tmp/git-user1 >> /home/git/.ssh/authorized_keys
sudo cat /tmp/git-user2 >> /home/git/.ssh/authorized_keys
...

Repositorys einrichten

Mit folgenden Befehlen wird ein neues Repository in /home/git/repos eingerichtet:

ssh ich@my_server
cd /home/git/repos
sudo mkdir test.git
cd test.git && sudo git init --bare && cd ..
sudo chown -R git.git test.git

Natürlich kann man sich dafür ein kleines Skript schreiben, das den Namen des Repositorys als Parameter bekommt. Wenn man dieses Skript newrepo nennt, kann man ein neues Repository leicht mit zwei Befehlen erzeugen.

ssh ich@my_server
sudo ./newrepo repo_name

Clients einrichten

Auf jedem Rechner, von dem aus wir auf den GIT Server zugreifen wollen, müssen wir noch ein paar kleine Vorbereitungen treffen.

Zuerst müssen wir ein Schlüsselpaar erzeugen und den öffentlichens Schlüssel auf den Server kopieren, so dass wir ihn da zu den erlaubten Schlüsseln hinzufügen können (s. Benutzer hinzufügen)

cd ~/.ssh
# Windows: cd c:\users\ich\.ssh
# Schlüsselpaar erzeugen.
# Wenn nach dem Namen gefragt wird, geben wir „ich-git“ ein.
ssh-keygen
# Öffentlichen Schlüssel auf Server kopieren
scp ich-git.pub ich@my_server:/tmp

Jetzt müssen wir uns nur noch mit dem richtigen Schlüssel anmelden. Dazu fügen wir den folgenden Text in unsere SSH Konfiguration in ~/,ssh/config (unter Windows c:\users\ich\.ssh\config) ein.

Host git
 User git
 Hostname my_server
 IdentityFile ~/.ssh/ich-git

Jetzt können wir das erste Repository vom Server holen. Die URL dafür ist git:repos/test.git, also

git clone git:/repos/test.git

Der Server-Name git wird durch den „Host“ Eintrag in der SSH Konfiguration übersetzt in git@my_server. Zur Anmeldung wird der angegebene Schlüssel, dessen öffentlicher Teil auf dem Server hinterlegt sein muss, verwendet.

Auf meinem Windows-Rechner ist GIT for Windows installiert. Damit werden auch die erforderlichen Tools (ssh.exe, ssh-keygen.exe und scp.exe installiert). Je nach Einstellungen bei der Installation, kann es sein, dass die UnixTools nur in der git-bash im Suchpfad sind. Wenn sie (wie bei mit) im globalen Suchpfad gefunden werden, kann statt git-bash auch cmd, tcc oder eine anderer Shell verwendet werden.

Veröffentlicht am

What 3 Words

Seit einiger Zeit versucht die Firma what3words Limited ein neues System zum Auffinden von Positionen auf der Erde zu propagieren. Die Idee ist auf dem ersten Blick scheinbar genial. Die ganze Erde wird in 3×3 Meter große Quadrate unterteilt und jedes dieser Quadrate bekommt einen „Namen“, der aus drei Wörtern besteht. So lautet z.B. die Adresse meiner Lieblingspension „gewinner.beschlossene.zins“. Wenn ich allerdings den Besitzer nach der Adresse fragen würde, würde er vermutlich „muestreo.mutua.expresados“ antworten.

Angeblich hat dieses System schon große Verbreitung gefunden. Sowohl die mongolische Post als auch der britische Rettungsdienst benutzen das System schon. Aber ist das System wirklich so viel besser als das herkömmliche System mit Länge und Breite?

Einen klaren Vorteil kann what3words für sich verbuchen. Drei Wörter können sich die meisten besser merken als zwei Zahlen wie z.B. „N28° 11.898 W14° 07.393“. Aber die Freude über diesen Etappensieg ist nur von kurzer Dauer.

Beim nachschlagen der 3-Wort-Adresse habe ich einen einzigen Buchstaben vergessen und nach „gewinner.beschlossen.zins“ gesucht. Man beachte das fehlende „e“ am Ende von „beschlossen(e)“. Das Ergebnis war N65° 06.290 E20° 19.544. Ein Buchstabe mehr oder weniger kann also einen Unterschied von fast 5000km ausmachen und es ist, glaube ich, auch nicht ganz unerheblich, ob der Rettungsdienst nach Fuerteventura oder Nord-Schweden gerufen wird.

Und damit wären wir auch schon beim großen Nachteil von what3words. Wenn man zwei what3words Adressen sieht, kann man aus ihrer Ähnlichkeit oder dem Fehlen derselben nicht auf ihre Nähe oder Entfernung schließen. Bei klassischen Koordinaten ist das anders. Je größer die Differenzen der Längen und Breiten sind, um so größer ist die Entfernung. Wenn die Gradzahlen gleich sind, ist die Entfernung kleiner als 150km. Wenn auch die Minuten gleich sind, sind die Punkte weniger als als 2,5km voneinander entfernt. Für what3words Adressen geht so eine einfache Abschätzung nicht. Ein Buchstabe kann eine Entfernung von ein paar tausend Kilometern bedeuten und zwei völlig verschieden Wortkombinationen können denselben Ort beschreiben.

Übrigens – wenn ich den Besitzer meiner Lieblingspension nach deren (klassischen) Koordinaten fragen würde, würde er mir, vielleicht auf spanisch, dieselben Zahlen nennen, die ich angeben würde.

Veröffentlicht am

Good Bye Office

Aus Gründen, auf die ich hier nicht näher eingehen will, sah ich mich gezwungen, MS Office über Bord zu werfen und durch etwas vergleichbares zu ersetzen. Aber wodurch?

Also erst einmal eine Bestandsaufnahme. Welche Teile von MS Office benutze ich wirklich?

  1. Outlook für E-Mail, Kontakte und Termine
  2. OneNote für schnelle Notizen
  3. Ab und zu mal ein längerer Text mit Word
  4. Manchmal auch eine Berechnung mit Excel
  5. Access habe ich zwar auch benutzt, aber schon allein durch die Geschwindigkeit (oder besser das Fehlen davon) war diese Art von Datenbank nicht wirklich attraktiv für mich

Welche Alternativen habe ich gefunden?

Für Word und Excel habe ich schnell eine Alternative schnell gefunden – LibreOffice reicht für den Hausgebrauch.

Für OneNote habe ich keine Alternative gefunden. Aber das war auch nicht nötig. Schließlich gibt es OneNote auch unabhängig von Office und dazu noch kostenlos.

Am schwierigsten fiel die Entscheidung für E-Mail, wobei die Mails selbst eigentlich gar kein Problem waren. Brauchbare E-Mail Clients gibt es fast wie Sand am Meer, und die meisten davon kommen locker mit mehreren verschiedenen Servern gleichzeitig zurecht. Persönliche Vorlieben geben da eher den Ausschlag als objektive Gründe.

Mein Problem waren Kontakte und Termine. Diese habe ich in Cloud in einem (kostenlosen) Outlook Online Account geparkt. Da konnte ich sie bisher bequem zwischen Outlook, der Cloud und dem Handy synchronisieren kann. Statt bei Outlook hätte ich sie auch bei Google parken können. Was auch immer meine Alternative für Outlook werden wollte, musste mit dieser Situation arbeiten können.

Nach einiger Recherche mit Google blieben noch zwei Kandidaten übrig, mit denen ich mehr oder weniger so wie bisher weiter arbeiten konnte.

Wenn alles in einem einzigen Programm vereint sein soll, ist eM Client für mich die erste Wahl. E-Mails sind natürlich kein Problem, und auch Kontakte und Termine werden problemlos mit Outlook Online oder GMail synchronisiert. Einziger kleiner Wermutstropfen ist der Preis. Wenn man mehr als zwei Konten einrichten will, braucht man die Pro Version und die kostet ca. 60€. Die Oberfläche ähnelt Outlook, man muss sie aber nicht schön finden. Aber das Programm funktioniert allem Anschein nach einwandfrei.

Wenn man jedoch bereit ist, für E-Mail, Kontakte und Termine drei verschiedene Programm, die erstaunlich gut zusammenarbeiten, zu verwende, braucht man jedoch gar nicht so lange suchen. Die meisten Windows 10 Benutzer haben schon alles auf dem Rechner. Der mit Windows 10 gelieferte E-Mail-Client, der Kalender und die Kontakte können schon alles, was ich mir wünsche.

Access war für mich kein akutes Thema. Wenn ich eine Datenbank brauche, benutze ich meistens SQLite oder MySQL. Irgendwo habe ich habe zwar noch ein paar alte Access Datenbanken rumliegen, aber die graphische Oberfläche habe ich schon jahrelang nicht mehr benutzt. Und die aktuellen ODBC, OLE DB und .NET Connectoren für Access gibt es natürlich immer noch kostenlos.

Veröffentlicht am

Pappa’s First

Der Name war Programm und dies sollte mein erster Geocache werden. Warum gerade der? Ganz einfach. Es war der nächste und es sollte die Generalprobe für die Suche auf Fuerteventura werden. Aber ich hatte noch viel zu lernen.

Ganz schnell gelernt habe ich, dass es bei der Suche nach einem Cache auf die richtige Zeit ankommt. Und der 1. Mai ist definitiv keine gute Zeit. Viel zu viele Muggle unterwegs. Aber irgendwie habe ich es doch geschafft, unbeobachtet zu bleiben.

Die Suche war anfangs sehr einfach. So ungefähr wusste ich, wo ich hin musste und mit dem GPS kam ich recht einfach in die Nähe des Caches und schon bald wusste ich, dass mein Ziel 5-10 Meter links vom Weg lag. Aber da musste ich erst einmal hin kommen. Eigentlich kein Problem, aber am 1. Mai? Es dauerte schon eine Weile bis ich mich ungesehen in die Büsche schlagen konnte. Im Schutz der Büsche war die suche dann einfach und unbeobachtet. Und so fand ich meinen ersten Cache.

Veröffentlicht am

Hello world!

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!