Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Conditions sur des paramètres templates

Conditions sur des paramètres templates

16 réponses
Avatar
Yohan
Bonjour,

J'ai une question concernant les paramètres des classes templates.
Est-ce possible de déclarer une condition à remplir pour qu'un template
soit instancié (ou non)au moment de la compilation ?
(et donc que cette condition non remplie enverrait une erreur au
compilateur par exemple)
Et est-ce possible d'utiliser le même type de condition pour choisir
quel méthode le compilateur devra compiler.

L'exemple suivant illustre ma première question:
la condition serait "la variable nb est supérieure à 1"


template < class T, int nb >
class Foo
{
private:

T _tab[nb];

public:

Foo(T[nb]);

...

}


typedef Foo<float,2> Coord; // cette ligne doit pouvoir compiler

typedef Foo<int,3> Example; // cette ligne aussi

typedef Foo<float,0> Another; // mais j'aimerai que cette ligne
envoieune erreur au compilo


// Cet exemple concernait ma première question
Ma deuxième question concerne une condition qui permettrait au
compilateur de necompiler que certaines méthodes.
Le choix se fesant à la compilation...

Par exemple, le cas d'un nombre de paramètre variable avant comilation,
mais fixe après comilation:
Ce qui suit illustre la question:

template < class T, int nb >
class Foo2
{
private:

T _tab[nb];

public:

#if( nb==1 )
Foo(T t1);

#else if (nb==2)
Foo(T t1, T t2);

#else if....

...

}


// bien sur, la syntaxe est fausse, car le précompilateur ne connait pas
lavariable nb.
Donc mon idée aurait été de trouver une forme de condition sur les
variables template, évaluée au moment de la compilation.

Si vous avez uneidée, elle pourrait m'être très précieuse !

Merci


Yohan
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
James Kanze
Fabien LE LEZ wrote:
On Sat, 25 Feb 2006 15:49:11 +0100, James Kanze :


j'ai un macro du nom « linux » (qui m'ennuie pas mal, parce
que j'ai un répertoire avec les en-têtes qui s'appelle linux,
et « #include "gb/syst/linux/xxx.hh" » ne marche pas très
bien quand tu remplaces linux avec 1).



Comment t'en sors-tu dans ce cas ? Tu renommes le répertoire
en "Linux" ?


Pour l'instant, je compile avec -std=c++98. C-à-d que je démande
au compilateur de se comporter de façon conforme à la norme. Ce
qu'il fait.

Mais je reflechis sur une solution plus adéquate. Parce que
j'imagine que s'ils définissent linux par défaut, il y a bien
une raison. Et qu'il se peut qu'il y a des logiciels tiers qui
s'y compte.

En fait, les noms des répertoires ici suivent une convention que
j'ai établi il y a très longtemps, sous MS-DOS. J'ai donc une
hiérarchie : dans le makefile, c'est écrit
$(arch)/$(syst)/$(comp). Avec les noms de chaque répertoire sans
majuscules, et 8 caractères au max. Or, je ne crois pas que ce
soit essentiel aujourd'hui -- c'est une reste historique. Mais
je n'ai pas encore réelement décidé avec quoi je veux le
remplacer : $(arch)-$(syst)-$(comp), peut-être, à la GNU, avec
arch-$(arch), etc. pour les cas où il n'y a dépendence que sur
un seul des éléments. Ou comme tu dis, simplement plus de
liberté dans le nommage, avec des majuscules. (C'est vrai que
c'est un changement qui ne me coûterait que quelques minutes. Et
qui serait en plus conforme à la convention que j'ai adopté
depuis dans la bibliothèque : un répertoire dont le nom commence
par une minuscule ne contient que du généré.)

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34


Avatar
James Kanze
Fabien LE LEZ wrote:
On Sat, 25 Feb 2006 15:49:11 +0100, James Kanze :

j'ai un macro du nom « linux » (qui m'ennuie pas mal,
parce que j'ai un répertoire avec les en-têtes qui s'appelle
linux, et « #include "gb/syst/linux/xxx.hh" » ne marche pas très
bien quand tu remplaces linux avec 1).


Comment t'en sors-tu dans ce cas ? Tu renommes le répertoire en
"Linux" ?




Avatar
meow
OK... Merci Kanze, dit comme ça oui, c'est évident. Vu que c'est une
doc de C++, "l'implémentation" se reporte évidemment à C++ lui meme,
et donc au compilo ! Il ne manquait donc rien dans la phrase :)
A ma décharge, je n'ai pas l'habitude de me placer dans l'optique de
celui qui code un compilo :D
Avatar
Fabien LE LEZ
On Sun, 26 Feb 2006 12:57:42 +0100, James Kanze :

Parce que
j'imagine que s'ils définissent linux par défaut, il y a bien
une raison.


Au moins, sous Windows, les compilos respectent la norme : les machins
définis sont _Windows et __WIN32__.

Au fait, si tu utilises le mot "linux" dans tes répertoires, ça veut
dire que tu fais du code compatible avec toutes les versions de Linux,
mais incompatible avec BSD par exemple ?

Avatar
kanze
Fabien LE LEZ wrote:
On Sun, 26 Feb 2006 12:57:42 +0100, James Kanze
:

