Hi,
ich mach gerade meine ersten Gehversuche mit glew. Ich habe via SDL_SetVideoMode ein Fenster erzeugt und rufe nun glewInit auf. Diese Funktion ruft offenbar glewContextInit auf, in der es eine Zugriffsverletzung gibt. Und zwar in dieser Zeile (8017):

Ich habe glew.c inkludiert, welche sich auch um die Einbindung von glew.h kümmert. Wenn ich glew.h explizit auch include, ändert es auch nichts. Irgendwelche Libraries habe ich nicht gelinkt, da keine im Download-Zip drin waren. Brauche ich vielleicht noch eine, wenn ja woher?

Danke schonmal im Voraus für eure Hilfe!

Du solltest "glew.h" includen und gegen die glew-Library linken, die man von dort bekommt. Ohne Library wirds wohl nicht funktionieren...

Ach, danke das du mich nochmal zur Download page verlinkt hast. Mir ist gar nicht aufgefallen, dass es einmal den Src- und einmal den Bin-Download gibt.

Habe mir jetzt also auch die Libraries runtergeladen und sie gelinkt. Leider ändert es nichts daran, dass ich immer noch eine Zugriffsverletzung bekomme.

Edit: Nachdem ich glew.c wieder rausgeworfen habe, läuft es jetzt einwandfrei. Danke für deine Hilfe!

In C/C++ inkludiert man immer nur den Header, nicht den eigentlichen Quellcode in *.c oder *.cpp Dateien.

_________________
Yeah!

Und woher weiß dann der Compiler (wenn es keine Library gibt), wo die ganzen Definitionen für die im Header deklarierten Funktionen sind? Ich hab bei selbst geschriebenen Headern bisher immer die cpp inkludiert und es hat immer funktioniert.^^ Wüsste nicht warum man die Cpps weglassen sollte.

Die .cpp Dateien enthalten den eigentlichen Quellcode, die Header definieren meistens nur die Schnittstelle.
Damit der Quellcode auch im fertigen Programm ankommt, wird dem Compiler die .cpp Datei zum kompilieren übergeben. D.h. wenn du jetzt z.B. den Source Code von glew einbinden willst, und nicht die lib benutzt, includierst du überall die glew.h und gibst dem Compiler die glew.c mit auf den Weg. Der kompiliert die glew.c dann fest in das Programm und alle anderen Code Dateien holen sich die Infos aus dem glew.h Header.

Wenn du die lib benutzt, includierst du auch nur die glew.h, sagst dem Compiler (bzw. dem Linker) aber, dass er die Bibliothek einbinden soll, das geht entweder mit einer statischen Bibliothek, wobei der Code dann in die Binary deines Programms übernommen wird, oder, bei dynamischen libs, erhält die Binary nur die Information, dass diese Bibliothek zur Laufzeit geladen werden soll. Die Informationen über die Orte der Funktionen etc. stehen weiterhin in dem glew.h Header.

Die Compiler bzw. Linker Optionen werden meistens von einer IDE übernommen, d.h. wenn du in der IDE angibst, dass er die lib linken soll, dann reicht die IDE das beim kompilieren an den Linker weiter.
Wenn du in einer IDE den Source Code einbinden willst, dann reicht es meistens die entsprechende .c/.cpp Datei in das Projekt aufzunehmen, alle Code Dateien in einem Projekt werden dann für gewöhnlich einfach dem Compiler übergeben.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Und wo ist jetzt der Vorteil, wenn ich alles einzeln kompiliere und als Bibliotheken linke? Ich finde es jedenfalls einfacher, wenn ich einschreibe stattoder Units in irgendwelche Listen eintrage.

Die Idee ist das jede *.cpp Datei zu einem sogenannten Objectfile *.o compiliert wird. Der Linker fügt dann die ganzen Objectfiles zusammen zu einer ausführbaren Datei.

Vorteil 1: Wenn du in einer *.cpp Datei etwas änderst (häufig, hier ist ja der Großteil des Quellcodes) muss nur das zugehörige Objectfile neu erzeugt werden und der Linker muss die ausführbare Datei neu linken. Aber der Rest des Programms muss NICHT neu compiliert werden!

Vorteil 2: Da die Objectfiles unabhängig voneinander sind können sie gleichzeitig compiliert werden. Z.B. hier am Lehrstuhl haben wir ein System das alle verfügbaren Rechner und CPU-Kerne im Netzwerk nutzt, d.h. man hat effektiv einen 40-Kerner und das compilieren geht entsprechend quasi 40mal schneller. Aber auch mein QuadCore zu Hause lässt sich dann mal wirklich nutzen.

_________________
Yeah!

Nun gut bei Extremprojekten (Linux-Kernel oder so?) mag es ja sinnvoll sein, dass man so unglaublich schnell kompilieren kann bzw. nur kleine Teile neu kompilieren muss. Für private Projekte zweifel ich den Nutzen dennoch an. Ich glaube ich hatte noch nie ein Programm, das länger als 20 Sekunden kompiliert hat und das wahrscheinlich auch nur auf einem Prozessorkern.

edit: Obwohl ich muss zugeben, ich weiß nicht, wie lange es dauern würde, wenn jedes Mal die stdlib neu kompiliert werden müsste.

Ich weiß nicht was du für Projekte machst....aber wenn du am Bug suchen bist und immer wieder kleinere Änderungen machst geht dir das kompilieren schnell auf die nerven
Die Hauptanwendung meiner Diplomarbeit braucht durchaus schon mal einige Minuten zum compilieren, wenn nur ein Kern verfügbar ist. Hängt aber auch stark vom Rechner und dem aktuellen Zustand des Festplattencaches ab. Das ganze ist zudem auch eine Qt-Anwendung, d.h. es gibt zusätzliche *.ui-Files die die GUI als XML beschreiben und natürlich müssen alle selbst geschriebenen Qt-Objekte nochmal durch den Meta-Object Compiler (MOC) der die Spracherweiterungen von Qt (*) in normalen C++-Code umwandelt.


(*) Signals und Slots sind toll

_________________
Yeah!