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++ Aide pour realiser une classe de manipualtion de donnees

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
Signaler un problème avec ce contenu

10 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 3 4 5
Avatar
Aurélien REGAT-BARREL
Il explique ce que c'est ici :
http://www.cuj.com/documents/sy86/cujcexp2002alexandr/alexandr.htm
Mais bon chaque chose en son temps. Là j'ai pas fini de lire les 32 pages
sur les smart ptr. Toutes les 2 pages je découvre une technique de fourbe.
Du coup je vais pas tarder à investir dans son bouquin.

--
Aurélien REGAT-BARREL
Avatar
drkm
"Aurélien REGAT-BARREL" writes:

Il explique ce que c'est ici :
http://www.cuj.com/documents/sy86/cujcexp2002alexandr/alexandr.htm
Mais bon chaque chose en son temps. Là j'ai pas fini de lire les 32 pages
sur les smart ptr. Toutes les 2 pages je découvre une technique de fourbe.
Du coup je vais pas tarder à investir dans son bouquin.


C'est un excellent investissement.

Et AMHA, il est intéressant de commencer par les deux premiers
chapitres, « Policy Classes » et « Techniques », avant tout autre.

--drkm

Avatar
kanze
(drkm) wrote in message
news:...
wrote in message
news::
drkm wrote in message
news:...

Je n'ai suivi la discussion que de loin, mais il me semble qu'il
s'agit ici d'un problème de typage *à la compilation*. Ne
vaudrait-il pas mieux utiliser quelque chose comme les TypeList
d'Alexandrescu ?


Je ne sais pas ; je ne connais pas TypeList. Étant obligé à utiliser
des compilateurs assez anciens, et d'écrire du code que peuvent
comprendre des collègues qui ne veulent pas se mettre à jour, j'ai
rarement l'occasion de pouvoir profiter de ce que fait Andrei.


C'est bien dommage. Mais même dans ces conditions, je pense que la
lecture de "Modern C++ Design" est des plus intéressantes. Débutant,
ce fut mon premier réel contact avec les templates, dans un contexte
autre que le simple paramétrage d'un conteneur sur un type. Le texte
n'est pas très conséquent, se lit vite, mais c'est du concentré.


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.

Est-ce une
implémentation de ce que je propose ?


Ma fois, je ne sais pas. Je n'avais déjà suivi cette discussion que
de loin il y a deux semaines. Là, je n'ai pas le courage de reprendre
le fil depuis le début. En deux mots, les Typelists sont des sortes de
listes chaînées de types. Un noeud de la liste est :

template < class T , class U >
struct Typelist
{
typedef T Head ;
typedef U Tail ;
} ;

NullType est défini comme valeur sentinelle de fin.


C'est intéressant, mais je crois que son utilité se trouve surtout dans
la contexte d'autres templates. Dans notre cas, il nous fallait bien
quelque chose qui puisse servir d'indice pour un set ou un map. Du genre :

struct TypeInfoLess
{
bool operator()(
typeinfo const* lhs,
typeinfo const* rhs )
{
return lhs->before( *rhs ) ;
}
} ;

struct TripletInfo
{
std::set< typeinfo const*, TypeInfoLess >
supportedDiplayTypes ;
std::string label ;
// ... ?

bool isSupported( type_info const& display ) const
{
return supportedDiplayTypes.find( &display )
!= supportedDiplayTypes.end() ;
}
} ;

typedef < std::map< typeinfo const*, TripletInfo > >
TripletInfoMap ;
TripletInfoMap tripletInfoMap ;

// Dans Display...
TripletInfoMap::const_iterator
tripletInfo
= tripletInfoMap.find( triplet->type ) ;
if ( tripletInfo != tripletInfoMap.end()
&& tripletInfo->second.isSupported( typeid( *this ) ) ) {
// C'est bon...
// Affiche avec tripletInfo->second.label...
}

On a besoin de plus que des typedef ici.

--
James Kanze GABI Software http://www.gabi-soft.fr
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
kanze
"Aurélien REGAT-BARREL" wrote in
message news:<40f24d90$0$25748$...

