Je suis en train d'impl=E9menter des carreaux de Bezier : =E0 peu de
chose pr=E8s, un entier n (le degr=E9) et un tableau de (n+1)*(n+2)/2
entr=E9es o=F9 stocker les "points de controle".
Bref, je me demandais s'il =E9tait pr=E9f=E9rable d'utiliser un type
vector ou un pointeur pour stocker mes points de controle... J'imagine
qu'il y a du plus comme du moins pour les deux solutions mais j'ai un
peu de mal =E0 =E9valuer tout =E7a. Pourrez vous m'aider ?
Ta question me paraît mal formulée. Le type "tableau" par défaut, en C++, est std::vector<>.
En d'autres termes, utilise std::vector<> sauf si tu as une bonne raison d'utiliser autre chose.
Même quand je dois implémenter un type particulier de tableau (par exemple, un mélange de vector<> et de map<>), la plupart du temps, en interne, c'est un vector<> qui s'occupe de contenir les données.
On 8 Aug 2005 06:21:25 -0700, "meow" <ben@agat.net>:
Quand utiliser la STL plutot qu'un tableau ?
Ta question me paraît mal formulée. Le type "tableau" par défaut, en
C++, est std::vector<>.
En d'autres termes, utilise std::vector<> sauf si tu as une bonne
raison d'utiliser autre chose.
Même quand je dois implémenter un type particulier de tableau (par
exemple, un mélange de vector<> et de map<>), la plupart du temps, en
interne, c'est un vector<> qui s'occupe de contenir les données.
Ta question me paraît mal formulée. Le type "tableau" par défaut, en C++, est std::vector<>.
En d'autres termes, utilise std::vector<> sauf si tu as une bonne raison d'utiliser autre chose.
Même quand je dois implémenter un type particulier de tableau (par exemple, un mélange de vector<> et de map<>), la plupart du temps, en interne, c'est un vector<> qui s'occupe de contenir les données.
meow
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un *Point plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
Ce que je voulais dire c'est :
est-ce qu'en stockant mes points de controle dans un *Point plutot que
dans un std::vector<Point> je gagne quelque chose ? En terme de
rapidité d'execution ou de mémoire ?
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un *Point plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
meow
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un Point* plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
Ce que je voulais dire c'est :
est-ce qu'en stockant mes points de controle dans un Point* plutot que
dans un std::vector<Point> je gagne quelque chose ? En terme de
rapidité d'execution ou de mémoire ?
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un Point* plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
adebaene
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un Point* plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
Le gain serait négligeable 99% du temps.
Comme toujours dans ces cas là, commences par faire un programme simple et correct, et *uniquement* s'il s'avère à l'usage qu'il y a un problème de performances, préoccupes-toi de : 1) Utiliser un profiler pour mesurer et identifier les portions de code qui posent un problème. 2) Micro-optimiser ses portions de code.
Les seules optimisations dont il faut se soucier en amont du codage, ce sont les optimisations d'algorithme (qui de toute façon ont généralement bien plus d'impact que les choix du type "vector VS tableau-à-la-C"
Arnaud
Ce que je voulais dire c'est :
est-ce qu'en stockant mes points de controle dans un Point* plutot que
dans un std::vector<Point> je gagne quelque chose ? En terme de
rapidité d'execution ou de mémoire ?
Le gain serait négligeable 99% du temps.
Comme toujours dans ces cas là, commences par faire un programme
simple et correct, et *uniquement* s'il s'avère à l'usage qu'il y a
un problème de performances, préoccupes-toi de :
1) Utiliser un profiler pour mesurer et identifier les portions de code
qui posent un problème.
2) Micro-optimiser ses portions de code.
Les seules optimisations dont il faut se soucier en amont du codage, ce
sont les optimisations d'algorithme (qui de toute façon ont
généralement bien plus d'impact que les choix du type "vector VS
tableau-à-la-C"
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un Point* plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
Le gain serait négligeable 99% du temps.
Comme toujours dans ces cas là, commences par faire un programme simple et correct, et *uniquement* s'il s'avère à l'usage qu'il y a un problème de performances, préoccupes-toi de : 1) Utiliser un profiler pour mesurer et identifier les portions de code qui posent un problème. 2) Micro-optimiser ses portions de code.
Les seules optimisations dont il faut se soucier en amont du codage, ce sont les optimisations d'algorithme (qui de toute façon ont généralement bien plus d'impact que les choix du type "vector VS tableau-à-la-C"
Arnaud
Bruno CAUSSE
dans l'article , à a écrit le 8/08/05 16:58 :
Les seules optimisations dont il faut se soucier en amont du codage, ce sont les optimisations d'algorithme (qui de toute façon ont généralement bien plus d'impact que les choix du type "vector VS tableau-à-la-C"
Hum...
Je suis debutant, alors je vais surement dire une conerie, mais les données d'un conteneur list vector.... sont stockés dans le tas (avec des new et delete transparents pour l'utilisateur). Donc si tu crée bcq d'objet "automatiques" contenant des conteneurs les perfs sont beaucoup moins bonnes.
dans l'article 1123513098.237043.296170@g44g2000cwa.googlegroups.com,
adebaene@club-internet.fr à adebaene@club-internet.fr a écrit le 8/08/05
16:58 :
Les seules optimisations dont il faut se soucier en amont du codage, ce
sont les optimisations d'algorithme (qui de toute façon ont
généralement bien plus d'impact que les choix du type "vector VS
tableau-à-la-C"
Hum...
Je suis debutant, alors je vais surement dire une conerie, mais les données
d'un conteneur list vector.... sont stockés dans le tas (avec des new et
delete transparents pour l'utilisateur). Donc si tu crée bcq d'objet
"automatiques" contenant des conteneurs les perfs sont beaucoup moins
bonnes.
Les seules optimisations dont il faut se soucier en amont du codage, ce sont les optimisations d'algorithme (qui de toute façon ont généralement bien plus d'impact que les choix du type "vector VS tableau-à-la-C"
Hum...
Je suis debutant, alors je vais surement dire une conerie, mais les données d'un conteneur list vector.... sont stockés dans le tas (avec des new et delete transparents pour l'utilisateur). Donc si tu crée bcq d'objet "automatiques" contenant des conteneurs les perfs sont beaucoup moins bonnes.
JBB
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un Point* plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
Tu peux aussi coder en assembleur pour gagner un peu de temps
d'execution et de mémoire. Mais le temps que tu vas passer en plus à coder et à debugger ton programme pour gagner 10 malheureux petits % en performances, et bien pendant ce temps là le PC moyen aura gagné en moyenne bien plus que ça.
Donc sauf si ton programme est destiné à être déployé sur des millions d'équipements sur lesquels augmenter la RAM revient du coup tres cher, ce ne sera pas rentable.
A l'heure actuelle 512 Mo de RAM coutent 50uros soit grosso-modo une heure-homme d'un ingénieur de SSI.
Apprends plutôt la STL ça te sera bien plus bénéfique.
Le seul intêret de faire autrement est à des fin pédagogique afin de comprendre le fonctionnement interne de la mémoire et se rendre compte par soi même tous les problemes que cela génère.
Ce que je voulais dire c'est :
est-ce qu'en stockant mes points de controle dans un Point* plutot que
dans un std::vector<Point> je gagne quelque chose ? En terme de
rapidité d'execution ou de mémoire ?
Tu peux aussi coder en assembleur pour gagner un peu de temps
d'execution et de mémoire.
Mais le temps que tu vas passer en plus à coder et à debugger ton
programme pour gagner 10 malheureux petits % en performances, et bien
pendant ce temps là le PC moyen aura gagné en moyenne bien plus que ça.
Donc sauf si ton programme est destiné à être déployé sur des millions
d'équipements sur lesquels augmenter la RAM revient du coup tres cher,
ce ne sera pas rentable.
A l'heure actuelle 512 Mo de RAM coutent 50uros soit grosso-modo une
heure-homme d'un ingénieur de SSI.
Apprends plutôt la STL ça te sera bien plus bénéfique.
Le seul intêret de faire autrement est à des fin pédagogique afin de
comprendre le fonctionnement interne de la mémoire et se rendre compte
par soi même tous les problemes que cela génère.
Ce que je voulais dire c'est : est-ce qu'en stockant mes points de controle dans un Point* plutot que dans un std::vector<Point> je gagne quelque chose ? En terme de rapidité d'execution ou de mémoire ?
Tu peux aussi coder en assembleur pour gagner un peu de temps
d'execution et de mémoire. Mais le temps que tu vas passer en plus à coder et à debugger ton programme pour gagner 10 malheureux petits % en performances, et bien pendant ce temps là le PC moyen aura gagné en moyenne bien plus que ça.
Donc sauf si ton programme est destiné à être déployé sur des millions d'équipements sur lesquels augmenter la RAM revient du coup tres cher, ce ne sera pas rentable.
A l'heure actuelle 512 Mo de RAM coutent 50uros soit grosso-modo une heure-homme d'un ingénieur de SSI.
Apprends plutôt la STL ça te sera bien plus bénéfique.
Le seul intêret de faire autrement est à des fin pédagogique afin de comprendre le fonctionnement interne de la mémoire et se rendre compte par soi même tous les problemes que cela génère.
Sauf bien sûr quand il vaut mieux faire autrement :-)
Si la taille du tableau est constante et connue à la compilation, un tableau à la C est aussi bien que vector<>. En pratique, on utilise vector<> quand même, car ça facilite l'évolution du code.
Il existe quand même un cas où le tableau à la C est utile (je crois que c'est le seul cas, mais je peux me tromper) : l'initialisation statique. static int const machin[]= { 13, 26, 99 };
On Mon, 08 Aug 2005 17:16:50 +0200, JBB <merci@pasdespam.fr>:
La réponse est donc : tout le temps.
Sauf bien sûr quand il vaut mieux faire autrement :-)
Si la taille du tableau est constante et connue à la compilation, un
tableau à la C est aussi bien que vector<>. En pratique, on utilise
vector<> quand même, car ça facilite l'évolution du code.
Il existe quand même un cas où le tableau à la C est utile (je crois
que c'est le seul cas, mais je peux me tromper) : l'initialisation
statique.
static int const machin[]= { 13, 26, 99 };
Sauf bien sûr quand il vaut mieux faire autrement :-)
Si la taille du tableau est constante et connue à la compilation, un tableau à la C est aussi bien que vector<>. En pratique, on utilise vector<> quand même, car ça facilite l'évolution du code.
Il existe quand même un cas où le tableau à la C est utile (je crois que c'est le seul cas, mais je peux me tromper) : l'initialisation statique. static int const machin[]= { 13, 26, 99 };
nico
Salut,
Quand utiliser la STL plutot qu'un tableau ? Réponse simple : tout le temps.
-- nico
Salut,
Quand utiliser la STL plutot qu'un tableau ?
Réponse simple : tout le temps.
Quand utiliser la STL plutot qu'un tableau ? Réponse simple : tout le temps.
-- nico
Arnaud Debaene
Bruno CAUSSE wrote:
dans l'article , à a écrit le 8/08/05 16:58 :
Les seules optimisations dont il faut se soucier en amont du codage, ce sont les optimisations d'algorithme (qui de toute façon ont généralement bien plus d'impact que les choix du type "vector VS tableau-à-la-C"
Hum...
Je suis debutant, alors je vais surement dire une conerie, mais les données d'un conteneur list vector.... sont stockés dans le tas (avec des new et delete transparents pour l'utilisateur). Donc si tu crée bcq d'objet "automatiques" contenant des conteneurs les perfs sont beaucoup moins bonnes.
Peut-être, et *si il s'avère que c'est un problème*, on en tiendra compte...
Si la taille du tableau est connue à la compilation (c'est rare, mais çà arrive), j'ai tendance à utiliser boost::array : je trouve que ca rend le code plus lisible, et çà a un surcout pour ainsi dire nul.
Anaud
Bruno CAUSSE wrote:
dans l'article 1123513098.237043.296170@g44g2000cwa.googlegroups.com,
adebaene@club-internet.fr à adebaene@club-internet.fr a écrit le
8/08/05 16:58 :
Les seules optimisations dont il faut se soucier en amont du codage,
ce sont les optimisations d'algorithme (qui de toute façon ont
généralement bien plus d'impact que les choix du type "vector VS
tableau-à-la-C"
Hum...
Je suis debutant, alors je vais surement dire une conerie, mais les
données d'un conteneur list vector.... sont stockés dans le tas (avec
des new et delete transparents pour l'utilisateur). Donc si tu crée
bcq d'objet "automatiques" contenant des conteneurs les perfs sont
beaucoup moins bonnes.
Peut-être, et *si il s'avère que c'est un problème*, on en tiendra compte...
Si la taille du tableau est connue à la compilation (c'est rare, mais çà
arrive), j'ai tendance à utiliser boost::array : je trouve que ca rend le
code plus lisible, et çà a un surcout pour ainsi dire nul.
Les seules optimisations dont il faut se soucier en amont du codage, ce sont les optimisations d'algorithme (qui de toute façon ont généralement bien plus d'impact que les choix du type "vector VS tableau-à-la-C"
Hum...
Je suis debutant, alors je vais surement dire une conerie, mais les données d'un conteneur list vector.... sont stockés dans le tas (avec des new et delete transparents pour l'utilisateur). Donc si tu crée bcq d'objet "automatiques" contenant des conteneurs les perfs sont beaucoup moins bonnes.
Peut-être, et *si il s'avère que c'est un problème*, on en tiendra compte...
Si la taille du tableau est connue à la compilation (c'est rare, mais çà arrive), j'ai tendance à utiliser boost::array : je trouve que ca rend le code plus lisible, et çà a un surcout pour ainsi dire nul.
