Franck Branjonneau wrote on 13/09/2006 01:17:Si cela fonctionne, ce n'est que le fruit du hasard (des
choix de ton implémentation) : std::vector<>::begin()
retourne un iterateur.
c'est quoi un "iterateur"
(ça se (s'auto) définit comment?
quels sont ses propres opérateurs de cast?)
Rm: ça retourne un "iterateur" ou un "iterateur const".
Franck Branjonneau wrote on 13/09/2006 01:17:
Si cela fonctionne, ce n'est que le fruit du hasard (des
choix de ton implémentation) : std::vector<>::begin()
retourne un iterateur.
c'est quoi un "iterateur"
(ça se (s'auto) définit comment?
quels sont ses propres opérateurs de cast?)
Rm: ça retourne un "iterateur" ou un "iterateur const".
Franck Branjonneau wrote on 13/09/2006 01:17:Si cela fonctionne, ce n'est que le fruit du hasard (des
choix de ton implémentation) : std::vector<>::begin()
retourne un iterateur.
c'est quoi un "iterateur"
(ça se (s'auto) définit comment?
quels sont ses propres opérateurs de cast?)
Rm: ça retourne un "iterateur" ou un "iterateur const".
Normal, mais pourquoi f n'est-elle pas déclarée:
void f(std::vector<CPoint>& points);
qui est la forme à laquelle on s'attend si on utilise la SL.
Bé d'abord parce que je découvre la STL,
ensuite cela m'évite de tout changer dans un premier temps,
puis cela fait des déclarations à rallonge :o)
Normal, mais pourquoi f n'est-elle pas déclarée:
void f(std::vector<CPoint>& points);
qui est la forme à laquelle on s'attend si on utilise la SL.
Bé d'abord parce que je découvre la STL,
ensuite cela m'évite de tout changer dans un premier temps,
puis cela fait des déclarations à rallonge :o)
Normal, mais pourquoi f n'est-elle pas déclarée:
void f(std::vector<CPoint>& points);
qui est la forme à laquelle on s'attend si on utilise la SL.
Bé d'abord parce que je découvre la STL,
ensuite cela m'évite de tout changer dans un premier temps,
puis cela fait des déclarations à rallonge :o)
Si tu changes le type d'un paramètre, il faut bien changer la
déclaration des fonctions qui le prend, non ? Sinon, je dirais
qu'il y a un vrai problème.
Si tu changes le type d'un paramètre, il faut bien changer la
déclaration des fonctions qui le prend, non ? Sinon, je dirais
qu'il y a un vrai problème.
Si tu changes le type d'un paramètre, il faut bien changer la
déclaration des fonctions qui le prend, non ? Sinon, je dirais
qu'il y a un vrai problème.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche,
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche,
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche,
Franck Branjonneau wrote on 13/09/2006 01:14:void f(std::vector<CPoint>& points);
Bé d'abord parce que je découvre la STL, ensuite cela m'évite de tout
changer dans un premier temps, puis cela fait des déclarations à
rallonge :o)
inline void f(std::vector<CPoint>& points) { return f(&points[0]); }
tu plaisantes ?
Franck Branjonneau wrote on 13/09/2006 01:14:
void f(std::vector<CPoint>& points);
Bé d'abord parce que je découvre la STL, ensuite cela m'évite de tout
changer dans un premier temps, puis cela fait des déclarations à
rallonge :o)
inline void f(std::vector<CPoint>& points) { return f(&points[0]); }
tu plaisantes ?
Franck Branjonneau wrote on 13/09/2006 01:14:void f(std::vector<CPoint>& points);
Bé d'abord parce que je découvre la STL, ensuite cela m'évite de tout
changer dans un premier temps, puis cela fait des déclarations à
rallonge :o)
inline void f(std::vector<CPoint>& points) { return f(&points[0]); }
tu plaisantes ?
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche, j'avoue que c'est le principal.
Respecter la norme pour la norme, ce n'est pas mon truc.
En un truc qui la respecte à la lettre, et un autre un peu
moins mais valable et plus lisible, mon choix est vite fait.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche, j'avoue que c'est le principal.
Respecter la norme pour la norme, ce n'est pas mon truc.
En un truc qui la respecte à la lettre, et un autre un peu
moins mais valable et plus lisible, mon choix est vite fait.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche, j'avoue que c'est le principal.
Respecter la norme pour la norme, ce n'est pas mon truc.
En un truc qui la respecte à la lettre, et un autre un peu
moins mais valable et plus lisible, mon choix est vite fait.
Si tu changes le type d'un paramètre, il faut bien changer la
déclaration des fonctions qui le prend, non ? Sinon, je dirais
qu'il y a un vrai problème.
Jusqu'à présent, quand je définissais des tableaux, j'utilisais tou jours
des trucs du genre :
A machin[NB_MAX]
f(A *pmachin);
Puis j'appelais de la manière suivante : f(machin);
En gros.
Pourquoi?
Parce que j'avais appris comme ça il y a trèèèèèès longtemp s.
Pendant longtemps j'ai eu la flemme d'apprendre la STL, mon
projet initial ne devant pas prendre tant d'ampleur.
Donc je déclarais les tableaux à l'ancienne, mais maintenant,
j'estime que dans un programme moderne, si on limite de
manière définitive la taille des tableaux (par exemple des
tableaux de divers objets graphiques), pour l'utilisateur
c'est trop contraignant.
D'où passage à la STL qui permet de s'affranchir de ça et de
gérer plus facilement la mémoire.
Donc, dans un premier temps, j'essaie de modifier le moins de
chose (en gros, uniquement les déclaration quand c'est
possible) en essayant de réutiliser l'existant.
Si je modifie tout d'un coup, c'est le plantage assuré
Si tu changes le type d'un paramètre, il faut bien changer la
déclaration des fonctions qui le prend, non ? Sinon, je dirais
qu'il y a un vrai problème.
Jusqu'à présent, quand je définissais des tableaux, j'utilisais tou jours
des trucs du genre :
A machin[NB_MAX]
f(A *pmachin);
Puis j'appelais de la manière suivante : f(machin);
En gros.
Pourquoi?
Parce que j'avais appris comme ça il y a trèèèèèès longtemp s.
Pendant longtemps j'ai eu la flemme d'apprendre la STL, mon
projet initial ne devant pas prendre tant d'ampleur.
Donc je déclarais les tableaux à l'ancienne, mais maintenant,
j'estime que dans un programme moderne, si on limite de
manière définitive la taille des tableaux (par exemple des
tableaux de divers objets graphiques), pour l'utilisateur
c'est trop contraignant.
D'où passage à la STL qui permet de s'affranchir de ça et de
gérer plus facilement la mémoire.
Donc, dans un premier temps, j'essaie de modifier le moins de
chose (en gros, uniquement les déclaration quand c'est
possible) en essayant de réutiliser l'existant.
Si je modifie tout d'un coup, c'est le plantage assuré
Si tu changes le type d'un paramètre, il faut bien changer la
déclaration des fonctions qui le prend, non ? Sinon, je dirais
qu'il y a un vrai problème.
Jusqu'à présent, quand je définissais des tableaux, j'utilisais tou jours
des trucs du genre :
A machin[NB_MAX]
f(A *pmachin);
Puis j'appelais de la manière suivante : f(machin);
En gros.
Pourquoi?
Parce que j'avais appris comme ça il y a trèèèèèès longtemp s.
Pendant longtemps j'ai eu la flemme d'apprendre la STL, mon
projet initial ne devant pas prendre tant d'ampleur.
Donc je déclarais les tableaux à l'ancienne, mais maintenant,
j'estime que dans un programme moderne, si on limite de
manière définitive la taille des tableaux (par exemple des
tableaux de divers objets graphiques), pour l'utilisateur
c'est trop contraignant.
D'où passage à la STL qui permet de s'affranchir de ça et de
gérer plus facilement la mémoire.
Donc, dans un premier temps, j'essaie de modifier le moins de
chose (en gros, uniquement les déclaration quand c'est
possible) en essayant de réutiliser l'existant.
Si je modifie tout d'un coup, c'est le plantage assuré
typedef peut aider si tu t'obliges à changer tes interfaces,
cela risque de ne pas tout régler si tu utilises des libs
externes attendant un CPoint*
Si c'est une classe à lui, il a toutes les chances à avoir accès
à toutes les fonctions concernées.
La façon naturelle en C++ de passer un paramètre par référence,
c'est d'utiliser une référence. Si on a un problème avec des
bibliothèques externe, on le résoud en général avec un wrapper
(modèle décorateur) qui fait les conversions nécessaires.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
public:
Points(){}
operator CPoint* () { return begin(); }
Et ça, évidemment, ne se compile pas, sinon que par hazard avec
un ancien compilateur. (Il se compilait avec VC++ 6.0 ou g++
2.95.2, mais il ne se compile pas avec VC++ 2005 ni avec g++
4.1.0.)
operator const CPoint* () const { return begin(); }
Pareil.
Et qui permet aussi :
std::vector< CPoint >* pv = new Points ;
delete pv ; // Comportement indéfini.
Mais vu que le code ne se compile pas avec un compilateur
moderne (et n'a jamais été légal), qu'importe.
typedef peut aider si tu t'obliges à changer tes interfaces,
cela risque de ne pas tout régler si tu utilises des libs
externes attendant un CPoint*
Si c'est une classe à lui, il a toutes les chances à avoir accès
à toutes les fonctions concernées.
La façon naturelle en C++ de passer un paramètre par référence,
c'est d'utiliser une référence. Si on a un problème avec des
bibliothèques externe, on le résoud en général avec un wrapper
(modèle décorateur) qui fait les conversions nécessaires.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
public:
Points(){}
operator CPoint* () { return begin(); }
Et ça, évidemment, ne se compile pas, sinon que par hazard avec
un ancien compilateur. (Il se compilait avec VC++ 6.0 ou g++
2.95.2, mais il ne se compile pas avec VC++ 2005 ni avec g++
4.1.0.)
operator const CPoint* () const { return begin(); }
Pareil.
Et qui permet aussi :
std::vector< CPoint >* pv = new Points ;
delete pv ; // Comportement indéfini.
Mais vu que le code ne se compile pas avec un compilateur
moderne (et n'a jamais été légal), qu'importe.
typedef peut aider si tu t'obliges à changer tes interfaces,
cela risque de ne pas tout régler si tu utilises des libs
externes attendant un CPoint*
Si c'est une classe à lui, il a toutes les chances à avoir accès
à toutes les fonctions concernées.
La façon naturelle en C++ de passer un paramètre par référence,
c'est d'utiliser une référence. Si on a un problème avec des
bibliothèques externe, on le résoud en général avec un wrapper
(modèle décorateur) qui fait les conversions nécessaires.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
public:
Points(){}
operator CPoint* () { return begin(); }
Et ça, évidemment, ne se compile pas, sinon que par hazard avec
un ancien compilateur. (Il se compilait avec VC++ 6.0 ou g++
2.95.2, mais il ne se compile pas avec VC++ 2005 ni avec g++
4.1.0.)
operator const CPoint* () const { return begin(); }
Pareil.
Et qui permet aussi :
std::vector< CPoint >* pv = new Points ;
delete pv ; // Comportement indéfini.
Mais vu que le code ne se compile pas avec un compilateur
moderne (et n'a jamais été légal), qu'importe.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche, j'avoue que c'est le principal.
Respecter la norme pour la norme, ce n'est pas mon truc.
En un truc qui la respecte à la lettre, et un autre un peu moins mais
valable et plus lisible, mon choix est vite fait.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche, j'avoue que c'est le principal.
Respecter la norme pour la norme, ce n'est pas mon truc.
En un truc qui la respecte à la lettre, et un autre un peu moins mais
valable et plus lisible, mon choix est vite fait.
class Points : public vector<CPoint> {
Ce n'est pas en général une bonne idée d'hériter de std::vector.
Il n'a pas été conçu pour servir de classe de base.
Oui mais si ça marche, j'avoue que c'est le principal.
Respecter la norme pour la norme, ce n'est pas mon truc.
En un truc qui la respecte à la lettre, et un autre un peu moins mais
valable et plus lisible, mon choix est vite fait.
