cout << "Voiture! Vous avez choisi une ";
switch(choix){
case 1:
cout << "Berline!" << endl << endl;
cout << "Modele selectionne' ?" << endl;
V = new berline;
break;
case 2:
cout << "Coupe!" << endl << endl;
cout << "Modele selectionne' ?" << endl;
V = new coupe;
break;
};
V->affiche_modele();
[/cpp]
berline et coupe sont deux classe fille de voiture
je veux changer ce main pour que je puisse configurer plusieur
voiture:
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture
*v [20][/cpp] mais ca ne marche pas, la syntaxe n est pas bonne
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
fu2 sur fr.comp.lang.c++
-- ;-)
Alex
Fabien LE LEZ wrote:
On 6 Feb 2005 13:20:19 -0800, (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé... Même si la STL est standard on peut toujours déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une extension.
Souvent c'est même dangereux de se laisser aller dans les tendances de représenter tout en objet, je passe un sacré temps à corriger les horibles constructions et copies de données comme ceci par exemple f(std::vector<vector<...> > vect) ou le vect est const et & suffisait. Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la performance en général. Sans parler derrière de fuite de mémoire etc. Je suis d'accord qu'il a les librairies qui sont franchement utile çà et là, dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20 pointeurs de voiture, il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur, surtout que le souci de la gestion de mémoire lié à voiture* reste.
Mais bon, je n'ai pas suivi cette file dès le début, peut-être j'ai tort...
Fabien LE LEZ wrote:
On 6 Feb 2005 13:20:19 -0800, boutkhourst.hassan@gmail.com (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture
*v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé... Même si la STL est standard on peut toujours
déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation
de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est
bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une
extension.
Souvent c'est même dangereux de se laisser aller dans les tendances de
représenter tout en objet, je passe un sacré temps à corriger les horibles
constructions et copies de données comme ceci par exemple
f(std::vector<vector<...> > vect) ou le vect est const et & suffisait.
Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la
performance en général. Sans parler derrière de fuite de mémoire etc. Je
suis d'accord qu'il a les librairies qui sont franchement utile çà et là,
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20
pointeurs de voiture, il n'y aurait peut-être jamais d'insertion ni
d'autres opérations liées au vecteur, surtout que le souci de la gestion de
mémoire lié à voiture* reste.
Mais bon, je n'ai pas suivi cette file dès le début, peut-être j'ai tort...
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé... Même si la STL est standard on peut toujours déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une extension.
Souvent c'est même dangereux de se laisser aller dans les tendances de représenter tout en objet, je passe un sacré temps à corriger les horibles constructions et copies de données comme ceci par exemple f(std::vector<vector<...> > vect) ou le vect est const et & suffisait. Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la performance en général. Sans parler derrière de fuite de mémoire etc. Je suis d'accord qu'il a les librairies qui sont franchement utile çà et là, dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20 pointeurs de voiture, il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur, surtout que le souci de la gestion de mémoire lié à voiture* reste.
Mais bon, je n'ai pas suivi cette file dès le début, peut-être j'ai tort...
Loïc Joly
Alex wrote:
Fabien LE LEZ wrote:
On 6 Feb 2005 13:20:19 -0800, (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé... Même si la STL est standard on peut toujours déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une extension.
Ce n'est pas vrai au sens formel du terme, mais, bon, je pense que ce n'est pas le sujet ici.
Souvent c'est même dangereux de se laisser aller dans les tendances de représenter tout en objet, je passe un sacré temps à corriger les horibles constructions et copies de données comme ceci par exemple f(std::vector<vector<...> > vect) ou le vect est const et & suffisait.
Et il est des cas où ça se justifie. Mais, bon, là, je vois plus un problème de quelqu'un qui n'y connait rien qu'un problème de sur-utilisation d'objet.
Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la performance en général.
J'ai plutôt vu des ex-javaiens utiliser des pointeurs à gogo, genre une classe fraction qui a un pointeur sur un numérateur et un pointeur sur un dénominateur...
Sans parler derrière de fuite de mémoire etc.
Là, je vois pas trop dans le code. Je vois des pertes de performances potentielles, mais pas de fuites mémoires avec l'utilisation de vector, et certainement moins qu'avec des pointeurs, surtout pour des gens venant de Java.
-- Loïc
Alex wrote:
Fabien LE LEZ wrote:
On 6 Feb 2005 13:20:19 -0800, boutkhourst.hassan@gmail.com (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture
*v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé... Même si la STL est standard on peut toujours
déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation
de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est
bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une
extension.
Ce n'est pas vrai au sens formel du terme, mais, bon, je pense que ce
n'est pas le sujet ici.
Souvent c'est même dangereux de se laisser aller dans les tendances de
représenter tout en objet, je passe un sacré temps à corriger les horibles
constructions et copies de données comme ceci par exemple
f(std::vector<vector<...> > vect) ou le vect est const et & suffisait.
Et il est des cas où ça se justifie. Mais, bon, là, je vois plus un
problème de quelqu'un qui n'y connait rien qu'un problème de
sur-utilisation d'objet.
Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la
performance en général.
J'ai plutôt vu des ex-javaiens utiliser des pointeurs à gogo, genre une
classe fraction qui a un pointeur sur un numérateur et un pointeur sur
un dénominateur...
Sans parler derrière de fuite de mémoire etc.
Là, je vois pas trop dans le code. Je vois des pertes de performances
potentielles, mais pas de fuites mémoires avec l'utilisation de vector,
et certainement moins qu'avec des pointeurs, surtout pour des gens
venant de Java.
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé... Même si la STL est standard on peut toujours déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une extension.
Ce n'est pas vrai au sens formel du terme, mais, bon, je pense que ce n'est pas le sujet ici.
Souvent c'est même dangereux de se laisser aller dans les tendances de représenter tout en objet, je passe un sacré temps à corriger les horibles constructions et copies de données comme ceci par exemple f(std::vector<vector<...> > vect) ou le vect est const et & suffisait.
Et il est des cas où ça se justifie. Mais, bon, là, je vois plus un problème de quelqu'un qui n'y connait rien qu'un problème de sur-utilisation d'objet.
Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la performance en général.
J'ai plutôt vu des ex-javaiens utiliser des pointeurs à gogo, genre une classe fraction qui a un pointeur sur un numérateur et un pointeur sur un dénominateur...
Sans parler derrière de fuite de mémoire etc.
Là, je vois pas trop dans le code. Je vois des pertes de performances potentielles, mais pas de fuites mémoires avec l'utilisation de vector, et certainement moins qu'avec des pointeurs, surtout pour des gens venant de Java.
-- Loïc
boutkhourst.hassan
Fabien LE LEZ wrote in message news:...
On 6 Feb 2005 13:20:19 -0800, (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
fu2 sur fr.comp.lang.c++
merci
Fabien LE LEZ <gramster@gramster.com> wrote in message news:<7p2d0110urjsimv15eg262j5sd6mpcr1l2@4ax.com>...
On 6 Feb 2005 13:20:19 -0800, boutkhourst.hassan@gmail.com (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture
*v [20][/cpp]
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture *v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
fu2 sur fr.comp.lang.c++
merci
kanze
Alex wrote:
Fabien LE LEZ wrote:
On 6 Feb 2005 13:20:19 -0800, (hollan):
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture
*v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé...
Conseillé, c'est un peu faible.
Même si la STL est standard on peut toujours déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une extension.
Le C++ est plus qu'une extension de C. C'est un autre langage. Or, si c'est vrai que la plupart des outils C s'y trouvent, il y en a bien d'autres aussi. Ne pas utiliser l'outil qui convient, c'est une erreur. (Il y a des cas où des tableaux de type C conviennent, mais ici n'en est pas un.)
Souvent c'est même dangereux de se laisser aller dans les tendances de représenter tout en objet,
Qu'entends-tu par « objet » ? Dans la norme, vector<int> et int[] déclare tous les deux des objets. Dans sa signification « orienté objet », ni vector<int> ni int[] sont des objets. Je ne vois pas la distinction que tu cherches à faire ici.
je passe un sacré temps à corriger les horibles constructions et copies de données comme ceci par exemple f(std::vector<vector<...> > vect) ou le vect est const et & suffisait. Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Si on ne connaît pas le langage, on va faire des erreurs. Mais l'erreur des Javaistes, ça ne serait pas plutôt à utiliser des pointeurs à outrance, et de ne jamais copier quoique ce soit ?
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la performance en général.
Ça dépend, mais surtout, si on prend « objet » dans le sens « orienté objet », ça mène à l'autre extrème -- n'utiliser que des pointeurs, quand une passe par valeur conviendrait.
Sans parler derrière de fuite de mémoire etc.
Où ? Là aussi, c'est plutôt l'utilisation des pointeurs qui mène à des fuites de mémoire. Tant que je copie des valeurs, aucune risque.
-- 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
Alex wrote:
Fabien LE LEZ wrote:
On 6 Feb 2005 13:20:19 -0800, boutkhourst.hassan@gmail.com
(hollan):
normalement l ai pensé a un tableau de pointeur, de type
[cpp]voiture
*v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé...
Conseillé, c'est un peu faible.
Même si la STL est standard on peut toujours déclarer un
tableau de pointeurs, un **, un n'importe quoi. Non
utilisation de STL ne te pousse pas en dehors du C++, même si
c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++
est une extension.
Le C++ est plus qu'une extension de C. C'est un autre langage.
Or, si c'est vrai que la plupart des outils C s'y trouvent, il y
en a bien d'autres aussi. Ne pas utiliser l'outil qui convient,
c'est une erreur. (Il y a des cas où des tableaux de type C
conviennent, mais ici n'en est pas un.)
Souvent c'est même dangereux de se laisser aller dans les
tendances de représenter tout en objet,
Qu'entends-tu par « objet » ? Dans la norme, vector<int> et
int[] déclare tous les deux des objets. Dans sa signification
« orienté objet », ni vector<int> ni int[] sont des objets. Je
ne vois pas la distinction que tu cherches à faire ici.
je passe un sacré temps à corriger les horibles constructions
et copies de données comme ceci par exemple
f(std::vector<vector<...> > vect) ou le vect est const et &
suffisait. Souvent c'est très répandu chez ceux ayant Java
comme premier langage.
Si on ne connaît pas le langage, on va faire des erreurs. Mais
l'erreur des Javaistes, ça ne serait pas plutôt à utiliser des
pointeurs à outrance, et de ne jamais copier quoique ce soit ?
Aucun souci de pointeur, références etc. tout ce qui a un
impact fort sur la performance en général.
Ça dépend, mais surtout, si on prend « objet » dans le sens
« orienté objet », ça mène à l'autre extrème -- n'utiliser que
des pointeurs, quand une passe par valeur conviendrait.
Sans parler derrière de fuite de mémoire etc.
Où ? Là aussi, c'est plutôt l'utilisation des pointeurs qui mène
à des fuites de mémoire. Tant que je copie des valeurs, aucune
risque.
--
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
normalement l ai pensé a un tableau de pointeur, de type [cpp]voiture
*v [20][/cpp]
Ça, c'est l'écriture C.
std::vector <voiture*> mon_tableau_de_voitures;
C'est ce qui est conseillé...
Conseillé, c'est un peu faible.
Même si la STL est standard on peut toujours déclarer un tableau de pointeurs, un **, un n'importe quoi. Non utilisation de STL ne te pousse pas en dehors du C++, même si c'est le bon style, c'est bien, machin truc etc...
Toutes les structures et syntagmes du C sont accessibles, c++ est une extension.
Le C++ est plus qu'une extension de C. C'est un autre langage. Or, si c'est vrai que la plupart des outils C s'y trouvent, il y en a bien d'autres aussi. Ne pas utiliser l'outil qui convient, c'est une erreur. (Il y a des cas où des tableaux de type C conviennent, mais ici n'en est pas un.)
Souvent c'est même dangereux de se laisser aller dans les tendances de représenter tout en objet,
Qu'entends-tu par « objet » ? Dans la norme, vector<int> et int[] déclare tous les deux des objets. Dans sa signification « orienté objet », ni vector<int> ni int[] sont des objets. Je ne vois pas la distinction que tu cherches à faire ici.
je passe un sacré temps à corriger les horibles constructions et copies de données comme ceci par exemple f(std::vector<vector<...> > vect) ou le vect est const et & suffisait. Souvent c'est très répandu chez ceux ayant Java comme premier langage.
Si on ne connaît pas le langage, on va faire des erreurs. Mais l'erreur des Javaistes, ça ne serait pas plutôt à utiliser des pointeurs à outrance, et de ne jamais copier quoique ce soit ?
Aucun souci de pointeur, références etc. tout ce qui a un impact fort sur la performance en général.
Ça dépend, mais surtout, si on prend « objet » dans le sens « orienté objet », ça mène à l'autre extrème -- n'utiliser que des pointeurs, quand une passe par valeur conviendrait.
Sans parler derrière de fuite de mémoire etc.
Où ? Là aussi, c'est plutôt l'utilisation des pointeurs qui mène à des fuites de mémoire. Tant que je copie des valeurs, aucune risque.
-- 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
Fabien LE LEZ
On Tue, 08 Feb 2005 00:00:57 +0100, Alex :
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20 pointeurs de voiture
20, seulement, réellement ?
il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres modifications de taille, même quand dans trois ans il se servira du code en question pour autre chose ? Peut-il garantir que la taille sera toujours fixée à la compilation ? Si oui, effectivement, les tableaux à la C sont une solution possible.
-- ;-)
On Tue, 08 Feb 2005 00:00:57 +0100, Alex <no@email.adresse>:
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20
pointeurs de voiture
20, seulement, réellement ?
il n'y aurait peut-être jamais d'insertion ni
d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres
modifications de taille, même quand dans trois ans il se servira du
code en question pour autre chose ? Peut-il garantir que la taille
sera toujours fixée à la compilation ?
Si oui, effectivement, les tableaux à la C sont une solution possible.
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20 pointeurs de voiture
20, seulement, réellement ?
il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres modifications de taille, même quand dans trois ans il se servira du code en question pour autre chose ? Peut-il garantir que la taille sera toujours fixée à la compilation ? Si oui, effectivement, les tableaux à la C sont une solution possible.
-- ;-)
Olivier Azeau
Fabien LE LEZ wrote:
On Tue, 08 Feb 2005 00:00:57 +0100, Alex :
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20
pointeurs de voiture
20, seulement, réellement ?
Oui, c'est pour un parking qui n'a que 20 places de stationnement.
il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres modifications de taille, même quand dans trois ans il se servira du code en question pour autre chose ? Peut-il garantir que la taille sera toujours fixée à la compilation ?
Et peut-il garantir que les voitures ne devront pas etre triées par taille dans la structure de stockage ? et identifiée par leur plaque d'immatriculation toujours dans la meme structure ?
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Si oui, effectivement, les tableaux à la C sont une solution possible.
Mais pas forcément souhaitable si l'on veut pouvoir relire ce que l'on écrit. 'std::vector' est quand meme plus parlant et lisible qu'un tableau C.
Fabien LE LEZ wrote:
On Tue, 08 Feb 2005 00:00:57 +0100, Alex <no@email.adresse>:
dans l'exemple d'au-dessus il était peut-être à déclarer un
tableau de 20
pointeurs de voiture
20, seulement, réellement ?
Oui, c'est pour un parking qui n'a que 20 places de stationnement.
il n'y aurait peut-être jamais d'insertion ni
d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres
modifications de taille, même quand dans trois ans il se servira du
code en question pour autre chose ? Peut-il garantir que la taille
sera toujours fixée à la compilation ?
Et peut-il garantir que les voitures ne devront pas etre triées par
taille dans la structure de stockage ? et identifiée par leur plaque
d'immatriculation toujours dans la meme structure ?
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Si oui, effectivement, les tableaux à la C sont une solution
possible.
Mais pas forcément souhaitable si l'on veut pouvoir relire ce que l'on
écrit.
'std::vector' est quand meme plus parlant et lisible qu'un tableau C.
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20
pointeurs de voiture
20, seulement, réellement ?
Oui, c'est pour un parking qui n'a que 20 places de stationnement.
il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres modifications de taille, même quand dans trois ans il se servira du code en question pour autre chose ? Peut-il garantir que la taille sera toujours fixée à la compilation ?
Et peut-il garantir que les voitures ne devront pas etre triées par taille dans la structure de stockage ? et identifiée par leur plaque d'immatriculation toujours dans la meme structure ?
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Si oui, effectivement, les tableaux à la C sont une solution possible.
Mais pas forcément souhaitable si l'on veut pouvoir relire ce que l'on écrit. 'std::vector' est quand meme plus parlant et lisible qu'un tableau C.
Fabien LE LEZ
On 8 Feb 2005 06:00:06 -0800, "Olivier Azeau" :
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
On compare ici deux solutions de complexité à peu près égale, "std::vector<Machin*> x" et "Machin* x[20]". J'ai tendance, dans ce cas, à choisir la solution la plus facilement extensible.
Si maintenant on a le choix entre une solution simple mais figée et une solution extensible mais compliquée, le problème n'est plus du tout le même.
Note aussi que je préfère faire un typedef plutôt qu'utiliser std::vector<> directement, i.e. typedef std::vector<Truc> TableauTrucs; TableauTrucs table; à la place de typedef std::vector<Truc> table;
ce qui me permet de décider, après coup, que std::list<> serait plus adapté. Cela ne m'empêche pas d'utiliser les spécificités de vector<>, mais alors le choix se fait au moment où je sais que j'ai effectivement besoin d'un vector<> et pas autre chose, au lieu de faire un choix a priori.
Les deux exemples suivent la même logique : ne pas hésiter à permettre l'extensibilité si l'augmentation de complexité est négligeable.
-- ;-)
On 8 Feb 2005 06:00:06 -0800, "Olivier Azeau" <ransom@xasamail.com>:
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
On compare ici deux solutions de complexité à peu près égale,
"std::vector<Machin*> x" et "Machin* x[20]". J'ai tendance, dans ce
cas, à choisir la solution la plus facilement extensible.
Si maintenant on a le choix entre une solution simple mais figée et
une solution extensible mais compliquée, le problème n'est plus du
tout le même.
Note aussi que je préfère faire un typedef plutôt qu'utiliser
std::vector<> directement, i.e.
typedef std::vector<Truc> TableauTrucs;
TableauTrucs table;
à la place de
typedef std::vector<Truc> table;
ce qui me permet de décider, après coup, que std::list<> serait plus
adapté.
Cela ne m'empêche pas d'utiliser les spécificités de vector<>, mais
alors le choix se fait au moment où je sais que j'ai effectivement
besoin d'un vector<> et pas autre chose, au lieu de faire un choix a
priori.
Les deux exemples suivent la même logique : ne pas hésiter à permettre
l'extensibilité si l'augmentation de complexité est négligeable.
On compare ici deux solutions de complexité à peu près égale, "std::vector<Machin*> x" et "Machin* x[20]". J'ai tendance, dans ce cas, à choisir la solution la plus facilement extensible.
Si maintenant on a le choix entre une solution simple mais figée et une solution extensible mais compliquée, le problème n'est plus du tout le même.
Note aussi que je préfère faire un typedef plutôt qu'utiliser std::vector<> directement, i.e. typedef std::vector<Truc> TableauTrucs; TableauTrucs table; à la place de typedef std::vector<Truc> table;
ce qui me permet de décider, après coup, que std::list<> serait plus adapté. Cela ne m'empêche pas d'utiliser les spécificités de vector<>, mais alors le choix se fait au moment où je sais que j'ai effectivement besoin d'un vector<> et pas autre chose, au lieu de faire un choix a priori.
Les deux exemples suivent la même logique : ne pas hésiter à permettre l'extensibilité si l'augmentation de complexité est négligeable.
-- ;-)
kanze
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Tue, 08 Feb 2005 00:00:57 +0100, Alex :
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20 pointeurs de voiture
20, seulement, réellement ?
Oui, c'est pour un parking qui n'a que 20 places de stationnement.
Qui serait agrandi dans trois semaines ? Et évidemment, dès que ça marche avec le parking A, on va l'utiliser pour le parking B (qui lui a 150 places).
Le nombre de place dans un parking, c'est le genre de chose qu'on met typiquement dans un fichier de configuration.
il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres modifications de taille, même quand dans trois ans il se servira du code en question pour autre chose ? Peut-il garantir que la taille sera toujours fixée à la compilation ?
Et peut-il garantir que les voitures ne devront pas etre triées par taille dans la structure de stockage ? et identifiée par leur plaque d'immatriculation toujours dans la meme structure ?
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Je suis d'accord avec les principes qui sont présenté là. Dans ce cas-ci, en revanche :
-- Moi, je n'ajoute pas de généricité ; le code générique est déjà là. Alors, autant s'en servir.
-- Il faut appliquer la règle avec un peu de bon sens, quand même. Dans un autre thread, j'ai parlé de l'importance d'une connaissance métier. Ici, il ne faut pas un énorme connaissance du métier pour se douter que changer le nombre de place serait une modification probable à l'avenir. (En général, quelque soit le métier, tout ce qui est valeur numérique est bon candidat -- les valeurs numériques ne resistent guère à l'épreuve du temps.)
Si oui, effectivement, les tableaux à la C sont une solution possible.
Les tableaux à la C sont toujours une solution possible. Il ne s'agit pas d'implémenter n'importe quelle solution possible. (Vingt variables distinctes avec un switch pour y accéder est aussi une solution possible.)
Mais pas forcément souhaitable si l'on veut pouvoir relire ce que l'on écrit. 'std::vector' est quand meme plus parlant et lisible qu'un tableau C.
Ça se discute. Je trouve quelque chose comme : double a[ 10 ][ 20 ] ; bien plus lisible que : std::vector< std::vector< double > > a( 10, std::vector< double >( 20 ) ) ;
Le problème principal avec les tableaux à la C, c'est qu'il se converissent en pointeur à tout instant ; ils sont des objets « deuxième classe ». Il y a des fois où les autres avantages sont plus important (possibilité d'initialisation statique, par exemple), mais sinon, il vaut mieux les éviter.
-- 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
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Tue, 08 Feb 2005 00:00:57 +0100, Alex <no@email.adresse>:
dans l'exemple d'au-dessus il était peut-être à déclarer un
tableau de 20 pointeurs de voiture
20, seulement, réellement ?
Oui, c'est pour un parking qui n'a que 20 places de
stationnement.
Qui serait agrandi dans trois semaines ? Et évidemment, dès que
ça marche avec le parking A, on va l'utiliser pour le parking B
(qui lui a 150 places).
Le nombre de place dans un parking, c'est le genre de chose
qu'on met typiquement dans un fichier de configuration.
il n'y aurait peut-être jamais d'insertion ni
d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou
autres modifications de taille, même quand dans trois ans il
se servira du code en question pour autre chose ? Peut-il
garantir que la taille sera toujours fixée à la compilation
?
Et peut-il garantir que les voitures ne devront pas etre
triées par taille dans la structure de stockage ? et
identifiée par leur plaque d'immatriculation toujours dans la
meme structure ?
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Je suis d'accord avec les principes qui sont présenté là. Dans
ce cas-ci, en revanche :
-- Moi, je n'ajoute pas de généricité ; le code générique est
déjà là. Alors, autant s'en servir.
-- Il faut appliquer la règle avec un peu de bon sens, quand
même. Dans un autre thread, j'ai parlé de l'importance d'une
connaissance métier. Ici, il ne faut pas un énorme
connaissance du métier pour se douter que changer le nombre
de place serait une modification probable à l'avenir. (En
général, quelque soit le métier, tout ce qui est valeur
numérique est bon candidat -- les valeurs numériques ne
resistent guère à l'épreuve du temps.)
Si oui, effectivement, les tableaux à la C sont une solution
possible.
Les tableaux à la C sont toujours une solution possible. Il ne
s'agit pas d'implémenter n'importe quelle solution possible.
(Vingt variables distinctes avec un switch pour y accéder est
aussi une solution possible.)
Mais pas forcément souhaitable si l'on veut pouvoir relire ce
que l'on écrit. 'std::vector' est quand meme plus parlant et
lisible qu'un tableau C.
Ça se discute. Je trouve quelque chose comme :
double a[ 10 ][ 20 ] ;
bien plus lisible que :
std::vector< std::vector< double > >
a( 10, std::vector< double >( 20 ) ) ;
Le problème principal avec les tableaux à la C, c'est qu'il se
converissent en pointeur à tout instant ; ils sont des objets
« deuxième classe ». Il y a des fois où les autres avantages
sont plus important (possibilité d'initialisation statique, par
exemple), mais sinon, il vaut mieux les éviter.
--
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
dans l'exemple d'au-dessus il était peut-être à déclarer un tableau de 20 pointeurs de voiture
20, seulement, réellement ?
Oui, c'est pour un parking qui n'a que 20 places de stationnement.
Qui serait agrandi dans trois semaines ? Et évidemment, dès que ça marche avec le parking A, on va l'utiliser pour le parking B (qui lui a 150 places).
Le nombre de place dans un parking, c'est le genre de chose qu'on met typiquement dans un fichier de configuration.
il n'y aurait peut-être jamais d'insertion ni d'autres opérations liées au vecteur,
Peut-il garantir qu'il n'y aura _jamais_ d'insertions ou autres modifications de taille, même quand dans trois ans il se servira du code en question pour autre chose ? Peut-il garantir que la taille sera toujours fixée à la compilation ?
Et peut-il garantir que les voitures ne devront pas etre triées par taille dans la structure de stockage ? et identifiée par leur plaque d'immatriculation toujours dans la meme structure ?
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Je suis d'accord avec les principes qui sont présenté là. Dans ce cas-ci, en revanche :
-- Moi, je n'ajoute pas de généricité ; le code générique est déjà là. Alors, autant s'en servir.
-- Il faut appliquer la règle avec un peu de bon sens, quand même. Dans un autre thread, j'ai parlé de l'importance d'une connaissance métier. Ici, il ne faut pas un énorme connaissance du métier pour se douter que changer le nombre de place serait une modification probable à l'avenir. (En général, quelque soit le métier, tout ce qui est valeur numérique est bon candidat -- les valeurs numériques ne resistent guère à l'épreuve du temps.)
Si oui, effectivement, les tableaux à la C sont une solution possible.
Les tableaux à la C sont toujours une solution possible. Il ne s'agit pas d'implémenter n'importe quelle solution possible. (Vingt variables distinctes avec un switch pour y accéder est aussi une solution possible.)
Mais pas forcément souhaitable si l'on veut pouvoir relire ce que l'on écrit. 'std::vector' est quand meme plus parlant et lisible qu'un tableau C.
Ça se discute. Je trouve quelque chose comme : double a[ 10 ][ 20 ] ; bien plus lisible que : std::vector< std::vector< double > > a( 10, std::vector< double >( 20 ) ) ;
Le problème principal avec les tableaux à la C, c'est qu'il se converissent en pointeur à tout instant ; ils sont des objets « deuxième classe ». Il y a des fois où les autres avantages sont plus important (possibilité d'initialisation statique, par exemple), mais sinon, il vaut mieux les éviter.
-- 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
