Hallo!
Jetzt, in den Ferien, hab ich mir C++ mal vorgenommen und mir dafür auch Boost geholt. Nun muss ja beim Kompilieren -I /pfad/zu/boost angeben, was aber bissl stört, was man öfter was re-kompiliert. Daher die Frage: Gibtt es irgendeine Umgebungsvariable zu der ich “/pfad/zu/boost” dazugeben könnte, sodass automatisch in dieses Verzeichnis geschaut wird? Ich meine, bei #include <> wird ja auch in dem vorher irgendwo festgelegten Standart-Verzeichnis gesucht.
So richtig kapier ichs nicht, aber… du willst boost einbinden?
Hab hier ein Tutorial gefunden, welches dies erklärt, allerdings fürs VS (weiß ja nicht, was du für eine IDE benutzt).
Die Bibliothek hab ich schon kompiliert und gebaut, auf Ubuntu. Aber trotzdem danke für den Link. Unter Windows werd ich es sicherlich auch probieren!
Für ne IDE hab ich mich auch noch nicht entschieden. Anjuta hab ich probiert, hat mir aber nicht so gut gefallen, weil wenn man z.B. eines Projekt beginnt, sehr viele (für mich unnötige) Dateien miterstellt werden, wie AUTHORS, README, Makefile usw., und ich es nicht auf die Reihe krieg wie man das einschränkt. Momentan bin ich bei KDevelop…mal schauen. Bleiben noch NetBeans und Code::Blocks. Hat jemand (gute/schlechte) Erfahrungen damit?
Zu meiner Frage (unter Ubuntu): So wie ich mir das vorstelle, benützt der Präprozessor eine Variable in der der Pfad zum Standard-Include-Verzeichnis steht. Und je nach dem ob da #include „foo.h“ oder #include <foo.h> steht, wird zuerst im aktuellen Folder geschaut ($PWD?) oder eben im Standard-Verzeichnis. Ich weiß nicht, ob das Bild was ich jetzt hab korrekt ist, aber wenn es das ist, dann muss es doch möglich sein dem Präprozessor mitzuteilen, er möge bitte auch in meinem /pfad/zu/boost nachschauen, wenn er ein #include <foo.h> antrifft (oder #include „foo.h“).
Wenn das nicht geht, ist es auch nicht schlimm. Immerhin ist es eher eine theoretische Frage, die eher aus dem Wunsch entstanden ist, beim Kompilieren nicht jedesmal dem Pfad angeben zu müssen.
Warum packst du das nicht in ein Verzeichnis, welches der Präprozessor findet?
Ja, das werd sicherlich das nächte Mal machen, im April, wenn ich die neue Version von Ubuntu installiere.
Aber zum Einen hab ich jetzt schon den „Fehler“ gemacht es nach /lib zu packen (und möchte ungern das procedere nochmal durchführen) und zum Anderen bin ich mir nicht ganz sicher was nun eigentlich der Standard-Include-Pfad ist.
Also der Standard-Include Pfad auf Linux müsste eigentlich /usr/include sein. Darin musst Du die boost Bibliotheken in einen Ordner namens boost kopieren. In /usr/lib dann noch die kompilierten Bibliotheken und der g++ sollte die header-files finden sofern Du sie wie folgt includierst: #include <boost/shared_ptr.hpp> usw. Bei Benutzen von DateTime, Regexp, etc. musst Du bekanntlich linken und solltest beim kompilieren -lboost_datetime_* mit angeben. Der ld sucht standardmäßig in /usr/lib.
Gut Schuß
VuuRWerK 
Das wäre ja auch ne Pfadangabe. Sowas will er ja nicht (soweit ich das verstanden habe).
Ok, kann man auch noch wegbekommen, man legt einfach keinen boost-Ordner in /usr/include an, aber das sorgt in meinen Augen nur für ein Datei „Wirr-Warr“. Generell ist es in C/C++ so das man bei Fremdbibliotheken immer ein Verzeichnis in /usr/include mit dem namen der Bibliothek hat und darin befinden sich alle header-files (inkl. Unterordner). Und ins einem eigene Quellcode spricht man diese dann wie oben geschrieben über bspw. boost/.hpp an.
Zumal es gerade bei boost zu den „include-all-header“(z.B. boost/asio.hpp) ja noch die jeweiligen seperaten Header gibt, z.B. boost/asio/ip/address.hpp und bei diesem Beispiel geht es sogar noch genauer: boost/asio/ip/address_v4.hpp oder boost/asio/ip/address_v6.hpp.
Das aber mal nur als Beispiel wieso es sich immer anbietet eigene Ordner für jede Bibliothek anzulegen.
Und wenn man doch mal eine lib verwendet wo die Header sich nicht in /usr/include befinden kann man immernoch über -I/path/to/other/lib/include dem Compiler verraten wo die Header liegen. Und heutzutage mit IDEs und/oder Makefiles alles überhaupt kein Aufwand mehr.
Gut Schuß
VuuRWerK
Ja, die Option hab ich bei Netbeans gefunden, danke!
Hab ne Frage zu einem ganz anderen Thema: Wie sieht es mit Signalen in C++ aus? In C hab ich immer am liebsten sigaction() verwendet, in der C++Refence ist jedoch nur signal() erwähnt. Hat es damit zu tun, dass C++ C90 “berücksichtigt” und nicht C99?
Das mit den Signalen hat sich jetzt auch erledigt.
[QUOTE=Evgeni]Hallo!
Jetzt, in den Ferien, hab ich mir C++ mal vorgenommen und mir dafür auch Boost geholt. Nun muss ja beim Kompilieren -I /pfad/zu/boost angeben, was aber bissl stört, was man öfter was re-kompiliert. Daher die Frage: Gibtt es irgendeine Umgebungsvariable zu der ich “/pfad/zu/boost” dazugeben könnte, sodass automatisch in dieses Verzeichnis geschaut wird? Ich meine, bei #include <> wird ja auch in dem vorher irgendwo festgelegten Standart-Verzeichnis gesucht.[/QUOTE]
Jetzt habe ich gefunden, wonach ich gesucht habe:
export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:/opt/local/include
export LIBRARY_PATH=$LIBRARY_PATH:/opt/local/lib
p.s. warum kann ich nicht meine Beiträge bearbeiten? Ist diese Option irgendwie zeitlich begrenzt?
Kurz zur Info: Signals haben nix mit C oder C++ zu tun sondern sind OS-Spezifisch. Auf Windoof bspw. gibt es keine Signale, da gibts nur Messages. Ist am Ende dasselbe aber man nutzt diese jeweils anders.
Maximal könnte man einen Wrapper bauen (sofern es nicht schon einen gibt) wo man allen Signals/Messages eindeutige Bezeichner gibt und dann für die jeweiligen Plattformen implementiert. Aber kA ob das so auch Sinn macht da Signals/Messages erst so richtig bei der GUI-Entwicklung zum tragen kommen und da wurden natürlich in den jeweiligen plattformunabhängigen Bibliotheken solche Wrapper von vornherein implementiert.
Gut Schuß
VuuRWerK