Bonjour à tous,

J'ai une classe possédant deux accesseurs :

// number.hpp

class Number {
    unsigned short precision_{};
    
public:
    unsigned short& precision();
    unsigned short precision() const;
};

Ils sont définis dans number.cpp :

inline unsigned short& math::Number::precision() {
	return precision_;
}

inline unsigned short math::Number::precision() const {
	return precision_;
}

J'ai aussi deux fichiers de test :

// unit_tests.hpp

#include "number.hpp"

namespace tests::number {
    void test();
}

// unit_tests.cpp

#include "unit_tests.hpp"
#include <cassert>

void tests::number::test() {
    using math::Number;

	{
		assert(Number("44").precision() == 0 && "false precision_ ");
		assert(Number(-14e+2, 7).precision() == 7 && "false precision_");
		auto a{ Number(44e-1, 85) };
		auto b{ a };	// checks the copy-constructor
		assert(b.precision() == 85 && "false precision_");
	}
}

Si j'appelle tests::number::test() dans le main, j'ai cette erreur

LNK2019	unresolved external symbol "public: unsigned short & __thiscall math::Number::precision(void)" (?precision@Number@math@@QAEAAGXZ) referenced in function "void __cdecl tests::number::test(void)" (?test@number@tests@@YAXXZ)	MathLib	E:\C++\Projets\MathLib\unit_tests.obj	1	

Je crois savoir qu'un unresolved eternal symbol signifie que le compilateur a trouvé la déclaration, mais pas l'implémentation / initialisation d'une variable ou d'une fonction.

Si je réunis ça en un seul fichier, ça s'exécute parfaitement.

Comment puis-je m'y prendre pour résoudre ce problème ?

Merci d'avance.

EDIT : j'ai remarqué dans l'erreur que les conventions d'appel (j'ai regardé ici, ça a l'air d'être des trucs pour le compilo en assembleur) sont différentes (__thiscall / __cdecl), j'ai donc essayé d'ajouter __cdecl à la signature de la fonction incriminée (prototype + implémentation), mais le message d'erreur est le même (sauf que __thiscall est remplacé par __cdecl).

-
Edité par Chi_Iroh 13 avril 2021 à 15:49:22

"number.cpp" fait-il partie des source à compiler ?

Oui, si je commente la partie qui pose problème, je peux utiliser les fonctions définies dans ce fichier sans problème de linkage.

C'est pas la question.

"number.cpp" fait-il partie des source à compiler ? (BIS)

Donnez-nous votre IDE si vous voulez qu'on soit plus précis.

Ca ressemble à un .cpp qui n'est pas compilé.

Sous code::block (je n'aime décidément pas cet IDE), assure toi que tous les fichiers fassent partie du projet.

@bacelar excusez-moi, je pensais que ça suffisait pour répondre, du coup j'ai vérifié dans les paramètres du fichier avec VS et il est bien inclus dans la compilation

Pareil du coup @Deedolith

>"les paramètres du fichier"

???

Les propriétés du fichier vous voulez dire ?

Ces réglages suivant sont-ils respectés :

- Sur la ligne "Contenu" : False

- Sur la ligne "Inclus dans le projet" : "True"

- Sur la ligne "Type de fichier" : "Code C/C++"

Excusez l'imprécision, voici un screen de VS :

Les traces de la compilation, SVP.

(bizarre, chez moi, ces champs sont vides et c'est la "vue des propriétés" (raccourci F4) qui affichent des propriétés légèrement différentes.)

Il manque le supposé namespace math dans number.hpp, mais bon je suppose qu'il y est dans le fichier originel. Non la raison probable vient des inline dans le fichier number.cpp

@Spaceln c'était bien le inline qui posait problème, je l'ai enlevé et ça linke correctement.

Après de nouvelles recherches, ce lien indique que les implémentations inline doivent être dans le header (c'est vrai qu'en fin de compte c'est logique puisque l'éditeur de liens remplace l'appel par leur corps).

Merci pour votre aide (j'aurais du faire davantage de recherches avant de poster, veuillez m'excuser)

et bonne continutation.

C'est étrange que le compilateur vous est suivi dans cet inline "sauvage" dans un .cpp (inline n'est qu'indicatif) et encore plus qu'il n'ait pas sorti au moins un warning.

Pourtant j'ai mis le niveau d'avertissement a 4, je ne mets pas tous, car du coup j'ai des centaines de warnings dans les headers C

Vous devriez essayer de garder le niveau de warning au maximum, quit à faire des #pragma push/pop autour des #include de headers C. (headers que vous devriez éviter quand c'est possible)

Bien entendu, je ne m'en sers pas au sens C (math.h), mais certaines fois (cmath, cassert voire une fois ou deux cctype mais c'est tout).

Je suis allé faire un tour sur la doc de Microsoft, et d'après ce que j'ai compris, on peut appliquer un certain niveau d'avertissement pour une partie de code donnée, selon SO :

#pragma warning(push, 0)
// niveau de warnings à 0
#include <headerWithWarnings>
// warnings non émis
#pragma warning(pop)
// niveau de warnings remis à la valeur des paramètres