Templates et spécialisation.

Version imprimable

18/12/2010, 11h56
NoIdea

Templates et spécialisation.
Bonjour, j'essaie d'écrire une classe Matrix, et, je n'arrive pas à la spécialiser comme je veux. Voici à quoi ressemblerait ma classe Matrix :
Code:

1 2 3 4 5 6 7 8 template<typename T, unsigned int Ligns, unsigned int Columns> class Matrix { private : T*Obj; public : /*DesChoses.*/ };
La difficulté :

J'aimerais que quand sizeof(T)*Ligns*Columns < 8*1000*100 (100ko), que Obj soit un tableau statique.
Donc déclaré ainsi : T Obj[Ligns*Columns].
Mais que quand sizeof(T)*Ligns*Columns > 8*1000*100 (100ko) j'aimerais alloué dynamiquement Obj (pour éviter de trop remplir la pile).
Donc, déclaré ainsi : T*Obj. En allouant avec new dans le constructeur.

Bien sur, l'une des solutions aurait été de spécialiser selon un booléen que l'utilisateur choisirait en true ou false :

Par Exemple :

Matrix<float, 4,4,true>//On alloue sur la pile.
Matrix<double, 1000,100,false>//On alloue sur le tas

Sauf que je veux que l'utilisateur ne rentre pas le true/false tout en lui laissant l'option de le faire (si il veut vraiment alloué un mégaoctet sur le pile, il peut l'obliger).

Il serait donc utilisé ainsi :

Matrix<float, 4,4>//On alloue sur la pile.
Matrix<double, 1000,100>//On alloue sur le tas.
Matrix<float, 4,4,false>//On alloue sur le tas.
Matrix<double, 1000,100,true>//On alloue sur la pile.

Comment donc spécialiser ma classe ? Ou mettre mes templates par défauts ?
Pensez vous que c'est une bonne idée de proposer pile/tas ? La limite de 100ko par défaut est-elle bonne ?

Merci.

J'ai trouvé. Il me fallait créer une autre structure et faire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
template<typename T, unsigned int Ligns, unsigned int Columns, bool size>
struct Politique
{
    typedef T* type;
};
 
template<typename T, unsigned int Ligns, unsigned int Columns>
struct Politique<T,Ligns,Columns,true>
{
    typedef T type[Ligns*Columns];
};
 
template<typename T, unsigned int Ligns, unsigned int Columns, bool policy=(sizeof(T)*Ligns*Columns<8*100*1000)>
class Matrix
{
    private :
        typename Politique<T,Ligns,Columns,policy>::type Obj;
}

18/12/2010, 13h18
koala01

Salut,

A vrai dire, je ne suis pas forcément persuadé qu'il soit particulièrement intéressant de faire ce genre de distinction... Tu serais tout aussi bien d'utiliser directement l'allocation dynamique, quelle que soit la taille finale du tableau.

De plus, je me méfie énormément des règles arbitraires, car on peut toujours décider de les remettre en compte: pourquoi 100 k et non 1000 ou 10 :question:

Certaines implémentation de la STL permettent, il est vrai, de faire quelque chose du genre en créant un tableau statique lorsque la taille de la chaine n'est pas supérieure à la taille d'un registre (typiquement 32 ou 64 bits), mais ce genre de limite est plus facilement défendable ;)
18/12/2010, 13h37
Joel F

Sur certain systèmes, c'est intéressant de faire ce distingo. Par contre, il serait de meilleur aloi de fournir une politique qui permette de spécifier la règle plutot que d'avoir une limite arbitraire.
18/12/2010, 20h59
3DArchi

Salut,
Présentation des classes de Traits et de Politiques en C++ par Alp Mestan
A consulter sans modération ;)
18/12/2010, 21h32
Alp

@NoIdea: tu noteras que le dernier exemple de traits dans l'article donné par 3DArchi utilise quelque chose de très similaire à ce que tu fais, et qu'utiliser une petite structure utilitaire comme c'est fait dans l'article est assez commun, surtout quand les conditions de spécialisations ne sont pas tout à fait triviales.
19/12/2010, 13h39
NoIdea

