Discussion :

[jwar0]

Bonjour,

J'ai un soucis avec un projet perso pour lequel j'ai décidé de séparer certains élément.
La partie math + geométrie faisant partie d'une library static ou j'ai créé un namespace(mathStd)
Mon problème est que les autres projet/library n'ont pas de visibilité sur ce namespace. J'ai l'erreur suivante Symbol 'mathStd' could not be resolved
Sans le namespace plus de problème.

J'utilise Eclipse CDT.

Des extraits de source

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
namespace mathStd
{
	class Vec2 {
	private:
		double x, y;
	public:
 
		Vec2();
 
		virtual ~Vec2();
 
		Vec2(double x, double y);
 
		Vec2(Vec2 const &vec);
 
		Vec2 operator-() const;
		Vec2 operator+(Vec2 const &vec) const;
		Vec2 &operator+=(Vec2 const &vec);
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
using namespace mathStd;
 
Vec2::Vec2() : x(0),y(0){}
 
Vec2::~Vec2() {}
 
Vec2::Vec2(double x, double y) : x(x),y(y) {}
 
Vec2::Vec2(Vec2 const &vec){
	x = vec.x;
	y = vec.y;
}
 
/*********** operators ***********/
Vec2 Vec2::operator-() const{
	return {-x, -y};
}
Vec2 Vec2::operator+(Vec2 const &vec) const{
	return {x + vec.x, y + vec.y};
}
Vec2 &Vec2::operator+=(Vec2 const &vec){
	x += vec.x;
	y += vec.y;
	return *this;
}
...

[bacelar]

Vous n'avez pas bien compris "using namespace xxx;"
Cela ne fait qu'injectez dans contenu du namespace xxx dans le namespace "sans nom".
Ici, vous voulez définir des fonctions dans un namespace bien précis.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
namespace mathStd
{
        Vec2::Vec2() : x(0),y(0){}
 
        Vec2::~Vec2() {}
 
        Vec2::Vec2(double x, double y) : x(x),y(y) {}
 
        Vec2::Vec2(Vec2 const &vec){
        	x = vec.x;
        	y = vec.y;
        }
 
