Bonjour,
J'aimerais bien créer quelques classes qui dérivent de certains conteneurs
de la STL. Je sais que ces derniers ne sont pas conçus pour être dérivés,
mais sachant que le but est simplement de :
- créer un vrai nouveau type au lieu d'un typedef
- ne pas ajouter de donnée membre mais uniquement dfes fonctions
est-ce une pratique acceptable ?
Exemple:
class SortedData : public std::set<int>
{
public:
SortedData( const std::vector<int> & Vect )
{
this->insert( Vect.begin(), Vect.end() );
}
// calcule la moyenne
double Average() const
{
int total = 0;
total = std::accumulate( this->begin(), this->end(), total );
return total * 1.0 / this->size();
}
};
demande-toi si casser ainsi l'encapsulation (i.e. demander à l'utilisateur de la classe de connaître la présence du membre privé x) est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur que tu utilises reellement. Au fait, pour des points tu n'as meme pas un bon ordre pour ton set. A la rigueur tu peux utiliser une transformation fractale (celle de Hilbert par exemple qui garde une bonne localite mais dans un sens uniquement: H(p) proche de H(q) indique que p et q sont proches, mais p et q proche ne force pas H(p) et H(q) a etre proche).
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
"noone@nowhere.com" <noone@nowhere.com> writes:
demande-toi si casser ainsi l'encapsulation (i.e. demander à
l'utilisateur de la classe de connaître la présence du membre privé x)
est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul
de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur
que tu utilises reellement. Au fait, pour des points tu n'as meme pas
un bon ordre pour ton set. A la rigueur tu peux utiliser une
transformation fractale (celle de Hilbert par exemple qui garde une
bonne localite mais dans un sens uniquement: H(p) proche de H(q)
indique que p et q sont proches, mais p et q proche ne force pas H(p)
et H(q) a etre proche).
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
demande-toi si casser ainsi l'encapsulation (i.e. demander à l'utilisateur de la classe de connaître la présence du membre privé x) est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur que tu utilises reellement. Au fait, pour des points tu n'as meme pas un bon ordre pour ton set. A la rigueur tu peux utiliser une transformation fractale (celle de Hilbert par exemple qui garde une bonne localite mais dans un sens uniquement: H(p) proche de H(q) indique que p et q sont proches, mais p et q proche ne force pas H(p) et H(q) a etre proche).
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
noone
On Fri, 21 Jan 2005 16:48:20 +0100, "" :
pourquoi 2 itérateurs ?
C'est l'idiome STL : toute fonction qui doit agir sur un ensemble d'éléments prend comme paramètre un itérateur sur le premier élément et un itérateur sur l'élément "past the end" (i.e. l'itérateur qui suit directement le dernier élément).
je n'avais pas compris ça...
j'avais compris 4 arguments (pour 2 ensembles)
On Fri, 21 Jan 2005 16:48:20 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
pourquoi 2 itérateurs ?
C'est l'idiome STL : toute fonction qui doit agir sur un ensemble
d'éléments prend comme paramètre un itérateur sur le premier élément
et un itérateur sur l'élément "past the end" (i.e. l'itérateur qui
suit directement le dernier élément).
C'est l'idiome STL : toute fonction qui doit agir sur un ensemble d'éléments prend comme paramètre un itérateur sur le premier élément et un itérateur sur l'élément "past the end" (i.e. l'itérateur qui suit directement le dernier élément).
je n'avais pas compris ça...
j'avais compris 4 arguments (pour 2 ensembles)
Fabien LE LEZ
Je reprends le problème à zéro.
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec éventuellement des mélanges entre les trois) :
- un std::list<> (ou n'importe quel autre conteneur de la STL) avec des fonctions externes pour faire ce dont tu as besoin
- une classe qui a une interface "à la STL" (ou un autre type d'interface similaire) :
class C { public: class iterator // ou un typedef { public: iterator& ++(); iterator ++ (int); Objet& operator * (); private: ... }; class const_iterator // presque pareil
Note que je n'ai pas mis les membres privés -- c'est un détail d'implémentation, pas une partie de l'interface.
-- ;-)
Je reprends le problème à zéro.
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec
éventuellement des mélanges entre les trois) :
- un std::list<> (ou n'importe quel autre conteneur de la STL) avec
des fonctions externes pour faire ce dont tu as besoin
- une classe qui a une interface "à la STL" (ou un autre type
d'interface similaire) :
class C
{
public:
class iterator // ou un typedef
{
public:
iterator& ++();
iterator ++ (int);
Objet& operator * ();
private:
...
};
class const_iterator // presque pareil
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec éventuellement des mélanges entre les trois) :
- un std::list<> (ou n'importe quel autre conteneur de la STL) avec des fonctions externes pour faire ce dont tu as besoin
- une classe qui a une interface "à la STL" (ou un autre type d'interface similaire) :
class C { public: class iterator // ou un typedef { public: iterator& ++(); iterator ++ (int); Objet& operator * (); private: ... }; class const_iterator // presque pareil
Note que je n'ai pas mis les membres privés -- c'est un détail d'implémentation, pas une partie de l'interface.
-- ;-)
noone
"" writes:
demande-toi si casser ainsi l'encapsulation (i.e. demander à l'utilisateur de la classe de connaître la présence du membre privé x) est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur que tu utilises reellement. Au fait, pour des points tu n'as meme pas un bon ordre pour ton set. A la rigueur tu peux utiliser une transformation fractale (celle de Hilbert par exemple qui garde une bonne localite mais dans un sens uniquement: H(p) proche de H(q) indique que p et q sont proches, mais p et q proche ne force pas H(p) et H(q) a etre proche).
A+
ça n'est pas moi qui utilise set mais Aurélien
mon problème est ici : http://s.cls.free.fr/index.php?page=fieldE
"Charges" contient des "Charge" Charges utilise une liste en tant que membre privé.
"noone@nowhere.com" <noone@nowhere.com> writes:
demande-toi si casser ainsi l'encapsulation (i.e. demander à
l'utilisateur de la classe de connaître la présence du membre privé x)
est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul
de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur
que tu utilises reellement. Au fait, pour des points tu n'as meme pas
un bon ordre pour ton set. A la rigueur tu peux utiliser une
transformation fractale (celle de Hilbert par exemple qui garde une
bonne localite mais dans un sens uniquement: H(p) proche de H(q)
indique que p et q sont proches, mais p et q proche ne force pas H(p)
et H(q) a etre proche).
A+
ça n'est pas moi qui utilise set mais Aurélien
mon problème est ici :
http://s.cls.free.fr/index.php?page=fieldE
"Charges" contient des "Charge"
Charges utilise une liste en tant que membre privé.
demande-toi si casser ainsi l'encapsulation (i.e. demander à l'utilisateur de la classe de connaître la présence du membre privé x) est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur que tu utilises reellement. Au fait, pour des points tu n'as meme pas un bon ordre pour ton set. A la rigueur tu peux utiliser une transformation fractale (celle de Hilbert par exemple qui garde une bonne localite mais dans un sens uniquement: H(p) proche de H(q) indique que p et q sont proches, mais p et q proche ne force pas H(p) et H(q) a etre proche).
A+
ça n'est pas moi qui utilise set mais Aurélien
mon problème est ici : http://s.cls.free.fr/index.php?page=fieldE
"Charges" contient des "Charge" Charges utilise une liste en tant que membre privé.
Jean-Marc Bourguet
Fabien LE LEZ writes:
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec éventuellement des mélanges entre les trois) :
Pour etre clair, perso je definirais une classe conteneur avec des iterateurs (un sur tout, un sur les points dans une region rectangulaire), des fonctions de recherche (element le plus proche d'un point donne) et autres operations liees a un conteneur d'elements ayant des coordonnees spaciales. Une implementation initiale a base de std::list est naturellement possible et assez simple.
Pour l'affichage, le calcul des champs, ... il me semble que for_each sur la totalite doit suffire (a moins que je manque qqch? je n'ai jamais travaille sur des solveurs de champs).
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
Fabien LE LEZ <gramster@gramster.com> writes:
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec
éventuellement des mélanges entre les trois) :
Pour etre clair, perso je definirais une classe conteneur avec des
iterateurs (un sur tout, un sur les points dans une region
rectangulaire), des fonctions de recherche (element le plus proche
d'un point donne) et autres operations liees a un conteneur d'elements
ayant des coordonnees spaciales. Une implementation initiale a base
de std::list est naturellement possible et assez simple.
Pour l'affichage, le calcul des champs, ... il me semble que for_each
sur la totalite doit suffire (a moins que je manque qqch? je n'ai
jamais travaille sur des solveurs de champs).
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
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec éventuellement des mélanges entre les trois) :
Pour etre clair, perso je definirais une classe conteneur avec des iterateurs (un sur tout, un sur les points dans une region rectangulaire), des fonctions de recherche (element le plus proche d'un point donne) et autres operations liees a un conteneur d'elements ayant des coordonnees spaciales. Une implementation initiale a base de std::list est naturellement possible et assez simple.
Pour l'affichage, le calcul des champs, ... il me semble que for_each sur la totalite doit suffire (a moins que je manque qqch? je n'ai jamais travaille sur des solveurs de champs).
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
Jean-Marc Bourguet
"" writes:
"" writes:
demande-toi si casser ainsi l'encapsulation (i.e. demander à l'utilisateur de la classe de connaître la présence du membre privé x) est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul de E et B ? Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur
que tu utilises reellement. Au fait, pour des points tu n'as meme pas un bon ordre pour ton set. A la rigueur tu peux utiliser une transformation fractale (celle de Hilbert par exemple qui garde une bonne localite mais dans un sens uniquement: H(p) proche de H(q) indique que p et q sont proches, mais p et q proche ne force pas H(p) et H(q) a etre proche). A+
ça n'est pas moi qui utilise set mais Aurélien
Oops, il y a peut-etre de la confusion dans mes reponses.
mon problème est ici : http://s.cls.free.fr/index.php?page=fieldE
"Charges" contient des "Charge" Charges utilise une liste en tant que membre privé.
C'est deja mieux. Mais j'ai l'impression que la classe fait trop de choses. L'affichage devrait a coup sur etre completement separe. A la place d'un membre qui est une liste, j'aurais fait ce que j'esquisse dans un autre message: un membre qui est un conteneur specialise pour des elements ayant des coordonnees (meme si en pratique c'est une liste pour le moment).
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
"noone@nowhere.com" <noone@nowhere.com> writes:
"noone@nowhere.com" <noone@nowhere.com> writes:
demande-toi si casser ainsi l'encapsulation (i.e. demander à
l'utilisateur de la classe de connaître la présence du membre privé x)
est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul
de E et B ?
Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur
que tu utilises reellement. Au fait, pour des points tu n'as meme pas
un bon ordre pour ton set. A la rigueur tu peux utiliser une
transformation fractale (celle de Hilbert par exemple qui garde une
bonne localite mais dans un sens uniquement: H(p) proche de H(q)
indique que p et q sont proches, mais p et q proche ne force pas H(p)
et H(q) a etre proche).
A+
ça n'est pas moi qui utilise set mais Aurélien
Oops, il y a peut-etre de la confusion dans mes reponses.
mon problème est ici :
http://s.cls.free.fr/index.php?page=fieldE
"Charges" contient des "Charge"
Charges utilise une liste en tant que membre privé.
C'est deja mieux. Mais j'ai l'impression que la classe fait trop de
choses. L'affichage devrait a coup sur etre completement separe. A
la place d'un membre qui est une liste, j'aurais fait ce que
j'esquisse dans un autre message: un membre qui est un conteneur
specialise pour des elements ayant des coordonnees (meme si en
pratique c'est une liste pour le moment).
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
demande-toi si casser ainsi l'encapsulation (i.e. demander à l'utilisateur de la classe de connaître la présence du membre privé x) est vraiment une bonne chose. Ça l'est rarement.
et je fais comment alors pour interagir avec ma grille pour faire le calcul de E et B ? Tu fournis un iterateur (mais tout aussi encapsule) sur le conteneur
que tu utilises reellement. Au fait, pour des points tu n'as meme pas un bon ordre pour ton set. A la rigueur tu peux utiliser une transformation fractale (celle de Hilbert par exemple qui garde une bonne localite mais dans un sens uniquement: H(p) proche de H(q) indique que p et q sont proches, mais p et q proche ne force pas H(p) et H(q) a etre proche). A+
ça n'est pas moi qui utilise set mais Aurélien
Oops, il y a peut-etre de la confusion dans mes reponses.
mon problème est ici : http://s.cls.free.fr/index.php?page=fieldE
"Charges" contient des "Charge" Charges utilise une liste en tant que membre privé.
C'est deja mieux. Mais j'ai l'impression que la classe fait trop de choses. L'affichage devrait a coup sur etre completement separe. A la place d'un membre qui est une liste, j'aurais fait ce que j'esquisse dans un autre message: un membre qui est un conteneur specialise pour des elements ayant des coordonnees (meme si en pratique c'est une liste pour le moment).
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
noone
Fabien LE LEZ writes:
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec éventuellement des mélanges entre les trois) :
Pour etre clair, perso je definirais une classe conteneur avec des iterateurs (un sur tout, un sur les points dans une region rectangulaire), des fonctions de recherche (element le plus proche d'un point donne) et autres operations liees a un conteneur d'elements ayant des coordonnees spaciales. Une implementation initiale a base de std::list est naturellement possible et assez simple.
Pour l'affichage, le calcul des champs, ... il me semble que for_each sur la totalite doit suffire (a moins que je manque qqch? je n'ai jamais travaille sur des solveurs de champs).
A+
Merci de vos conseils éclairé à tous les 2 par contre j'ai un problème dans ma classe "Charges" pour enlever des Charge (remove sur une liste)
Pouvez-vous y jeter un oeil et m'indiquer ce qu'il faut faire car je suis débutant en C++ (j'ai un peu pratiqué le C, le VB, le C# et le Python)
Donc la STL c'est pas mon truc...
Vous pouvez m'écrire à l'adresse indiquée ici http://s.cls.free.fr/index.php?page=contact
Fabien LE LEZ <gramster@gramster.com> writes:
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec
éventuellement des mélanges entre les trois) :
Pour etre clair, perso je definirais une classe conteneur avec des
iterateurs (un sur tout, un sur les points dans une region
rectangulaire), des fonctions de recherche (element le plus proche
d'un point donne) et autres operations liees a un conteneur d'elements
ayant des coordonnees spaciales. Une implementation initiale a base
de std::list est naturellement possible et assez simple.
Pour l'affichage, le calcul des champs, ... il me semble que for_each
sur la totalite doit suffire (a moins que je manque qqch? je n'ai
jamais travaille sur des solveurs de champs).
A+
Merci de vos conseils éclairé à tous les 2 par contre j'ai un problème
dans ma classe "Charges" pour enlever des Charge (remove sur une liste)
Pouvez-vous y jeter un oeil et m'indiquer ce qu'il faut faire car je
suis débutant en C++ (j'ai un peu pratiqué le C, le VB, le C# et le Python)
Donc la STL c'est pas mon truc...
Vous pouvez m'écrire à l'adresse indiquée ici
http://s.cls.free.fr/index.php?page=contact
Si tu veux gérer un ensemble d'éléments, tu as trois solutions (avec éventuellement des mélanges entre les trois) :
Pour etre clair, perso je definirais une classe conteneur avec des iterateurs (un sur tout, un sur les points dans une region rectangulaire), des fonctions de recherche (element le plus proche d'un point donne) et autres operations liees a un conteneur d'elements ayant des coordonnees spaciales. Une implementation initiale a base de std::list est naturellement possible et assez simple.
Pour l'affichage, le calcul des champs, ... il me semble que for_each sur la totalite doit suffire (a moins que je manque qqch? je n'ai jamais travaille sur des solveurs de champs).
A+
Merci de vos conseils éclairé à tous les 2 par contre j'ai un problème dans ma classe "Charges" pour enlever des Charge (remove sur une liste)
Pouvez-vous y jeter un oeil et m'indiquer ce qu'il faut faire car je suis débutant en C++ (j'ai un peu pratiqué le C, le VB, le C# et le Python)
Donc la STL c'est pas mon truc...
Vous pouvez m'écrire à l'adresse indiquée ici http://s.cls.free.fr/index.php?page=contact
noone
C'est deja mieux. Mais j'ai l'impression que la classe fait trop de choses. L'affichage devrait a coup sur etre completement separe. A la place d'un membre qui est une liste, j'aurais fait ce que j'esquisse dans un autre message: un membre qui est un conteneur specialise pour des elements ayant des coordonnees (meme si en pratique c'est une liste pour le moment).
c'est un peu l'idée du MVC non ? mais dans ce cas je dois faire une classe pour la vue des point une classe pour la vue des charges une classe pour la vue des "graines" ...
ça me semble assez lourd à gérer...
C'est deja mieux. Mais j'ai l'impression que la classe fait trop de
choses. L'affichage devrait a coup sur etre completement separe. A
la place d'un membre qui est une liste, j'aurais fait ce que
j'esquisse dans un autre message: un membre qui est un conteneur
specialise pour des elements ayant des coordonnees (meme si en
pratique c'est une liste pour le moment).
c'est un peu l'idée du MVC non ?
mais dans ce cas je dois faire une classe pour la vue des point
une classe pour la vue des charges
une classe pour la vue des "graines"
...
C'est deja mieux. Mais j'ai l'impression que la classe fait trop de choses. L'affichage devrait a coup sur etre completement separe. A la place d'un membre qui est une liste, j'aurais fait ce que j'esquisse dans un autre message: un membre qui est un conteneur specialise pour des elements ayant des coordonnees (meme si en pratique c'est une liste pour le moment).
c'est un peu l'idée du MVC non ? mais dans ce cas je dois faire une classe pour la vue des point une classe pour la vue des charges une classe pour la vue des "graines" ...
ça me semble assez lourd à gérer...
Aurélien REGAT-BARREL
Tu mélanges mon post avec le sien. SortedData c'est moi, Charge c'est lui.
-- Aurélien REGAT-BARREL
Tu mélanges mon post avec le sien. SortedData c'est moi, Charge c'est lui.
