Boost - Hallo Welt

Hallo Welt will einfach nicht laufen. :frowning:
Bin sooooo sehr frustriert. wieee geht nicht mehr… grummel.

Also ich hab jede Menge Libs.

Z.B. C:\Program Files\boost\boost_1_51\lib\boost_regex-vc100-mt-1_51.lib

Und ebensoviele Header.

Z.B. C:\Program Files\boost\boost32bit_1_51\boost\regex.hpp

Aber Code-Blocks meldet einfahch main.cpp|4|error: boost/xpressive/xpressive.hpp: No such file or directory|

Meine Einstellungen:

Unter Settings > Compiler > Other Options

C:\Program Files\boost\boost_1_51\boost\
C:\Program Files\boost\boost_1_51\boost\regex.hpp

Unter Settings > Linker Settings

C:\Program Files\boost\boost_1_51\lib\boost_regex-vc100-mt-1_51.lib

Hier der Code:

#include 
#include 

using namespace boost::xpressive;

int main()
{
 std::string hello( "hello world!" );

 sregex rex = sregex::compile( "(\\w+) (\\w+)!" );
 smatch what;

 if( regex\_match( hello, what, rex ) )
 {
 std::cout 

Hallo Fragewurm,

Aber Code-Blocks meldet einfahch main.cpp|4|error:
boost/xpressive/xpressive.hpp: No such file or directory|

Meine Einstellungen:

Unter Settings > Compiler > Other Options

C:\Program Files\boost\boost_1_51\boost\
C:\Program Files\boost\boost_1_51\boost\regex.hpp

Unter Settings > Linker Settings

C:\Program
Files\boost\boost_1_51\lib\boost_regex-vc100-mt-1_51.lib

Du hast immer noch das selbe Problem: /t/boost-regex-hpp-no-such-file-or-directory/7018845

Aber hier weiss keiner, wo du die Datei „xpressive.hpp“ auf deiner Festplatte abgelegt hast.

Am besten lässt du mal dein Betriebssystem nach der Datei auf der ganzen Festplatte suchen.
Dann vergleichst du den gefunden Pfad mit dem was du eingetragen hast.
Und je nach Betriebssystem musst du auch auf die Gross/Kleinschreibung achten.

MfG Peter(TOO)

#define boost C:\ …
Hallo Peter,

Du hast immer noch das selbe Problem:
/t/boost-regex-hpp-no-such-file-or-directory/7018845

Aber hier weiss keiner, wo du die Datei „xpressive.hpp“ auf
deiner Festplatte abgelegt hast.

Mit
#include
kommt der (fast) selbe Fehler einige Zeilen später.

Hoffte durch

#define boost C:\Program Files\boost\boost_1_51\boost\

den Fehler global behaben zu können, aber meine define Präprozessoranweisung scheint leider keinen Einfluss zu haben.

herzlich

Hallo Fragewurm,

Mit
#include
kommt der (fast) selbe Fehler einige Zeilen später.

Und welcher Fehlertext genau??

MfG Peter(TOO)

Und es wurde Licht … :

Project > propherties > Project / target options >
> Project build options > Select Compiler (GNU CCC Compiler) > Search directories >

#define boost C:\Program Files\boost\boost_1_51\boost\

falsch (im sinne von scheinbar wirkungslos) war Einstellugne unter

Settings > compiler and debugger > Search directories usw vorzunehmen.

Dort hatte/habe ich ne lib und auch header-Verzeichnis angegeben.

jedenfalls ! hurrra !! :smile:

hatten zeitgleich gepostet - danke (siehe oben)
danke peter

hatten zeitgleich gepostet - danke (siehe oben)

bei der gelegenheit nenne ich noch mal die ide

Code::Blocks 10.05!

:frowning: leider wurde nur alte exe ausgeführt
codeBlocks hat über

build and run (f9-taste)

nur die alte exe ausgeführt.

schade.

habe jetzt statt „hallo welt“ ne andere meldung damit ich nicht wieder darauf reinfalle.

Tausende Ersetzungen
Hallo

Aber hier weiss keiner, wo du die Datei „xpressive.hpp“ auf
deiner Festplatte abgelegt hast.

Am besten lässt du mal dein Betriebssystem nach der Datei auf
der ganzen Festplatte suchen.

Ich habe jetzt radikal

alle

#include

und andere ähnliche mehr

bald stelle sich herraus das die include anweisungen sehr unterschiedlich sind und arbeiten mit regulärem Ausdruck wurde notwenig:

#\s*include Resultat:

Nun wurden tatsächlich (scheinbar) alle Dateien gefunden,
aber es wurden über 500 Fehler gemeldet.

Z.B.
321 31 C:\Program Files\boost\boost32bit_1_51\boost\smart_ptr\detail\shared_count.hpp [Error] expected ‚,‘ or ‚…‘ before ‚&&‘ token

So scheint es auch nicht zu gehen.

Irgendwie muss man der IDE beibringen, dass sie dem Compiler sagt, dass immer auch in C:\Program Files\boost\boost32bit_1_51\boost/
gesucht werden soll.

Der ganze Workaround hat nix gebracht. Immerhin ein bisschen Erkenntniss. Sad :frowning:

Hallo Fragewurm,

Z.B.
321 31 C:\Program
Files\boost\boost32bit_1_51\boost\smart_ptr\detail\shared_count
.hpp [Error] expected ‚,‘ or ‚…‘ before ‚&&‘ token

Dies ist aber ein Syntaxfehler!
Die Fehlermeldug besagt nur, dass dieser Syntaxfehler in dieser Datei gefunden wurde.

C kann recht hinterlistig sein, was Fehler angeht.
Viele Fehlermeldungen gaben nur an, dass der Fehler sich zwischen dem Anfang der Datei und dem Punkt an welchem er gemeldet wird befindet.
Ein fehlender „;“ kann erst 100te Zeilen später zu einem Fehler führen.

Auch fehlerhafte „#define“ führen meist erst an der Stelle wo sie verwendet werden zu zu einer Meldung.

Auch neigt C dazu nach einem Fehler viele Folgefehler zu erzeugen. Deshalb ist es wichtig immer mit den ersten gemeldeten Fehler zu beginnen.

Noch etwas zum Verständnis:
Der Preprocessor, also grob alle Befehle welche mit einem „#“ beginnen, ist mehr eine Art von Texterarbeitung und hat mit der Sprache eigentlich nichts am Hut. Die meisten Preprocessor-Befehle sind eine Art von „Suchen und Ersetzen“ wie bei der Textverarbeitung.
#include“ fügt einfach an dieser Stelle die gefundene Datei ein.

Erst diesen aufbereiteten Text, bekommt dann der eigentliche Compiler zur Verarbeitung verfüttert.

Der klassische Verarbeitungsablauf ist folgender:

Preprocessor -> C-Compiler -> Assembler -> Linker

Für C++ wurde ursprünglich einfach eine zusätzliche Stufe zwischen Preprocessor und C-Compiler eingefügt.

Unter Unix gab es auch einen BASIC-Compiler, welcher einfach BASIC in C übestzte und dann wie ein C-Programm weiter verarbeitet wurde.

Dabei besteht jeder Schritt aus einem eigenständigen Programm und dieses erzeugt eine Datei für die nächste Stufe.

MfG Peter(TOO)

Compiler sucht nicht, sondern setzt Pfade zusammen
Hallo Peter,

vor dem schlafen wollte ich doch noch mal was ausprobieren und es hat geklappt.

Bei der ganzen Ersetzerrei wurde offensichlich, dass es wohl nur darum geht, das der Compiler die Header nicht findet.

321 31 C:\Program
Files\boost\boost32bit_1_51\boost\smart_ptr\detail\shared_count
.hpp [Error] expected ‚,‘ or ‚…‘ before ‚&&‘ token

Dies ist aber ein Syntaxfehler!

Ja, aber wohl eine Folge meiner Ersetzungsbemühungen.

Bisher hatte ich ja mit dem Verzeichnis

C:\Program Files\boost\boost32bit_1_51\boost\

hantiert und nicht

mit

C:\Program Files\boost\boost32bit_1_51\

und das alleine war der Fehler.

Irgendwie hatte ich durch meine vorigen Versuche mit dem Path (Umgebungsvariable) daran geglaubt (inuitiv, wenig durchdacht),
dass
dieses boost wie eine Konstante zu handhaben wäre die dann ersetzt wird.

Hätte ich dabei eher an sowas wie DocumentRoot (wie bei Webseiten) und relativer Verlinkung gedacht, wäre es mir gelich aufgefallen.

In Ersetzungen zu denken war der falsche Ansatz. Nein es ist einfach sowas wie der Root Folder.

Ich weiss nicht genau, wie das mit den directories funktioniert die man dem Compiler mit angibt.

Eigentlich dachte ich er durchsucht die Ordner nach Header, wenn er Sie im Porjekt - Ordner oder sonstwo nicht gefunden hat.

Daher schien mir es nicht so wichtig wie der Pfad genau ist.
Hauptsache die Header sind dort drin zu finden (waren sie ja auch), nur hat der Compiler sie trotzdem nicht gefunden, weil er ja nicht wirklch sucht, sondern nur den Pfad anbaut.

Aber da würde ich lieber mal nicht von Suchen sprechen (so wie man es von sich selbst kennt wenn man Dateien ab einem Ordner inklusive Unterordnern sucht).

Tja. Es musste nicht ein Ordner zu den Headern, sondern zu der Include Angabe unter den „Projekt Options“ angegeben werden.

Mit anderen Worten bzw. konkreter:

Damit hier

#include

funktioniert

bedurfte es unter DEC++„Projekt Options“ > Directories > Include Directories

NICHT

C:\Program Files\boost\boost_1_51\boost\

(ebenso sinnlos war es diesen Pfad an anderen Directorie - Samelstellen der IDE einzugeben).

Dies führte zu

#include

und nicht (was richtig ist)

#include

Das war der ganze Fehler. Die Denkweise, der Compiler würde ähnlich wie in einer grossen Bibliothek nach einem Buch gesucht wird einfach die Header-Dateien in einerm Pfad (inklusive Unterordner) suchen.

Weit gefehlt. Er setzt einfach die Pfade zusammen.

Weil man in der IDE an mehreren Stellen Pfadangaben machen konnte und zu BOOST etliche Anleitungen im Web sind, dieses Projekt so gross ist, dachte ich nciht an einen soooo einfachen Fehler. Naja. Hat etliche Wochen gedauert. Wie grausam ! :smiley:

Danke.
Deine sonsigen Erläuterungen, werde ich mir noch mal genauer Anschauen. Danke.

Hallo Fragewurm,

Weit gefehlt. Er setzt einfach die Pfade zusammen.

Weil man in der IDE an mehreren Stellen Pfadangaben machen
konnte und zu BOOST etliche Anleitungen im Web sind, dieses
Projekt so gross ist, dachte ich nciht an einen soooo
einfachen Fehler. Naja. Hat etliche Wochen gedauert. Wie
grausam ! :smiley:

Deshlb habe ic dir in der ersten Antwort schon gschriebn, dass wir nicht wissen WO deine Daeien auf der estplatte rumgammeln :wink:

Somit konnten wir auch aus der Ferne deine Pfadangaben nicht überprüfen.

Naja, ich denke, dass du DIESEN Fehler nie mehr machen wirst :wink:

Es gibt übrigens 2 Formen von include:
#include „datei“
und
#include

„datei“ sucht zuerst im gleichen Verzeichnis in welchem sich die Source-Datei befindet und sucht dann die eingestellten Pfade ab.
sucht zuerst in den angegebnen Pfaden und erst dann im aktuellen Vereichnis.
Wie das genau gehandhabt wird, ist aber je nach Compiler etwas unteschiedlich und steht im Compiler-Handbuch (meist im Anhang unter den implementierungsspezifischen Angaben).

Ursprünglich hat man den Standardpfad auf die Systembibliothek gesetzt.
Eigene Includes hat man dann mit „datei“ eingebunden und diejenigen welche zum System gehören mit .

Der Sinn dahinter liegt darin, dass man manchmal eine Bibliotheks-Datei mit einer eigenen übersteuern will und nicht den ganzn Pfad angeben will oder kann.

MfG Peter(TOO)

1 Like

Hallo Peter,

„datei“ sucht zuerst im gleichen Verzeichnis in welchem sich
die Source-Datei befindet und sucht dann die eingestellten
Pfade ab.
sucht zuerst in den angegebnen Pfaden und erst dann im
aktuellen Vereichnis.

betrachten wir dazu, was der Standard (ANSI-ISO 9899 1999) sagt:

A preprocessing directive of the form
# include new-line
searches a sequence of implementation-defined places for a header identified uniquely by
the specified sequence between the delimiters, and causes the replacement of that
directive by the entire contents of the header. How the places are specified or the header
identified is implementation-defined.

A preprocessing directive of the form
# include „q-char-sequence“ new-line
causes the replacement of that directive by the entire contents of the source file identified
by the specified sequence between the " delimiters. The named source file is searched
for in an implementation-defined manner. If this search is not supported, or if the search
fails, the directive is reprocessed as if it read
# include new-line
with the identical contained sequence (including > characters, if any) from the original
directive.

Insbesondere im unterstrichenen Fall und bei Allerweltsnamen fuer die Headerfiles fuehrt das gerne zu Problemen, an denen Beginner verzweifeln koennen (z.B. wenn Verzeichnisse nicht die richtigen Rechte besitzen).

In beiden Faellen unterliegt im uebrigen auch „.“ (implizit oder explizit) der genannten Suchreihenfolge.

Gruss
n.