        /*********** operators ***********/
        Vec2 Vec2::operator-() const{
        	return {-x, -y};
        }
        Vec2 Vec2::operator+(Vec2 const &vec) const{
        	return {x + vec.x, y + vec.y};
        }
        Vec2 &Vec2::operator+=(Vec2 const &vec){
        	x += vec.x;
        	y += vec.y;
        	return *this;
        }
        ...
}

[jwar0]

Les 2 syntaxes donne le même résultat et la compilation de la library se passe bien.
D'ailleurs j'ai trouvé les 2 types d'implémentation en exemple sur le net, j'ai opté pour la plus simple pour une première version, mais j'ai testé la version proposé.

Le problème dans le projet qui importe la library persiste, aucune visibilité du namespace dans les 2 cas.

[Bousk]

C'est quoi l'erreur ? Le mesage exact et non "ça marche pas".
Tu inclues le header qui définies Vec2 et peux l'utiliser avec mathStd::Vec2.

[jwar0]

L'erreur est en gras dans le premier message, lorsque je veux utiliser le namespace dans un projet qui utilise cette library, avec using namespace mathStd ou mathStd::Vec2

[bacelar]

Bon, montre ton code.
Celui de "mathStd::Vec2" ET celui qui s'en sert.

Tu ne sais tellement pas ce que tu fais que t'es pas foutu de nous donner les extrait de code pertinents, alors donne nous tout ce code.

[jwar0]

Apparemment Eclipse était un peu a la masse, après quelques "freshen all files" pour les index, le namespace est reconnu dans le projet qui utilise la library.
C'est pas la première fois que je lutte sur cette IDE.

Le but était de pouvoir switcher entre la version "basique" et la version SSE/AVX dans 2 libs distinct.

Merci.

[bacelar]

Ok, peut-être une utilisation un peu cavalière des pre-compiled header ?
https://warwick.ac.uk/fac/sci/system.../pchineclipse/

Le but était de pouvoir switcher entre la version "basique" et la version SSE/AVX dans 2 libs distinct.

Ne serait-il pas plus pertinent d'utiliser une constante de compilation pour changer de librairie ?

Je vois mal comment l'usage de plusieurs namespace permet de gérer plusieurs implémentations.

[jwar0]

Au départ je voulais isoler le code pour tout ce qui est vecteurs, matrices, géométrie et tout ce qui est calcul lié (notament les collisions qui peuvent être lourde) dans des librairies séparée(en gardant les même nom de classes)
Comme je ne suis pas familié avec les namespace j'ai tenté quelques chose. A vrai dire je ne sais pas ce qui est le plus adapté.

[koala01]

Salut,

Je verrais bien un moyen, mais il me paraît "relativement crade" :

On commencerait par une compilation conditionnelle proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#if defined(USE_SSX)
#define LIBNAMESPACE ssx_namespace
#else
#define LIBNAMESPACE mathStd
#endif

(ou ssx_namespace correspondrait à l'espace de nom utilisé par la bibliothèque qui utilise ssx/avx)
et, partout où l'on a besoin d'une fonctionnalité de la bibliothèque, nous aurions quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#if defined(USE_SSX)
#include <Header.h>
#else 
#include <MyLibHeader.hpp>
#endif
void foo(){
    LIBNAMESPACE::Vec2 myVector;
    /* ... *
}

Ensuite, dans la configuration du projet (par exemple, avec CMake) nous pourrions avoir quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
option(USE_SSX_AVX "should we use SSX/AVX capabilities?" TRUE)
if(USE_SSX_AVX)
    # tout ce qui permettra de trouver la bibliothèque SSX :
    find_package(nom_du_package_lib_ssx)
    if(nom_du_package_lib_ssx_FOUND)
        add_target_definitions(MyTarger USE_SSX)
        target_link_libraries(MyTarget lib_ssx)
    else()
        message(FATAL_ERROR "No lib ssx found")
    endif()
else()
    # tout ce qui permettra d'utiliser ta bibliothèque perso
endif()

Si je trouve cela "relativement crade", c'est parce que cela t'oblige à

• sélectionner les fichiers d'en-têtes en fonction du symbole USE_SSX (selon mon exemple) à chaque fois
• utiliser exactement le même schéma (noms de classes, de fonctions et autres) pour ta bibliothèque perso que pour la bibliothèque qui utilise SSX

Une autre solution -- sans doute bien meilleure -- serait d'utiliser le pimple idiom:

Tu organise ton projet selon une arborescence proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
root directory
|    - include           // contient les fichiers indépendants de la bibliothèque (en-tête)
|     |    - with_ssx  // contient les fichiers utilisant de SSX              (en-tête)
|     |    - no_ssx    // contient les fichiers utilisant ta bibliothèque    (en-tête)
|    - src               // contient les fichiers indépendants de la bibliothèque (implémentation)
|     |    - with_ssx // contient les fichiers utilisant de SSX          (implémentation)
|     |    - no_ssx   // contient les fichiers utilisant ta bibliothèque   (implémentation)

les dossiers include et src (mais pas les sous dossiers) contiennent "tout ce qui utilise le pimple idiom", par exemple:
un fichier d'en-tête MyClass.hpp ressemblant à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <TrucPimple.hpp>
MyClass{
    MyClass();
    /* tous les services utiles */
    void foo();
private:
    std::unique_ptr<TrucPimple> pimple;
};

et le fichier d'implémentation MyClass.cpp ressemblant à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <MyClass.cpp>
MyClass::MyClass():pimple_{std::move(std::make_unique<TrucPimple>())}{
}
void MyClass::foo(){
     pimple.get()->foo();
}

et, dans les sous dossier include/with_ssx (respectivement include/no_ssx) et src/with_ssx (respectivement src/no_ssx), tu crées des classes (portant le même nom, dans le même espace de noms, offrant les mêmes services) qui pourront servir de "facade" à l'utilisation des bibliothèques, par exemple:
include/with_ssx/TrucPimple.hpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#include <ssx.hpp>
class TrucPimple{
public:
    void foo();
private:
    /* tout ce qui est spécifique à l'utilisation de la bibliothèque SSX */
};

src/with_ssx/TrucPimple.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#include <TrucPimple.hpp>
void TrucPimple::foo(){
    /* on utilise la bibliothèque SSX ici */
}

include/no_ssx/TrucPimple.hpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#include <mylib.hpp>
class TrucPimple{
public:
    void foo();
private:
    /* tout ce qui est spécifique à l'utilisation de la bibliothèque perso */
};

src/no_ssx/TrucPimple.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#include <TrucPimple.hpp>
void TrucPimple::foo(){
    /* on utilise la bibliothèque perso ici */
}

Ce qui te permettrait, au niveau de CMake, d'avoir quelque chose qui ressemblerait à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
option(USE_SSX_AVX "should we use SSX/AVX capabilities?" TRUE)
if(USE_SSX_AVX)
    # tout ce qui permettra de trouver la bibliothèque SSX ...
    set(SPECIFICS with_ssx)
    set(LIB_DEP nom_bibliothèque_SSX)
else()
    # tout ce qui permettra d'utiliser ta bibliothèque perso ...
    set(SPECIFICS no_ssx)
    set(LIB_DEP nom_bibliothèque_perso)
endif()
# la liste des fichiers d'en-tête 
set(HEADERS include/MyClass.hpp
            include/${SPECIFICS}/TrucPimple.hpp
            #les autres fichiers d'en-tête ...
)
set(SRCS src/MyClass.cpp
         src/{SPECIFICS}/TrucPimple.cpp
         #les autres fichiers d'implémentation ...
)
add_executable(MyApp ${SRCS} ${HEADERS})
target_include_directories(MyApp ${CMAKE_CURRENT_SRC_DIR}/include/${SPECIFICS})
target_link_libraries(MyApp ${LIBD_DEP})

Tout cela permettra à CMake de choisir les bons fichiers d'en-tête en fonction de la valeur de l'option USE_SSX, et, à toi, de choisir d'utiliser (ou non) SSX simplement en cochant / décochant l'option dans cmake-gui (ou en transmettant -DUSE_SSX=TRUE | FALSE en invoquant CMake)

Ce sera "moins crade" que la première solution que j'ai donnée, et cela t'autorisera "plus de souplesse" lorsque tu développera ta propre bibliothèque (tu ne sera pas obligé de respecter exactement le même schéma que la bibliothèque SSX en ce qui concerne les noms), mais ce sera "plus de travail".

Sauf que, si mes souvenirs sont bon, eclipse CDT utilise toujours les auto-tools (autoconf, autoheader, automake, ...).

Personnellement, je n'aime pas trop utiliser eclipse pour le développement en C++: cela me semble être un comble d'utiliser un outil qui nécessite java pour ce genre de taf. Mais bon, chacun voit midi à sa porte sur ce coup là

Tu devrais pouvoir arriver à un résultat très similaire avec les autotools, mais il faudra que tu adaptes le code que je présente pour CMake, car, si je connaît les autotools, cela fait un peu trop longtemps que je ne les ai plus utilisés (et, surtout, j'ai la flegme d'adapter mon code moi-même )

[jwar0]

Salut Koala,

Je sais pas si ta solution est crade mais elle à l'air compliqué, je vais lire ça tranquillement d'ailleurs je ne sais pas si CMake est dispo avec Eclipse ou alors c'est un outil genre ant ?

Pour le choix d'Eclipse, il est simple, je suis dev JEE(informatique de gestion) et dev JSE sur des projet perso avec cet IDE.
J'ai tenté CodeBlock mais j'ai vite trouvé que j'étais limité, peut être parce que je ne trouvais pas les automatisme que j'ai acquis avec Eclipse et que j'ai pas pris le temps.
Dans un autre domaine, j'ai eu le même problème avec photoshop, usine a gaz capable de tout ou presque, mais avec un tas d'alternative lorsqu'il s'agit d'une tache bien particulière.

[koala01]

Salut Koala,

Je sais pas si ta solution est crade mais elle à l'air compliqué,

Ben, tu sais, à partir du moment où tu veux jongler avec plusieurs bibliothèques qui fournissent à peu près les mêmes fonctionnalités, et choisir l'une des deux, toutes les solutions seront forcément "plus compliquées" que si tu ne voulait utiliser qu'une seule bibliothèque

d'ailleurs je ne sais pas si CMake est dispo avec Eclipse ou alors c'est un outil genre ant ?

CMake est un outil de configuration de projet, dans le genre de la suite des autotools.



Pour faire simple, tu décris ton projet, les fichiers et les dossiers qui le composent, les dépendances vis-à-vis des bibliothèques tierces qu'il utilise, les différentes options de compilation à prendre en compte, etc, et l'outil se charge de créer le Makefile qui permettra de générer l'exécutable.

L'énorme avantage de CMake, par rapport au autotools, c'est qu'il est tout à fait portable, et qu'il est donc disponible pour tous les systèmes "classiques" (windows, linux, MacOS), alors que les autotools sont ... embêtants à utiliser sous windows.

De plus, mais ce n'est qu'un avis strictement personnel, je trouve la syntaxe des fichiers à créer beaucoup plus simple d'utilisation

A priori, il est possible d'intégrer CMake à ant

Pour le choix d'Eclipse, il est simple, je suis dev JEE(informatique de gestion) et dev JSE sur des projet perso avec cet IDE.

Oh, tu sais, le choix d'un IDE n'est jamais qu'une question de gout

J'ai tenté CodeBlock mais j'ai vite trouvé que j'étais limité, peut être parce que je ne trouvais pas les automatisme que j'ai acquis avec Eclipse et que j'ai pas pris le temps.

C'est possible

Et puis, les gouts et les couleurs... Ca ne se discute pas

J'hésite à te proposer d'essayer QtCreator ou VisualStudio; tous les deux permettent l'utilisation de CMake, le premier étant disponibles sur la plupart des systèmes "classiques", le second n'étant disponible que sous windows.

Mais si tu préfères éclipse, c'est ton choix, et je n'ai pas à le remettre en cause

Ceci dit, il est aussi très facile de s'en passer, surtout lorsqu'on utilise les autotools ou CMake :

"Tout ce qu'il faut", c'est un éditeur de textes plats susceptible de fournir la coloration syntaxique adaptée au langage (et, le cas échéant, susceptible d'être "automatisé") et une bonne console de "ligne de commande".