Je pense enfin avoir compris l'utili{sation,t=E9} de cette technique,
pourrez-vous me corriger ?
En bref : les traits r=E9pondent =E0 une probl=E9matique qui me gene
depuis un moment : l'abscence de ce que j'appelerai "m=E9taclasse" pour
la gestion des templates.
En plus d=E9taill=E9 :
Probl=E8me :
Avec les templates on ecrit souvent des trucs comme :
template <class T>
class A{
.=2E.
typedef typename T::BAR BABAR;
.=2E.
.=2E.
T a;
a=2Efoo();
.=2E.
}
Et on laisse au programeur le soin de respecter le contrat *vague*
qu'=E0 chaque fois qu'il instanciera une classe A avec une classe T il
fournira un T d=E9finissant bien un type BAR et une m=E9thode foo !
R=E9ponse, utilit=E9 et utilisation du "trait" :
Les traits on pour but de *clarifier ce contrat* en d=E9finissant une
sorte de m=E9taclasse.
En fait formellement, A ne sera plus template <class T>, mais template
<m=E9taclass mon_trait<T>>.
Concr=E8tement maintenant, on d=E9finit ("=E0 la main" s'il le faut, c'est
=E0 dire explicitement) une classe mon_trait<T> pour tous les T qu'on
souhaitera utiliser avec A, puis on continuera d'=E9crire que A est
template<class T> mais on n'utilisera que mon_trait<T> dans la
d=E9finition de A !
Enfin, ultime raffinement, on ecrira que A est template <class T,class
trait=3Dmontrait<T>> pour faire apparraitre la "m=E9taclasse" dans le type
meme de A.
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
Jean-Marc Bourguet
"meow" writes:
Je pense enfin avoir compris l'utili{sation,té} de cette technique, pourrez-vous me corriger ?
Les traits permettent d'introduire un niveau d'indirection. Tu peux t'en servir pour expliciter les contraintes mais ce n'est pas l'utilisation principale qui est de profiter de la souplesse du niveau d'indirection.
Une autre utilisation est de regrouper des parametres templates un peu comme l'utilisation d'une struct permet de regrouper des parametres d'une fonction.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"meow" <schwarz.ben@gmail.com> writes:
Je pense enfin avoir compris l'utili{sation,té} de cette technique,
pourrez-vous me corriger ?
Les traits permettent d'introduire un niveau d'indirection. Tu peux
t'en servir pour expliciter les contraintes mais ce n'est pas
l'utilisation principale qui est de profiter de la souplesse du niveau
d'indirection.
Une autre utilisation est de regrouper des parametres templates un peu
comme l'utilisation d'une struct permet de regrouper des parametres
d'une fonction.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je pense enfin avoir compris l'utili{sation,té} de cette technique, pourrez-vous me corriger ?
Les traits permettent d'introduire un niveau d'indirection. Tu peux t'en servir pour expliciter les contraintes mais ce n'est pas l'utilisation principale qui est de profiter de la souplesse du niveau d'indirection.
Une autre utilisation est de regrouper des parametres templates un peu comme l'utilisation d'une struct permet de regrouper des parametres d'une fonction.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
meow
merci pour ta réponse Marc, mais je ne la comprends pas ! :) On ne comprend généralement les problématiques que lorsqu'on y a déjà été confronté, et pour ma part Je n'ai pas énormément de pratique dans le langage ! En l'occurrence je ne comprends déjà pas l'exemple du struct pour regrouper des parametres de fonction...
merci pour ta réponse Marc, mais je ne la comprends pas ! :)
On ne comprend généralement les problématiques que lorsqu'on y a
déjà été confronté, et pour ma part Je n'ai pas énormément de
pratique dans le langage !
En l'occurrence je ne comprends déjà pas l'exemple du struct pour
regrouper des parametres de fonction...
merci pour ta réponse Marc, mais je ne la comprends pas ! :) On ne comprend généralement les problématiques que lorsqu'on y a déjà été confronté, et pour ma part Je n'ai pas énormément de pratique dans le langage ! En l'occurrence je ne comprends déjà pas l'exemple du struct pour regrouper des parametres de fonction...
kanze
meow wrote:
merci pour ta réponse Marc, mais je ne la comprends pas ! :)
C'est peut-être que tu essaies de sauter les étapes. Les traits sont une technique avancée. Peut-être pas aussi avancée que certains le prétendent, ni qu'ils semblenet au premier abord, mais il faut quand même certaines bases avant de les aborder.
On ne comprend généralement les problématiques que lorsqu'on y a déjà été confronté, et pour ma part Je n'ai pas énormément de pratique dans le langage !
Il faut donc commencer par des choses simples.
En l'occurrence je ne comprends déjà pas l'exemple du struct pour regrouper des parametres de fonction...
Par exemple...
Prenons un cas concret : un panneau de texte dans une fenêtre d'une GUI. Ce panneau a beaucoup d'attributes de customisation, genre couleur de fond, couleur de text, taille, police... En plus du texte. Ce qui ferait un constructeur avec une vingtaine de paramètres. Ce qui est un peu pénible à écrire chaque fois, surtout qu'à l'intérieur d'une application, il y a de fortes chances que beaucoup de ces paramètres seront identiques à chaque appel. On les régroupe alors dans une struct :
struct PaneAttributes { Color backgroundColor ; Color foregroundColor ; Font font ; Dimension size ; // ... } ;
En somme, je n'ai jamais à spécifier une vingtaine d'attributes.
(Une alternative qui sert souvent dans les GUI, c'est de systèmatiquement créer le panneau avec les attributes par défaut, et exiger alors que l'utilisateur appelle des fonctions sur le panneau pour changer celles où il ne veut pas le défaut. Ce qui marche aussi rélativement bien dans le cas des composants d'une GUI, mais pas toujours dans d'autres cas.)
-- 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
meow wrote:
merci pour ta réponse Marc, mais je ne la comprends pas ! :)
C'est peut-être que tu essaies de sauter les étapes. Les traits
sont une technique avancée. Peut-être pas aussi avancée que
certains le prétendent, ni qu'ils semblenet au premier abord,
mais il faut quand même certaines bases avant de les aborder.
On ne comprend généralement les problématiques que lorsqu'on y
a déjà été confronté, et pour ma part Je n'ai pas énormément
de pratique dans le langage !
Il faut donc commencer par des choses simples.
En l'occurrence je ne comprends déjà pas l'exemple du struct
pour regrouper des parametres de fonction...
Par exemple...
Prenons un cas concret : un panneau de texte dans une fenêtre
d'une GUI. Ce panneau a beaucoup d'attributes de customisation,
genre couleur de fond, couleur de text, taille, police... En
plus du texte. Ce qui ferait un constructeur avec une vingtaine
de paramètres. Ce qui est un peu pénible à écrire chaque fois,
surtout qu'à l'intérieur d'une application, il y a de fortes
chances que beaucoup de ces paramètres seront identiques à
chaque appel. On les régroupe alors dans une struct :
struct PaneAttributes
{
Color backgroundColor ;
Color foregroundColor ;
Font font ;
Dimension size ;
// ...
} ;
En somme, je n'ai jamais à spécifier une vingtaine d'attributes.
(Une alternative qui sert souvent dans les GUI, c'est de
systèmatiquement créer le panneau avec les attributes par
défaut, et exiger alors que l'utilisateur appelle des fonctions
sur le panneau pour changer celles où il ne veut pas le défaut.
Ce qui marche aussi rélativement bien dans le cas des composants
d'une GUI, mais pas toujours dans d'autres cas.)
--
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
merci pour ta réponse Marc, mais je ne la comprends pas ! :)
C'est peut-être que tu essaies de sauter les étapes. Les traits sont une technique avancée. Peut-être pas aussi avancée que certains le prétendent, ni qu'ils semblenet au premier abord, mais il faut quand même certaines bases avant de les aborder.
On ne comprend généralement les problématiques que lorsqu'on y a déjà été confronté, et pour ma part Je n'ai pas énormément de pratique dans le langage !
Il faut donc commencer par des choses simples.
En l'occurrence je ne comprends déjà pas l'exemple du struct pour regrouper des parametres de fonction...
Par exemple...
Prenons un cas concret : un panneau de texte dans une fenêtre d'une GUI. Ce panneau a beaucoup d'attributes de customisation, genre couleur de fond, couleur de text, taille, police... En plus du texte. Ce qui ferait un constructeur avec une vingtaine de paramètres. Ce qui est un peu pénible à écrire chaque fois, surtout qu'à l'intérieur d'une application, il y a de fortes chances que beaucoup de ces paramètres seront identiques à chaque appel. On les régroupe alors dans une struct :
struct PaneAttributes { Color backgroundColor ; Color foregroundColor ; Font font ; Dimension size ; // ... } ;
En somme, je n'ai jamais à spécifier une vingtaine d'attributes.
(Une alternative qui sert souvent dans les GUI, c'est de systèmatiquement créer le panneau avec les attributes par défaut, et exiger alors que l'utilisateur appelle des fonctions sur le panneau pour changer celles où il ne veut pas le défaut. Ce qui marche aussi rélativement bien dans le cas des composants d'une GUI, mais pas toujours dans d'autres cas.)
-- 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
meow
ah, comme ça, ok ! Merci Kanze. C'est vrai pourtant que c'était pourtant clair dans le précédent post... Mais comme dit, tant qu'on a pas été confronté concrètement à la question on comprend moins bien.
ah, comme ça, ok ! Merci Kanze.
C'est vrai pourtant que c'était pourtant clair dans le précédent
post... Mais comme dit, tant qu'on a pas été confronté concrètement
à la question on comprend moins bien.
ah, comme ça, ok ! Merci Kanze. C'est vrai pourtant que c'était pourtant clair dans le précédent post... Mais comme dit, tant qu'on a pas été confronté concrètement à la question on comprend moins bien.
