OVH Cloud OVH Cloud

Aide pour realiser une classe de manipualtion de donnees

45 réponses
Avatar
Aurélien REGAT-BARREL
Bonjour,
Ca parrait long, mais c'est vite lu :-)

J'ai un certain nombre de classes ABC, DEF, GHI, ... qui ont la
particularité d'avoir une certain nombre (presque tout le temps 3) de
"valeurs" toutes de type double. En fait, la seule chose qui différencies
ces classes est le nom de ces valeurs :

class ABC
{
public:
double A() const { return this->a; }
double B() const { return this->b; }
double C() const { return this->c; }
private:
double a;
double b;
double c;
};

class DEF
{
public:
double D() const { return this->d; }
double E() const { return this->e; }
double F() const { return this->f; }
private:
double d;
double e;
double f;
};

etc...
C'est utile de les différencier, car ces valeurs n'ont pas la même
signification, et le typage est nécessaire.
Jusque là tout va bien, tout est calculé correctement.

Probleme :
Je veux dessiner ces valeurs dans un graphe, 1 valeur au choix sur chaque
axe.
Par exemple, dessiner A() et B() sur mon graphe.
Je voudrais donc faire un truc générique, et pas XX fonctions pour chaque
type.
J'ai voulu faire hériter toutes ces classes d'une même classe de base :
Triplet.

class Triplet
{
public:
virtual double Value( int Index ) const = 0;
};

Ainsi je file mon ABC ou DEF ou XYZ à mon graphe et je lui dit "dessine moi
la valeur 1 et 2 et il fait Value( 1 ) et Value ( 2 ) pour les récupérer.

class ABC : public Triplet
{
// idem que plus haut

public:
double Value( int Index )
{
switch ( Index )
{
case 0 : return this->A();
case 1 : return this->B();
case 2 : return this->C();
}
// exception
}
};

Mais Triplet est abstraite, et je ne peux pas contruire un
std::vector<Triplet> à passer pour dessiner.
Je compte du coup re-écrire toutes les classes dans ce style :

class Triplet
{
public:
virtual double Value( int Index ) const { return this->values.at(
Index ); }
private:
std::vector<double> values;
};

class ABC : public Triplet
{
public:
double A() const { return this->values[ 0 ]; }
double B() const { return this->values[ 1 ]; }
double C() const { return this->values[ 2 ]; }
};

Y'a-t-il une meilleure solution ?
Par exemple :

class ABC : public std::vector<double>
{
public:
double A() const { return this->at( 0 ); }
double B() const { return this->at( 1 ); }
double C() const { return this->at( 2 ); }
};

Merci de m'avoir lu.

--
Aurélien REGAT-BARREL

5 réponses

1 2 3 4 5
Avatar
drkm
Gabriel Dos Reis writes:

drkm writes:

| Gabriel Dos Reis writes:

| > On dirait que ce bouquin a ruiné les chances d'application des
| > techniques templates dans nombre d'endroit.

