Discussion :

[PINGOUIN_GEANT]

Je vous expose mon problème :
Je dois utiliser une bibiothèque écrite en C et j'ai mis une interface dans un espace de noms

Code :

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

1
2
3
4
5
6
 
#include "fichier_C.h"
namespace monEspace {
typedef struct_C MyStruct;
void MyFunction(MyStruct *);
}

j'amerais savoir si je protège bien l'utilisation de monEspace::MyFunction et qu'on ne pourra pas l'appeler avec un struct_C

Autre question : il y a une constante macro dans le fichier .h REAL qui correspond soit à double soit à float et qui est utilisée dans struct_C mais elle n'est définie que dans le fichier .c (qui au passage fait 15 000 lignes )

pour pas que cela plante il y a donc un

Code :

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

#define REAL double

juste avant l'inclusion.
mais j'aimerais pouvoir l'inclure dans dans l'espace de noms. Avez-vous des solutions moins bancales ?
Je vous remercie par avance 8).

[Aurelien.Regat-Barrel]

j'amerais savoir si je protège bien l'utilisation de monEspace::MyFunction et qu'on ne pourra pas l'appeler avec un struct_C

Ben non. typedef c'est juste pour créer un alias

pour pas que cela plante il y a donc un

Code :

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

#define REAL double

juste avant l'inclusion.
mais j'aimerais pouvoir l'inclure dans dans l'espace de noms. Avez-vous des solutions moins bancales ?

Ben utilise un typedef déjà au lieu d'un #define. Après j'ai pas bien compris, peut-être veux tu faire un truc dans ce genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
namespace perso
{
    typedef double REAL;
    #include "fichier_C.h"
}
namespace monEspace
{ 
    typedef perso::struct_C MyStruct; 
    void MyFunction( MyStruct * ); 
}

[PINGOUIN_GEANT]

j'amerais savoir si je protège bien l'utilisation de monEspace::MyFunction et qu'on ne pourra pas l'appeler avec un struct_C

Ben non. typedef c'est juste pour créer un alias

je trouve cela dommage de ne pas protéger comme cela l'utilisation de MyFunction avec une obligation d'utiliser une variable de l'espace de nom. Qu'en pensez-vous ?
Car en fait le truc aurait été de pouvoir protéger de l'utilisation avec REAL = float. avec ce que j'avais déjà proposé, je ne sais pas si cela marche mais a priori le #define dans le même fichier doit pouvoir l'assurer.
Aurélien>>j'aime bien ce que tu m'as proposé, je n'ai pas eu le temps de l'adapter sans erreur à la compilation mais je le garde sous le coude quand j'aurais le temps car on doit avancer dans le projet.
Merci beaucoup.

[Aurelien.Regat-Barrel]

je trouve cela dommage de ne pas protéger comme cela l'utilisation de MyFunction avec une obligation d'utiliser une variable de l'espace de nom. Qu'en pensez-vous ?

Ben typedef ça crée pas un nouveau type, ça sert juste à définir un alias. Pour créer un nouveau type c'est struct/class. Si typedef créait un nouveau type, le code suivant produirait une erreur :

Code :

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

1
2
3
4
5
6
7
8
 
namespace toto
{
    typedef double Real;
    void Test( Real );
}
 
Test( 10.5 ); // error : could not convert double to type Real

je le garde sous le coude quand j'aurais le temps car on doit avancer dans le projet.

moi aussi j'ai plein de trucs sur ma todo list...

[PINGOUIN_GEANT]

[

Ben typedef ça crée pas un nouveau type, ça sert juste à définir un alias. Pour créer un nouveau type c'est struct/class. Si typedef créait un nouveau type, le code suivant produirait une erreur :

Code :

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

1
2
3
4
5
6
7
8
 
namespace toto
{
    typedef double Real;
    void Test( Real );
}
 
Test( 10.5 ); // error : could not convert double to type Real

justement c'est ce que je veux : Test ne peux être exécuté qu'avec des types appartenant à l'espace de noms.
on a aussi pensé à redéfinir la classe(copier/coller) et faire un transtypage quand on appelle la fonction de la bibliothèque à l'intérieur de MyFunction.

[JolyLoic]

Les "strong typedef" sont dans la liste des évolutions du C++. Mais ce n'est pas pour demain, surtout que si tout le monde est d'accord pour avoir des s"strong typedef", personne n'est d'accord pour savoir exactement ce dont il s'agit.

[Aurelien.Regat-Barrel]

J'ai moi aussi désiré un tel comportement. J'ai créé ma propre classe avec un constructeur explicit et un opérateur de conversion vers le type empaqueté. Un template dans ce genre si je me souviens bien:

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
 
template<typename T>
class TypeMaker
{
public:
    explicit TypeMaker( const T & t ) : value( t ) {}
    operator T &() { return this->value; }
    operator const T &() const { return this->value; }
    T * operator &() { return &this->value; }
    T & operator = ( const T & t ) { this->value = t; return this->value; }
 
    T value;
};
 
typedef TypeMaker<double> Real;
 
int main()
{
    Real r( 10.5 );  
    r = 10;
    double d = r;      
}

En fonction de tes exigences tu peux virer ou non le explicit.

[PINGOUIN_GEANT]

c'est intéressant ce que tu m'as donné Aurélien.
en tout cas, pour les strong typedef, je les ferais un peu comme expliqué plus haut avec une portée au niveau des espaces de noms. Une fonction de cet espace de noms avec un strong typedef comme argument serait forcément appelé avec ce type d'argument et pas avec un alias de cet argument.
clairement, cela ne marcherait pas au niveau des classes à cause des fonctions amies.
d'un autre côté je n'ai pas assez de recul et je suis trop nul en C++ pour juger de toutes les possibilités