Discussion :

[ahoff]

Bonjour,

Je travaille avec fftw, dont le type complexe n'est autre qu'un tableau de deux éléments. Le problème est que j'ai créé une classe matrice templaté (oui parce que je manipule aussi des doubles etc.), la définition de cette classe est grosso modo la suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
template<typename T>
class Matrix
{
public:
....
   T operator() (uint i, uint j) const; // lecture
   T& operator() (uint i, uint j); // écriture
...
};

Le problème c'est que si T = fftw_complex = double[2], les opérateurs renvoient un tableau et le compilateur considère ça comme une erreur (on ne peut pas vraiment luit en vouloir en même temps...). Du coup pour contourner le problème, je me demandais s'il était possible de faire un truc genre :

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
 
template<typename T>
class Matrix
{
public:
....
    template_if<T == fttw_complex>
    {
        std::complex<double> operator() (uint i, uint j) const; // lecture
        std::complex<double>& operator() (uint i, uint j); // écriture
    }
    template_else
    {
        T operator() (uint i, uint j) const; // lecture
        T& operator() (uint i, uint j); // écriture
    }
...
};

Merci d'avance.

[Ehonn]

Bonjour

Le plus simple est de virer les tableaux en les remplaçant par une structure plus adéquate (comme le std::complex que tu as écris).

Sinon, tu peux faire de la spécialisation de classe.
FAQ C++ - Qu'est-ce que la spécialisation de template ?

PS:
Selon l'utilisation, tu peux peut être vouloir éviter la copie lors des accès en lecture (?)

Code :

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

T const & operator() (uint i, uint j) const;

Les std::size_t sont peut être préférables au uint (?)

[ahoff]

Merci pour ta réponse !

Le plus simple est de virer les tableaux en les remplaçant par une structure plus adéquate (comme le std::complex que tu as écris).

Effectivement c'est le plus simple et le plus propre (je comprends même pas pourquoi ils utilisent des tableaux), mais un truc qui me motive à garder les tableaux, c'est que ma matrice utilise le même format de stockage que les "tableaux multis-dim" de fftw, du coup mettons que j'ai une méthode :

Code :

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

T* maMatrice<T>::ptr() {return this->mat_core;}

je peux faire directement :

Code :

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

1
2
3
 
maMatrice<fftw_complex> m(...);
 p = fftw_plan_dft_1d(N, m.ptr(), m.ptr(), FFTW_FORWARD, FFTW_ESTIMATE);

sans passer par une étape de conversion (je suis short niveau mémoire), si tu connais un truc qui permet de faire la conversion sans recréer un tableau, je suis preneur !

Sinon, tu peux faire de la spécialisation de classe.
FAQ C++ - Qu'est-ce que la spécialisation de template ?

Ouais, j'y avais pensé, le problème c'est qu'il faut que je change le type de retour de certaines méthodes, du coup j'ai opté pour un :

Code :

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

1
2
3
4
5
6
 
typedef typename std::conditional<std::is_same<fftw_complex,T>::value, const double*, T>::type return_val;	
typedef typename std::conditional<std::is_same<fftw_complex,T>::value, double*, T&>::type return_ref;
...
return_val operator() (uint i, uint j) const;
return_ref operator() (uint i, uint j);

je trouve cette solution un peu crade mais elle me convient pour le moment.

PS:
Selon l'utilisation, tu peux peut être vouloir éviter la copie lors des accès en lecture (?)

Code :

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

T const & operator() (uint i, uint j) const;

Les std::size_t sont peut être préférables au uint (?)

Ha ok, je connaissais pas ces pratiques de programmation merci !

[koala01]

Salut,

En fait, il existe à ce jour trois possibilités distinctes: la première, la deuxième et la troisième... Euhhh, pardon:

1. La simple, mais laborieuse (parce qu'elle implique de se répéter pour toute la classe matrix), qui consiste à créer une spécialisation de matrix
2. La pensée "à la david Wheller" qui consiste à créer un trait qui sera spécialisé
3. La possibilité, si on dispose de C++11, de jouer avec des traits comme enable_if et is_same.

Je ne suis pas particulièrement fan de la première solution, parce qu'elle implique de copier l'intégralité du code de matrix dans la spécialisation pour fftw_complex, ce qui fait beaucoup de boulot pour, finalement, un très petit point de variation.

La pensée à la david Wheller consiste à se dire que

all problems in computer science can be solved by another level of indirection
(Tout problème en informatique peut être résolu par un autre niveau d'indirection)

et que, si tu veux "simplement" ajouter un point de variation pour un type bien particulier, il t'est toujours possible de créer un petit quelque chose de minimal qui permette cette variation.

Ainsi, nous pourrions très bien envisager une structure template proche de

Code :

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

1
2
3
4
5
6
template <typename Type>
struct MatrixTrait{
    /* à l'ancienne mode */
    typedef Type & ref_type;
    typedef Type const & const_ref_type;
};

que nous spécialisons pour fftw_complex sous une forme proche de

Code :

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

1
2
3
4
5
6
template <>
struct MatrixTrait <fftw_complex>{
    /* à l'ancienne mode */
    typedef fftw_complex & ref_type;
    typedef fftw_complex const & const_ref_type;
};

une fois que c'est fait, il nous devient "facile" d'utiliser ce trait à l'intérieur de notre matrice, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
template<typename T>
class Matrix
{
public:
    typedef MatrixTrait<T> type_traits;
    typedef typename type_traits::ref_type ref_type;
    typedef typename type_traits::const_ref_type const_ref_type;
    const_ref_type operator() (uint i, uint j) const; // lecture
    ref_type operator() (uint i, uint j); // écriture
    /* ... */
};

La dernière possibilité nécessite de disposer d'un compilateur récent car elle implique d'utiliser des fonctionnalités (en fait des traits) qui ne sont présent dans la STL que depuis la norme C++11, et donc peut etre de compléter les options de compilation avec une option fort proche de -std=c++11 (syntaxe Gcc, à adapter à ton compilateur).

Il est en effet possible de laisser le choix au compilateur d'activer (ou non) une fonctionnalité avec std::enable_if et quelques traits particuliers comme is_same.

Cela prendrait une forme (non testée!!!) proche de

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
template<typename T>
class Matrix
{
public:
....
    // finalement, on est tout proche de ce que tu voulais faire à la base :D
   // on active les deux version pour le cas ou l'on a affaire à un fftw_complex
        std::enable_if<std::is_same<T,fftw_complex>::value, T>::type
         operator() (uint i, uint j) const; // lecture
        std::enable_if<std::is_same<T,fftw_complex>::value, T>::type &
         operator() (uint i, uint j); // écriture
 
   // et pour tout ce qui n'est pas un fftw_complex
        std::enable_if<!std::is_same<T,fftw_complex>::value, T>::type
         operator() (uint i, uint j) const; // lecture
        std::enable_if<!std::is_same<T,fftw_complex>::value, T>::type &
         operator() (uint i, uint j); // écriture
...
};

Je ne suis pas loin de penser que cette troisième solution est certes très sympa, mais qu'elle présente un problème majeur: tu devras systématiquement fournir une version de chaque fonction prenant un T en argument spécifique pour fftw_complex et une pour "les autre types".

De mon avis (strictement personnel !!!), la création d'un trait spécifique me semble être la meilleure approche

[ahoff]

Merci, du coup j'ai opté pour la deuxième solution.