| Heu, je ne comprend pas bien comment. En présentant les choses de
| manière trop hermétique (ce n'est pas mon avis) ?

Je ne sais pas si c'est trop hermétique. Mais pour nombre de gens,
cela appraît comme un jeu ou un show où on roule la mécanique. :-(


Huh ? Il y aura toujours des jaloux pour traiter de frimeurs les
gens plus intelligens qu'eux. Ne supportant pas que des auteurs
étallent leur savoir dans des bouquins, ils en resteront au fleuron de
l'édition technique, Micro Application, et je ne m'en plainderai pas.

Les programmeurs que j'ai rencontrés (y compris les étudiants ici qui
ont spontanément décidé de suivre mon groupe de travail sur la
programmation générique) et qui se sont fait leurs idées sur les
templates en lisant ce bouquin pensent que

(1) les templates, c'est un jeu, bon à mettre sur son CV mais pas
plus ;

(2) c'est loin des préoccupations de programmation courante ; ils


Arf ! Pondre du code générique ou un générateur de code est loin
des préoccupations de programmation courante.

préfèrent continuer avec les macros ou les fonctions virtuelles
ou l'héritage (multiple ou non) là où cela ne s'impose pas.

(3) quelqu'un qui comprend les templates, c'est dangereux pour
leurs projets.

:-(


Pour le moins.

Mais rassure-moi, tu n'as pas été exaustif, ici. Tu as oublié la
catégorie des personnes qui ont découvert un intérêt nouveau aux
techniques templates.

évidemment, c'est un problème qui comporte une part d'éducation et
cela prend du temps.

| > Et c'est triste. :-(. Je
| > connais beaucoup de gens influents dans la communauté C++ qui pensent
| > que même si le bouquin a le mérite de collectionner en un seul endroit
| > des techniques faisant partie du folklore culturel aux alentours de
| > 1997-1999, il n'en fait pas forcément une bonne présentation
| > pédagogique

| Quelle drôle d'idée.

???


Je trouve une drôle d'idée celle-ci : « Modern C++ Design ne fait
pas une présentation pédagogique de son sujet ». Il est vrai que les
techniques employées ne sont pas toujours évidentes. Mais justement.
Tout au long du livre, je n'ai cessé de penser « Mon dieu, mais c'est
bien sûr. C'est clair et limpide. Pourquoi n'ai-je pas écrit ce
livre avant ? C'est pourtant si simple. » ;-)

| > et applicative.

| Je ne vois pas ce que tu veux dire par là. Parles-tu de la mise en
| situation des techniques décrites ? Si oui, je trouve cela étrange,
| comme idée.

Il y a de bonnes idées dans ce bouquin. Seulement, je crois des fois
l'illustration est noyée dans trop de technicités


Pour moi, ce bouquin est résolument technique. Il ne comporte pas
beaucoup de mises en situation du code développé. Mais c'est parce
que si l'implémentation est originale, les techniques employées
nouvelles pour beaucoup, les outils définis sont eux bien classiques,
ou leur problématique bien connue :

Ch. 1-3 [techniques utilisées tout au long du livre]
Ch. 4 Small-Object Allocation
Ch. 5 Generalized Functors
Ch. 6 Implementing Singletons
Ch. 7 Smart Pointers
Ch. 8 Object Factories
Ch. 9 Abstract Factories
Ch. 10 Visitor
Ch. 11 Multimethods

Bon, d'accord, pour le dernier, c'est peut-être un peu moins
évident.

(ou parfois du
marketing).


Que veux-tu dire par là ?

Je suis mal placé pour en parler plus longuement :-)


Et par là ?-)

Je me souviens qu'à l'Adobe Tehcnical Summit (organisé par Alex
Stepanov) d'Avril dernier à San Jose, mes amis et confrères Jeremy et
Jaakko ont été invités à faire une session sur la programmation
générique. L'assistance était principalement composée de programmeurs
professionnels d'Adobe ainsi que les suspects usuels (Stroustrup et
Stepanov au premier rang). Ce fut une très bonne présentation (j'étais
à la présentation de Matt Austern et Dave Abrahams qui avait lieu en
même temps, mais j'ai visionné les enregistrements le soir). À la
fin, Alex a bondi sur scène en disant « that is wrong » (c'était
plutôt affectif). Il avait vivement réagi contre la partie qui
concernait « concept checking. » Selon lui, ce sont des parties
techniques que le programmateur ne devrait pas savoir en
premier lieu -- en fait aurait jamais dû avoir à écrire ces
contorsions, mais c'est un problème sur lequel nous travaillons ;-)


Tout à fait d'accord.

Le fond de l'histoire est qu'une présentation des templates doit se
concentrer sur les problèmes communs et suggérer des solutions
simples, du moins rationnellement et pédagogiquement expliquées.
Autrement, on risque de voir des programmeurs ignorer cet outil
formidable parce que leurs rencontres auraient été indigestes. On aura
gâcher une opportunité de convaincre les gens à améliorer leurs
programmes ou comment il les écrivent.


Je ne sais pas si tu parles encore de « Modern C++ Design ». Il ne
s'agit aucunement selon moi d'une présentation sur les templates. Il
les utilise bien sûr abondamment en tant qu'outil, et présente comme
il se doit les aspects non-triviaux qu'il en utilise.

J'avoue être fort étonné par ce que tu dis. Je n'ai pas eu
l'occasion de voir beaucoup de critiques du bouquin, et aucune d'en
parler avec des connaissances (a fortiori des gens qui auraient
découvert les templates par son entremise). Je ne connaissais
moi-même pas du tout nombre d'aspects des templates employés dans le
livre, et les ai découvert avec cette aisance des choses pas si
simples mais bien expliquées. J'ai sans doute un peu vite conclu que
ce ne pouvait qu'être le cas pour quiconque.

--drkm

Avatar
Gabriel Dos Reis
drkm writes:

[...]

| Mais rassure-moi, tu n'as pas été exaustif, ici. Tu as oublié la
| catégorie des personnes qui ont découvert un intérêt nouveau aux
| techniques templates.

Oui, mais ceux-là sont déjà « sauvés » ;-))

