Link Error

Hab mal die bound.cpp,bound.h und eine kleine main hochgeladen.
http://rapidshare.com/files/409873234/link_error_2010_07_29.zip

Ich wette es ist einfach etwas banales... nur ist es nach einem ganzen tag programmierarbeit nicht mehr möglich die eigenen fehler zu sehen.

hier ein komplettes VS2010 projekt.
http://rapidshare.com/files/409875842/link_error_project_2010-07-29.zip
Wäre dankbar wenn jemand drüberschauen könnte bevor ich hier komplett verzweifel.

SeppJ

linker_ schrieb:

Hab mal die bound.cpp,bound.h und eine kleine main hochgeladen.
http://rapidshare.com/files/409873234/link_error_2010_07_29.zip

Ich wette es ist einfach etwas banales... nur ist es nach einem ganzen tag programmierarbeit nicht mehr möglich die eigenen fehler zu sehen.

Sei mal sparsamer mit dem inline. Inline macht eine Funktion nämlich auch static für die Übersetzungseinheit, daher deine Probleme. Außerdem können viele Compiler meistens ganz gut selber entscheiden, welche Funktionen inline sein sollen. Daher ingorieren sie dieses Schlüsselwort mehr oder weniger - bis auf die Tatsache, dass inline Funktionen auch automatisch static sind.

Wenn du den Compiler eher darauf stoßen möchtest, eine Memberfunktion inline zu machen, solltest du kurze Funktionen direkt in der Klassendeklaration definieren. Dann kann das auch ein etwas weniger stark optimierender Compiler (einer der nicht das ganze Programm auf einmal optimiert) inline machen. Und dann stört auch nicht das static. Und du musst übrigens auch nicht inline davor schreiben, falls du dies machst, denn Funktionen die direkt in der Klasse definiert werden, sind automatisch inline.

P.S.: Und man kann es übrigens auch übertreiben mit const-correctness :p

SeppJ schrieb:

linker_ schrieb:

Hab mal die bound.cpp,bound.h und eine kleine main hochgeladen.
http://rapidshare.com/files/409873234/link_error_2010_07_29.zip

Ich wette es ist einfach etwas banales... nur ist es nach einem ganzen tag programmierarbeit nicht mehr möglich die eigenen fehler zu sehen.

Sei mal sparsamer mit dem inline. Inline macht eine Funktion nämlich auch static für die Übersetzungseinheit, daher deine Probleme. Außerdem können viele Compiler meistens ganz gut selber entscheiden, welche Funktionen inline sein sollen. Daher ingorieren sie dieses Schlüsselwort mehr oder weniger - bis auf die Tatsache, dass inline Funktionen auch automatisch static sind.

Volltreffer
Das mit dem static habe ich nicht gewusst...
Ich dachte nur dass er den code an der stelle einsetzt sonst nichts.

SeppJ schrieb:

P.S.: Und man kann es übrigens auch übertreiben mit const-correctness :p

Das ist Schulbuchprogrammieren
Schadet es wenn da zuviel const ist? Kostet es performance?

Danke übrigens für die guten tipps. hat auf Anhieb geklappt.

SeppJ

linker_ schrieb:

SeppJ schrieb:

P.S.: Und man kann es übrigens auch übertreiben mit const-correctness :p

Das ist Schulbuchprogrammieren
Schadet es wenn da zuviel const ist? Kostet es performance?

Danke übrigens für die guten tipps. hat auf Anhieb geklappt.

Nein, schaden tut's nicht. Ich fand's nur etwas komisch zu sehen, dass jemand tatsächlich Parameter die by-value übergeben werden als const markiert. Da habe ich erstmal drüber nachdenken müssen, ob da ein tieferer Sinn hinter steckt. Bis ich drauf kam, dass es keinen Sinn macht. Insofern kostet es Entwicklerperformance .

Nexus

linker_ schrieb:

Schadet es wenn da zuviel const ist?

Ja, es schadet, weil es nichts nützt, aber gleichzeitig irrelevante Informationen in die Schnittstelle bringt. In der Implementierung (Funktionsdefinition) kannst du das machen, es bringt auch da nicht viel, aber im API hat das nichts zu suchen. Oder was soll es den Aufrufer interessieren, ob die Funktion die kopierten Parameter ändert? Ich würde mir const für die wichtigen Fälle (in Parameterlisten also Zeiger und Referenzen auf const -qualfizierte Objekte) reservieren, damit ich eine entsprechende Semantik schneller erkenne.

padreigh

Nur der Interesse halber, das hier wäre sinnvoll?

inline void set_max_pan(const double &new_max);
inline void set_min_pan(const double &new_min);
inline void set_max_fov(const double &new_max);
inline void set_min_fov(const double &new_min);
inline void set_max_tilt(const double &new_max);
inline void set_min_tilt(const double &new_min);

oder bringt byRef mit integralen Typen keinerlei Vorteil?

pumuckl

padreigh schrieb:

oder bringt byRef mit integralen Typen keinerlei Vorteil?

double ist kein integraler Typ. Meinst du vielleicht eingebauter Typ?
Ob es bei double einen Vorteil brigt ist nicht einfach zu sagen, bei anderen (kleineren Typen) bringt es keinen wirklichen Vorteil.

Folgendes ist jetzt NICHT allgemeingültig, aber auf "normalen" Systemen mit "normalen" Compilern üblich:
Eine Referenz wird intern als Pointer umgesetzt, Größe 4 byte. Die werden in dei Funktion hineinkopiert, an der Stelle also keinerlei Vorteil gegenüber ints und kleinere Datentypen, höchstens gegen long long, double, float, long double (long int ist oft gleich int).
Nach dem Kopieren muss der Pointer intern dann noch dereferenziert werden, was auch wieder etwas kostet.

Allgemein ist die Faustregel, dass man eingebaute Typen per value übergibt ud nicht per const Referenz.

padreigh schrieb:

Nur der Interesse halber, das hier wäre sinnvoll?

inline void set_max_pan(const double &new_max);
inline void set_min_pan(const double &new_min);
inline void set_max_fov(const double &new_max);
inline void set_min_fov(const double &new_min);
inline void set_max_tilt(const double &new_max);
inline void set_min_tilt(const double &new_min);

oder bringt byRef mit integralen Typen keinerlei Vorteil?

Das bringt bei skalaren Typen nichts.