Parce que j'imagine que s'ils définissent linux par défaut,
il y a bien une raison.


Au moins, sous Windows, les compilos respectent la norme : les
machins définis sont _Windows et __WIN32__.


C'est pareil sous Solaris. (C-à-d que je ne sais pas tout ce qu'ils
définissent, mais je n'ai jamais eu de problème. Et j'ai bien un
répertoire nommé « sparc » aussi.)

Au fait, si tu utilises le mot "linux" dans tes répertoires,
ça veut dire que tu fais du code compatible avec toutes les
versions de Linux, mais incompatible avec BSD par exemple ?


Peut-être:-). Ça veut dire que j'ai du code ciblé Linux. Il se
peut bien que ce code marche aussi sous BSD. Un coup d'oeil
rapid : les seuls répertoires linux sont dans les hièrarchies du
genre « i80x86/linux/gcc » ou « x86_64/linux/gcc ». Grosso modo,
trois fichiers en tous : un pour la configuration du make (qui
ne fait qu'inclure unix.mk et gcc.mk, qui définissent les
conventions de nommage pour tout Unix, et les options de
compilation pour g++), un dans Global, qui ne comporte que des
#define's, du genre sysFamily est posix (c'est assez proche pour
mes besoins), threads sont pthreads, etc., et un qui implémente
le code pour rémonter la pile -- qui peut dépendre à la fois du
système, du compilateur et de l'architecture. (En fait, sous
Unix, c'est rare qu'il dépend du compilateur -- encore que
comment faire pour trouver le début du chaînage dépend parfois
même des options de compilation.)

En gros, l'utilisateur designe l'architecture, le système et le
compilateur ; le système de build utilise ces trois données pour
trouver tout ce qui en dépend d'au moins un d'entre eux. Et je
ne crois pas avoir trouver la solution définitive -- par
exemple, j'ai encore des noms tout minuscule, avec un maximum de
huit caractères, parce que dans le temps...

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
Yohan
Bonjour à tous,

j'ai trouvé la réponse à ma question, mais j'avais
oublié de vous
transmettre la solution.

Avant tout, j'aimerai féliciter Franck Branjonneau pour sa réponse
dédaigneuse et donc peu utile. Ma question était très
claire, nul
besoin de corriger les mots comme au collège, surtout pour conclure de
coder "à la main". Bref :-)

La solution au problème est d'exploiter la propriété SFINAE
(pour
"Substitution Failure Is Not An Error") des compilateurs c++. Il
s'agit
d'une technique assez avancée à mon goût, donc je
préfère indiquer
un lien web (voir le paragraphe "SFINAE") :
http://perso.ens-lyon.fr/guillaume.melquiond/divers/cpp/template.html
Il s'agit de déclarer un type seulement si une structure
paramétrée
reçoit un booleen vrai en paramètre. Il s'agit du
"enable_if" que
l'on retrouve dans Boost.

Voila, donc merci à tous.
Yohan







Franck Branjonneau wrote:
Yohan écrivait:

J'ai une question concernant les paramètres des classes templates.
Est-ce possible de déclarer une condition à remplir pour qu'un
template soit instancié (ou non)au moment de la compilation ?



Ta question est mal posée.

Et est-ce possible d'utiliser le même type de condition pour choisir
quel méthode le compilateur devra compiler.



Cette question n'a pas de sens.

L'exemple suivant illustre ma première question:
la condition serait "la variable nb est supérieure à
1"



[ Je lis supérieure ou égale à 1 ]

template < class T, int nb >
class Foo
{
private:

T _tab[nb];



S'interdire l'usage de _ en premier caractère d'un identificateur.

public:

Foo(T[nb]);



Vraiment ?


...

}



Manque un point-virgule.

Quelque chose comme ça doit convenir :

template < class T, int nb, bool /* ensure nb >= 1 */ nb < 1 >
class Foo;

// Not defined, nb < 1 is true.
template<>
template < class T, int nb >
class Foo< T, nb, true >;


template<>
template < class T, int nb >
class Foo< T, nb, false > {

// Ok, nb >= 1.

};

typedef Foo<float,0> Another; // mais j'aimerai que cette ligne
envoieune erreur au compilo



Envoyer une erreur au compilateur ? Cette ligne provoqueras une erreur
de compilation et un diagnostic.

Ma deuxième question concerne une condition qui permettrait au
compilateur de necompiler que certaines méthodes.



Méthode ?

Le choix se fesant à la compilation...

Par exemple, le cas d'un nombre de paramètre variable avant
comilation, mais fixe après comilation:



Ce n'est pas évident. Voire du côté des tuples de boost ou
tr1
peut-être.

Ce qui suit illustre la question:

template < class T, int nb >
class Foo2
{
private:

T _tab[nb];
^


Non !

public:

#if( nb==1 )
Foo(T t1);
^


2

#else if (nb==2)
Foo(T t1, T t2);
^


2

#else if....

...

}
^


;

Si le domaine de nombre est petit ou si le nombre de fonctions
concernées est petit il est possible de le faire « à la
main ».

--
Franck Branjonneau



1 2