Mais, le fond du problème est réel. Que ces arguments soient valides
ou invalides n'est pas vraiment la question -- parce que les reactions
sont vraiment dès fois proches de la foi. Et la masse de programmeurs
qui ignorent les templates sciemment ou non est _très_ importante,
beaucoup plus que tu ne le crois. C'est un vrai problème.

| > évidemment, c'est un problème qui comporte une part d'éducation et
| > cela prend du temps.
|
| > | > Et c'est triste. :-(. Je
| > | > connais beaucoup de gens influents dans la communauté C++ qui pensent
| > | > que même si le bouquin a le mérite de collectionner en un seul endroit
| > | > des techniques faisant partie du folklore culturel aux alentours de
| > | > 1997-1999, il n'en fait pas forcément une bonne présentation
| > | > pédagogique
|
| > | Quelle drôle d'idée.
|
| > ???
|
| Je trouve une drôle d'idée celle-ci : « Modern C++ Design ne fait
| pas une présentation pédagogique de son sujet ». Il est vrai que les
| techniques employées ne sont pas toujours évidentes. Mais justement.
| Tout au long du livre, je n'ai cessé de penser « Mon dieu, mais c'est
| bien sûr. C'est clair et limpide. Pourquoi n'ai-je pas écrit ce
| livre avant ? C'est pourtant si simple. » ;-)

C'est tant mieux que tu le trouves clair et pédagogique. Mais de ce
que je peux voir et des réactions d'autres personnes bien installées
dans la communauté, ton impression ne serait pas universelle.

Voici deux exmples de livres qui étaient très avancés pour leur époque
(et qui continuent à être recommandés bien qu'ils bénéficieraient bien
d'un lifting) :

* Barton & Nackman

Scientific and Engineering C++ : An Introduction with Advanced
Techniques and Examples
Addison-Wesley, 1994

Ce bouquin a influencé même la norme tant du côté de la bibliothèque
que la spécification des templates eux-mêmes -- et il faut vraiment
le lire pour voir ce que je disais au niveau de la présentation
pédagogique.

* Coplien

Advanced C++ Programming Styles and Idioms
Addison-Wesley, 1991

C'est un peu provocateur de donner le bouquin du Prof. Coplien en
exemple, mais c'est justement pour illustrer le point de la pédagogie.
Il faut vraiment les avoir lu pour comprendre ce que je veux dire.

| > | > et applicative.
|
| > | Je ne vois pas ce que tu veux dire par là. Parles-tu de la mise en
| > | situation des techniques décrites ? Si oui, je trouve cela étrange,
| > | comme idée.
|
| > Il y a de bonnes idées dans ce bouquin. Seulement, je crois des fois
| > l'illustration est noyée dans trop de technicités
|
| Pour moi, ce bouquin est résolument technique. Il ne comporte pas

On peut être technique sans noyer dans la technicité. Voir les deux
bouquins que je cite plus haut.

| beaucoup de mises en situation du code développé. Mais c'est parce
| que si l'implémentation est originale, les techniques employées
| nouvelles pour beaucoup, les outils définis sont eux bien classiques,
| ou leur problématique bien connue :
|
| Ch. 1-3 [techniques utilisées tout au long du livre]
| Ch. 4 Small-Object Allocation
| Ch. 5 Generalized Functors
| Ch. 6 Implementing Singletons
| Ch. 7 Smart Pointers
| Ch. 8 Object Factories
| Ch. 9 Abstract Factories
| Ch. 10 Visitor
| Ch. 11 Multimethods

Tu crois que je me concentre sur les noms des chapitres lorsque je te
parle du contenu ? Ce dont je te parle, c'est comment le contenu est
présenté. Encore une fois, regarde les deux bouquins cités plus haut,

[...]

| > Je suis mal placé pour en parler plus longuement :-)
|
| Et par là ?-)

