Probleme mit statischer Lib



  • ich bastel mir gerade eine statische Bibliothek mit allen möglichen Mathe-Klassen (vector2d, vector3d, matrix3x3, matrix4x4, quaternion usw.)

    Der Header der Lib sieht so aus:

    /* ------------------------------------------------------------------------------------------------
    		MATHLIB.H
      Headerfile containing all mathematical classes and routines
      Created: August 10, 2003 by Jan-Philipp Follenius
    */
    
    #ifndef MATHLIB_H_
    #define MATHLIB_H_
    
    #include <cmath>
    
    #include "Vector2D.h"
    #include "Vector3D.h"
    #include "Matrix3x3.h"
    #include "Matrix4x4.h"
    
    #endif
    

    Die dort eingebundenen Header stellen Klassen bereit wie Vector2D, Vector3D, Matrix3x3 usw., die auch inline-Funktionen benutzen. Diese Funktionen benutzen die Funktionen sqrt und fabs aus <cmath> und binden diese auch ein.

    Jetzt zur Anwendung, die die Library benutzen soll: die Anwendung ist verlinkt zu MathLib.lib und bindet die Headerdatei MathLib.h ein. Die Verzeichnisse sind korrekt eingestellt.

    // main.cpp: MathLib test application 
    
    #include <MathLib.h>
    
    int main(int argc, char *argv[]) {
    	return 0;
    }
    

    Trotz allem beschwert sich aber immer der Compiler mit zwei Fehlermeldungen

    c:\Vector2D.h(34) : error C2065: 'sqrt' : nichtdeklarierter Bezeichner
    c:\Vector2D.h(43) : error C2065: 'fabs' : nichtdeklarierter Bezeichner
    Fehler beim Ausführen von cl.exe.

    Wo liegt der Fehler?

    Danke schon mal. Mfg, smasher1985



  • wenn du den Visual C++ 6 verwendest:

    der hat 'nen Fehler in der Standardbibliothek, so dass alle Funktionen aus <cmath> im globalen Namensraum und nicht im namespace std liegen

    (zum gleichen Problem gibts noch 'nen Thread auf der 1. Seite 😉 )



  • @Blue-Tiger: ja, und der andere Thread war auch von mir 😉 aber das eine hat doch mit dem anderen nichts zu tun, oder? Selbst wenn die Funktionen sqrt und fabs im globalen Namensraum liegen und nicht - wie man erwarten sollte - im Namensraum std, ändert das nichts daran, dass ich zwei Compilerfehler bekomme, wenn ich meine statische Lib benutzen will. Ich hab den Fehler beim MSVC++6 ja akzeptiert und verwende die Funktionen ohne std und ohne Scope-Operator...

    Mfg, smasher1985



  • Ok, ich hab das ganze nochmal auf ein Minimalbeispiel reduziert. Ich verwende MSVC++6 und habe eine statische Library erstellt, welche aus 3 Dateien besteht:
    testlib.cpp, testlib.h und a.h

    testlib.cpp

    // testlib.cpp
    #include "testlib.h"
    

    testlib.h

    // testlib.h
    #ifndef TESTLIB_H_
    #define TESTLIB_H_
    
    #include "a.h"
    
    #endif
    

    a.h

    // a.h
    #include <cmath>
    
    class a {
    public:
      void f() { sqrt(12); }
    };
    

    So, das sei meine statische Library.

    Testprogramm

    Mein Testprogramm wird verlinkt zur testlib.lib und sieht so aus:

    // test.cpp
    #include "testlib.h"
    
    int main(int argc, char* argv[]) {
    }
    

    Das führt jetzt zu einem Compilerfehler:

    :\a.h(5) : error C2065: 'sqrt' : nichtdeklarierter Bezeichner

    So, das war jetzt hoffentlich ausführlich genug, so dass mir jemand helfen kann. Wodurch wird dieser Compilerfehler ausgelöst?

    Mfg, smasher1985



  • Du machst mit

    // a.h 
    #include <cmath> 
    
    class a { 
    public: 
      void f() { sqrt(12); } 
    };
    

    die Funktion f() inline. D.h. der Code dafür steht im Header und liegt nicht compiliert in der statischen Lib vor. Das ganze wird dann erst in Deinem Testprogramm übersetzt und da hast Du cmath ja nirgendwo eingebunden.



  • Dann sollte aber bei folgendem Testprogramm alles funktionieren:

    // test.cpp 
    #include <cmath>
    #include "testlib.h" 
    
    int main(int argc, char* argv[]) { 
    }
    

    Jetzt werden zwar die inline-Funktionen erst in dieser Übersetzungseinheit übersetzt, haben aber doch Zugriff auf die Mathe-Routinen sqrt und fabs, weil ich <cmath> einbinde.
    Das funktioniert aber nicht, sondern führt zu denselben Compilerfehler wie vorher...

    Das kanns also irgendwie nicht sein...

    Mfg, smasher1985


Anmelden zum Antworten