Merci. Pour ces précisions, j'avais déjà lu l'article mais j'ai du l'oublier en grande partie. Le relire ne me fera pas de mal.

Juste quelques questions :

-La limite de 100ko est celle par défaut, bien sur, l'utilisateur peut spécifier si il veut allouer sur la pile/tas. Que pensez vous de cette limite par défaut ?

-Les petites structures, on les met dans un espaces de nom anonyme habituellement ?

-Pour des soucis de performances, j'ai créer une structure qui m'indique si le type est un type de base (pointeur/int/float/...). Ainsi, le me contente d'un memcpy pour copier la matrice. Est-ce chose courante ? Peut-on demander au compilateur si le contructeur du template est trivial ? (comme sa sa marcherait même pour des structures C).
19/12/2010, 14h06
Joel F

Citation:

Envoyé par NoIdea

-La limite de 100ko est celle par défaut, bien sur, l'utilisateur peut spécifier si il veut allouer sur la pile/tas. Que pensez vous de cette limite par défaut ?

Qu'elle est arbitraire et donc incorrecte. Laisse le sgens fixer la limite séparant le static du dynamique.

Citation:

Envoyé par NoIdea

-Les petites structures, on les met dans un espaces de nom anonyme habituellement ?

Non

Citation:

Envoyé par NoIdea

-Pour des soucis de performances, j'ai créer une structure qui m'indique si le type est un type de base (pointeur/int/float/...). Ainsi, le me contente d'un memcpy pour copier la matrice. Est-ce chose courante ? Peut-on demander au compilateur si le contructeur du template est trivial ? (comme sa sa marcherait même pour des structures C).

boost::has_trivial_constructor
Note bien que utiliser std::copy fait deja ce genre d'optimisation.
19/12/2010, 14h39
NoIdea

Citation:

Qu'elle est arbitraire et donc incorrecte. Laisse le sgens fixer la limite séparant le static du dynamique.

Donc pas de par défaut du tout ?
Je dois obliger l'utilisateur à choisir ?

Citation:

Non

Je les laisse visibles et en train de polluer l'espace de nom globale ? je les met dans un espace de nom Implementation ?

Citation:

boost::has_trivial_constructor

Après avoir lu la doc de boost, il ne font pas plus : il s'assure juste que le type est un type de base ou non. Après, il indique à l'utilisateur que si le compilateur propose une option pour le faire, alors il faut changer une macro.
En plus, je n'ai pas particulièrement envie de dépendre de boost pour une classe matrice.

Citation:

Note bien que utiliser std::copy fait deja ce genre d'optimisation.

Intéressant. Cependant, en regardant encore une fois boost, il disaient que avec memcpy, c'était plus rapide.
19/12/2010, 17h42
3DArchi

Salut,
Pour un memcpy, ce serait boost::is_pod (ou std::is_pod en C++0x).
19/12/2010, 20h58
Joel F

Citation:

Envoyé par 3DArchi

Salut,
Pour un memcpy, ce serait boost::is_pod (ou std::is_pod en C++0x).

sur certains compolateur, is_pod retourne toujours faux :/
19/12/2010, 23h10
3DArchi

Citation:

Envoyé par Joel F

sur certains compolateur, is_pod retourne toujours faux :/

:koi:
L'intrinseque __is_pod de visual retourne faux apparemment pour les types primitifs, mais std::is_pod<int>::value vaut bien vrai avec visual 10
Et je serais très tenté de répondre, change de compilo :roll:
20/12/2010, 09h08
Joel F

Citation:

Envoyé par 3DArchi

:koi:
L'intrinseque __is_pod de visual retourne faux apparemment pour les types primitifs, mais std::is_pod<int>::value vaut bien vrai avec visual 10
Et je serais très tenté de répondre, change de compilo :roll:

Je pensais plus a des trucs genre XLC ou SunCC.
La triade gcc/msvc/icc fonctionne correctement.