Que je suis vraiment mal placé pour en parler plus longuement sans que
mes propos ne soient mal interprêtés. Usenet est un endroit bizarre.

[...]

| > Le fond de l'histoire est qu'une présentation des templates doit se
| > concentrer sur les problèmes communs et suggérer des solutions
| > simples, du moins rationnellement et pédagogiquement expliquées.
| > Autrement, on risque de voir des programmeurs ignorer cet outil
| > formidable parce que leurs rencontres auraient été indigestes. On aura
| > gâcher une opportunité de convaincre les gens à améliorer leurs
| > programmes ou comment il les écrivent.
|
| Je ne sais pas si tu parles encore de « Modern C++ Design ». Il ne

Toujours, mais dans un cadre plus général.

| s'agit aucunement selon moi d'une présentation sur les templates. Il
| les utilise bien sûr abondamment en tant qu'outil, et présente comme
| il se doit les aspects non-triviaux qu'il en utilise.

Qu'est-ce que tu comprends par présentation des templates ?
Un bouquin, a priori destiné aux programmeurs, qui utilise comme outil
fondamental les templates n'est pas une présentation des
templates ? Pour moi, cela en est une ; une mise en situation et
utilisation concrête.

| J'avoue être fort étonné par ce que tu dis. Je n'ai pas eu

J'avoue être étonné que tu sois étonné :-)

| l'occasion de voir beaucoup de critiques du bouquin, et aucune d'en
| parler avec des connaissances (a fortiori des gens qui auraient
| découvert les templates par son entremise). Je ne connaissais

C'est probablement pour ça que je ne fais pas de review marketting de
bouquins :-) Je me ferais trop d'ennemis en disant ce que je pense.
Je fais volontiers les reviews techniques.

| moi-même pas du tout nombre d'aspects des templates employés dans le
| livre, et les ai découvert avec cette aisance des choses pas si

C'est ça le point. Beaucoup de gens, bien plus que tu ne l'imagines,
ne connaissent pas beaucoup les templates (ou ses potentialités) et
arrivent sur ce bouquin pour une raison X ou Y. Et le danger est bien
réel et les réactions concrêtes et nombreuses (je ne peux
malheureusement pas nommer l'ami dont je parlais plus haut, la
situation est suffisamment complexe comme cela) et ceci de la part
d'honnêtes programmeurs C++. Si j'étais seul à le penser, cela n'aurait
aucune importance ; et je ne crois pas que j'aurais écrit trois
messages qui vont être sûrement mal interprêtés sur Usenet.

| simples mais bien expliquées. J'ai sans doute un peu vite conclu que
| ce ne pouvait qu'être le cas pour quiconque.

Tu as la marque des génies :-)

-- Gaby
Avatar
James Kanze
Gabriel Dos Reis writes:

|> writes:

|> | Sa lecture est bien dans ma liste de choses à faire. Seulement,
|> | dans la mésure où je connais un peu ce que fait Andrei en général,
|> | et que je sais ne pas pouvoir l'appliquer dans un futur proche, ce
|> | n'est pas d'une priorité très élevée.

|> On dirait que ce bouquin a ruiné les chances d'application des
|> techniques templates dans nombre d'endroit. Et c'est triste. :-(. Je
|> connais beaucoup de gens influents dans la communauté C++ qui
|> pensent que même si le bouquin a le mérite de collectionner en un
|> seul endroit des techniques faisant partie du folklore culturel aux
|> alentours de 1997-1999, il n'en fait pas forcément une bonne
|> présentation pédagogique et applicative.

Merci d'avoir donné un contre-avis. À vrai dire, à juger d'après les
articles de Andrei ailleurs, je me serais pas attendu à « une bonne
présentation pédagogique et applicative » de toute façon:-). Mais pour
ça, il y a le Josuttis et Vandevoorde, qui a l'avantage d'être l'un des
livres techniques le mieux écrits que je connais.