Donc j'ai opté pour une solution à base de template.
L'interface ITriplet n'existe nul part, elle est purement logique.


Je ne suis pas sûr, mais je crois que dans ce cas-là, on parle de
concepte, plutôt que d'interface. Un concepte étant justement une
interface qui n'est pas matérialisée.

Au moins que la différence principale soit le fait qu'un type peut a
postiori implémenter un concepte ; souvent, le concepte est en fait une
abstraction de quelque chose qui est en fait common à un certain nombre
de types existants. (On pense, par exemple, au concepte Assignable de la
STL. Quand K&R ont défini « int », ils n'ont certainement pas pensé à ce
qu'il faut qu'il implémente un concepte de la STL. C'est plutôt le
contraire, quand Stepanov concevait la STL, il a plutôt défini des
conceptes en fonction de ce qui était commun à un grand nombre de types
existants, comme int.)

--
James Kanze GABI Software http://www.gabi-soft.fr
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
Gabriel Dos Reis
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. 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. Heureusement pour lui, cela
n'était pas le cas -- donc cela s'est bien passé finalement.

-- Gaby
Avatar
Aurélien REGAT-BARREL
Je ne suis pas sûr, mais je crois que dans ce cas-là, on parle de
concepte, plutôt que d'interface. Un concepte étant justement une
interface qui n'est pas matérialisée.

Au moins que la différence principale soit le fait qu'un type peut a
postiori implémenter un concepte ; souvent, le concepte est en fait une
abstraction de quelque chose qui est en fait common à un certain nombre
de types existants. (On pense, par exemple, au concepte Assignable de la
STL. Quand K&R ont défini « int », ils n'ont certainement pas pensé à ce
qu'il faut qu'il implémente un concepte de la STL. C'est plutôt le
contraire, quand Stepanov concevait la STL, il a plutôt défini des
conceptes en fonction de ce qui était commun à un grand nombre de types
existants, comme int.)


A c'est possible. Mais suite à l'autre thread, ce serait finalement bien une
interface, avec une présence dans le code d'une classe template ITriplet.
L'implementation de cette interface est faite ainsi :

class ABC : public ITriplet<ABC>
{
public:
void MethodeSpecifiqueABC();

public:
// fonctions / variables nécessaires pour implémenter ITriplet
};

Si demain j'ai une deuxième interface à implémenter :

class ABC : public ITriplet<ABC>, public AutreInterface<ABC>
{
};

--
Aurélien REGAT-BARREL

Avatar
drkm
writes:

C'est intéressant, mais je crois que son utilité se trouve surtout dans
la contexte d'autres templates.


Bien sûr.

Dans notre cas, il nous fallait bien
quelque chose qui puisse servir d'indice pour un set ou un map.


Ok.

--drkm

Avatar
Gabriel Dos Reis
writes:

| Au moins que la différence principale soit le fait qu'un type peut a
| postiori implémenter un concepte ; souvent, le concepte est en fait une
| abstraction de quelque chose qui est en fait common à un certain nombre
| de types existants. (On pense, par exemple, au concepte Assignable de la
| STL. Quand K&R ont défini « int », ils n'ont certainement pas pensé à ce
| qu'il faut qu'il implémente un concepte de la STL.

Dennis Ritchie a certainement estimé qu'il voulait faire une affection
à un int ;-)

[ Dennis Ritchie, tout comme Bjarne Stroustrup, ou Alex Stepanov, ou
les gens de Cambridge qui ont inventé BCPL ont reçu de très bonne
éducation en maths et ont une capacité d'abstraction qui les place
hautement au-dessus de la masse :-) ]


-- Gaby
Avatar
drkm
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.

--drkm

Avatar
Gabriel Dos Reis
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. :-(

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
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.

:-(

é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.

???

| > 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 (ou parfois du
marketing). Je suis mal placé pour en parler plus longuement :-)

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 ;-)

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.

-- Gaby
1 2 3 4 5