Dans mon cas, évidemment, je ne le lirais pas tellement pour acquérir
des techniques que je compte mettre tout de suite en pratique, mais
plutôt à titre d'acquérir une partie essentielle de culture C++
générale. En somme, simplement parce qu'il est tellement cité, il faut
le connaître.

Mais c'est une raison qui n'a pas une haute priorité -- il y a tellement
de choses qu'il faut que je lise pour les utiliser réelement (de la SQL,
par exemple). Ce qui explique pourquoi je n'y suis pas encore arrivé.

|> L'une de ses personnes, en consultance dans une entreprise, a vu ses
|> interlocteurs virés au rouge lorsqu'il a mentionné template et
|> méta-programmation -- ils ont cru qu'il allait leur parler des
|> choses dans ce bouquin.

Ça, malheureusement, c'est un danger avec beaucoup de choses. Selon les
préjugés de l'interlocuteur. J'ai déjà rencontré cette attitude
vis-à-vis la STL, par exemple. (Il y a quelques jours seulement !) En
revanche, lors de mon intervue d'embauche où je suis maintenant, il
était beaucoup question de la méta-programmation, des traits, de la
spécialisation, etc. Aussi un préjugé, en quelque sort, étant donné que
le boulot, c'est de la maintenance sur un programme écrit il y a un
certain nombre d'années, et qu'on compile encore avec Sun CC mode
compat=4. (Enfin, je l'ai porté à g++ 3.4.0 ; il y a donc des chances
qu'à l'avenir...)

|> Heureusement pour lui, cela n'était pas le cas -- donc cela s'est
|> bien passé finalement.

L'art de passer des intervues de travail, c'est d'abord de déterminer
les préjugés de l'interviewer. Ensuite, on décide si on veut le boulot
ou non ; si on le veut, on s'adapte un peu aux préjugés.

--
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
Arnaud Meurgues
Gabriel Dos Reis wrote:

sont vraiment dès fois proches de la foi. Et la masse de programmeurs
qui ignorent les templates sciemment ou non est _très_ importante,
beaucoup plus que tu ne le crois. C'est un vrai problème.


Il y en a aussi une partie (que je ne saurais pas quantifier) qui ne les
utilise pas parce qu'ils ont été refroidis par les performances des
compilateurs en la matière.

C'est tant mieux que tu le trouves clair et pédagogique. Mais de ce
que je peux voir et des réactions d'autres personnes bien installées
dans la communauté, ton impression ne serait pas universelle.


Je n'ai pas fini le bouquin, mais mon impressionquand j'ai commencé à le
lire est qu'il commençait par exposer les moyens avant d'exposer les fins.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Avatar
Loïc Joly
drkm wrote:

Gabriel Dos Reis writes:


On dirait que ce bouquin a ruiné les chances d'application des
techniques templates dans nombre d'endroit.



Heu, je ne comprend pas bien comment. En présentant les choses de
manière trop hermétique (ce n'est pas mon avis) ?


Et c'est triste. :-(. Je
connais beaucoup de gens influents dans la communauté C++ qui pensent
que même si le bouquin a le mérite de collectionner en un seul endroit
des techniques faisant partie du folklore culturel aux alentours de
1997-1999, il n'en fait pas forcément une bonne présentation
pédagogique



Quelle drôle d'idée.


et applicative.



Je ne vois pas ce que tu veux dire par là. Parles-tu de la mise en
situation des techniques décrites ? Si oui, je trouve cela étrange,
comme idée.


Personellement, j'ai beaucoup aimé ce livre, mais je rejoins assez
l'avis de Gaby. Je le considère plus comme quelques pensées "en
brouillon" couchées par écrit (et donc orienté "recherche") que comme un
document de référence sur des techniques éprouvées orienté "industrie".

Je pense que le problème est qu'à l'époque où il est paru, il n'y avait
pas forcément d'ouvrages sur les utilisations "avancées" des templates,
et que ce livre s'est vu attribué par défaut une place qu'il n'avait pas
de prédispositions pour prendre.

--
Loïc


1 2 3 4 5