/* Topic des codeurs couche-tard [1] */

helly · Le 29/07/2010, à 18:04

Ha ouais j'y avais pas pensé !
Merci

helly · Le 29/07/2010, à 18:10

Mais ça ne règle pas tout à fait le truc qui me bloquait ! (zut >_<)
Paske en fait dans le truc que je veux faire, j'ai un vector < vector < Unites > > .
Et le truc c'est que je veux pouvoir rajouter une Unité en x,y sans forcément que x-1,y-1 soient déjà occupés ! Donc push_back marche pas ici vu qu'il rajoute dans la première place de libre…

En gros (si j'ai pas été claire) pour reprendre l'exemple que j'ai donné ici, push_back marche bien si je veux remplir toutes les cases de ligne unes par unes, mais si je ne veux remplir que les cases 1,5,9 ?
Jpeux pas avec push_back

Bon, j'ai trouvé une magouille pour contourner… mais j'aimerai bien avoir la solution quand même, pour l'avenir

Dernière modification par helly (Le 29/07/2010, à 18:17)

grim7reaper · Le 29/07/2010, à 18:19

helly a écrit :

Jpeux pas avec push_back

Non, mais avec insert tu devrais y arriver .

Dernière modification par grim7reaper (Le 30/07/2010, à 00:12)

helly · Le 29/07/2010, à 18:20

/me va voir le man et je te dis ça

grim7reaper · Le 29/07/2010, à 18:23

Arf, ou pas en fait.
Insert fait vraiment de l'insertion en agrandissant le tableau. Je crois que j'ai mal compris ta demande et que j'ai répondu trop vite…
Je vais continuer à chercher.

Et tout bếtement un truc du genre (à la C, ça doit être possible avec la magie de la surcharge des opérateurs).

line[x][y] = unite;

ça ne fonctionne pas ?

À la limite, si la taille de ta matrice ne varie pas tu peux utiliser des tableaux à la C (si la taille ne varie pas après la création).
Ou sinon, tu jetes un œil du côté de boost::multi_array qui est fait pour ça.

Dernière modification par grim7reaper (Le 29/07/2010, à 18:32)

helly · Le 29/07/2010, à 18:49

ça ne fonctionne pas ?

Ça renvoie une belle erreur de segmentation
Ce qui est plutôt évident en fait vu que le vector n'a pas été agrandi à la taille suffisante
(/me va dodoter un coup et revenir là dessus ce soir, ça doit bien être faisable quand même via les vectors ! )

grim7reaper · Le 29/07/2010, à 18:53

Qu'entends tu par "alloué" ?
La case est forcément alloué, sinon elle n'existe pas.
Si tu veux dire vide, alors non je ne pense pas. Il faut que tu définisses une "valeur" qui signifie vide et que les cases inocuppé ait cette valeur.

Raah, tu as édité .

helly a écrit :

ça ne fonctionne pas ?
Ça renvoie une belle erreur de segmentation
Ce qui est plutôt évident en fait vu que le vector n'a pas été agrandi à la taille suffisante

T'a la place dispo ou pas ?
Si tu as la place ça fonctionne (ou alors tu fait un truc bizarre), si tu n'a pas la place faut y aller avec insert.

Cela dit, insérer au milieu d'un tableau ça pue niveau performance (décalage, tout ça). Donc si tu as beaucoup d'insertion il vaut mieux utiliser une liste, mais après tu perds le bénéfice de l'accès direct.
À toi de voir (revoir ?) ton algo.

helly · Le 29/07/2010, à 19:53

Cela dit, insérer au milieu d'un tableau ça pue niveau performance

Ouais jme doute bien
Mais c'est bon, j'ai trouvé une feinte

grim7reaper · Le 29/07/2010, à 20:02

helly a écrit :

Mais c'est bon, j'ai trouvé une feinte

Du genre ?

Au fait, c'est quoi le rôle de ta matrice (un genre de carte je suppose) ?

helly · Le 29/07/2010, à 20:05

Ouais c'était pour le TD, une map contenant les défenses positionnées.
Mais finalement ça sera plus simple (et meilleur côté mémoire je pense) de remplacer cette map 2D par juste un vecteur 1D, et finalement les positions des défenses, au lieu de les trouver via la map, elles seront incluses dans la classe des Defenses !
(c'est clair ? )

grim7reaper · Le 29/07/2010, à 20:11

Oui, je vois le truc .

Faudra que je me remette dessus moi (enfin, sur le truc qui ressemble vaguement à un toolkit) parce que là ça fait 3 jours que j'y ai pas touché (mais bon je suis sûr autre chose là, un truc en Java *frisson*.).

Dernière modification par grim7reaper (Le 29/07/2010, à 20:12)

helly · Le 29/07/2010, à 20:13

Bha moi je gratte pas mal, mais je retombe toujours à zéro paske je trouve une autre technique meilleure
Ce soir encore

helly · Le 29/07/2010, à 20:16

Pour une matrice 2D dont la dimension varie pas, c'est plus correct de faire un **int ou un vector < vector <int> > ?

bloublou · Le 29/07/2010, à 20:35

int tab[A][b];

grim7reaper · Le 29/07/2010, à 20:36

helly a écrit :

Pour une matrice 2D dont la dimension varie pas, c'est plus correct de faire un **int ou un vector < vector <int> > ?

Le plus correct je ne sais pas. Mais le vector fait plus C++, et comme c'est la lib standard autant s'en servir.
De plus, tu bénéficieras du contenu de <algorithm>. Il me semble que tu ne pourras pas en bénificier avec un int**.

louiz' a écrit :

int tab[A][b];

Un tableau dont la taille ne varie pas n'est pas nécessairement un tableau dont la taille est connue à la compilation.

Dernière modification par grim7reaper (Le 29/07/2010, à 20:39)

helly · Le 29/07/2010, à 20:36

@Louiz : Ça je sais
La question c'est, lequel est le plus correct !

@grim : ouais bon bha en attendant un autre avis, va pour un vector 2D

Dernière modification par helly (Le 29/07/2010, à 20:37)

\\Ouranos// · Le 29/07/2010, à 21:32

xapantu · Le 29/07/2010, à 21:45

helly a écrit :

La question c'est, lequel est le plus correct !

Et au niveau des performances ? il y a des différences ?

grim7reaper · Le 29/07/2010, à 22:06

Oui, inévitablement mais c'est quasi imperceptible.
Pour moi, la lègère perte de vitesse est largement compensé par les avantages des vectors. Bon après, il faut voir au cas par cas, mais a priori je suggère d'utiliser les vector.
C'est plus ou moins le même débat que std::string vs char*.

Utiliser int** va peut-être, je dis bien peut-être, faire gagner un peu de vitesse d'exécution. Mais combien de temps perdu à debugger, traquer les fuites de mémoire et autres joyeusetés propres aux pointeurs ?

Dernière modification par grim7reaper (Le 29/07/2010, à 22:11)

\\Ouranos// · Le 29/07/2010, à 22:12

cm-t · Le 29/07/2010, à 22:33

Re&'Nuit;

helly · Le 29/07/2010, à 22:40

Utiliser int** va peut-être, je dis bien peut-être, faire gagner un peu de vitesse d'exécution. Mais combien de temps perdu à debugger, traquer les fuites de mémoire et autres joyeusetés propres aux pointeurs ?

Ouais !
Puis ça fait peu de temps que j'ai découvert les vectors, mais je trouve ça vachement simple à manipuler

xapantu · Le 29/07/2010, à 23:03

@grim7reaper et helly : ok merci, dans un programme que j'avais (tenté ) fait, j'avais opté pour les vector, ça me semblait plus simple que les pointeurs (vu mon niveau aussi ).

Dernière modification par xapantu (Le 29/07/2010, à 23:03)

grim7reaper · Le 29/07/2010, à 23:07

Oui, c'est carrément plus simple (c'est le but en même temps ).
Parce qu'avec les pointeurs, même en ayant l'habitude, on n'est jamais à l'abri d'une fausse manip'.

compte supprimé · Le 29/07/2010, à 23:45

Tiens, un TD en Python ! Ca peut être sympa
(Comment ça je bosse déjà sur un MUD, un bot foireux et un mastermind en console ?)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1651 Le 29/07/2010, à 18:04

Re : /* Topic des codeurs couche-tard [1] */

#1652 Le 29/07/2010, à 18:10

Re : /* Topic des codeurs couche-tard [1] */

#1653 Le 29/07/2010, à 18:19

Re : /* Topic des codeurs couche-tard [1] */

#1654 Le 29/07/2010, à 18:20

Re : /* Topic des codeurs couche-tard [1] */

#1655 Le 29/07/2010, à 18:23

Re : /* Topic des codeurs couche-tard [1] */

#1656 Le 29/07/2010, à 18:49

Re : /* Topic des codeurs couche-tard [1] */

#1657 Le 29/07/2010, à 18:53

Re : /* Topic des codeurs couche-tard [1] */

#1658 Le 29/07/2010, à 19:53

Re : /* Topic des codeurs couche-tard [1] */

#1659 Le 29/07/2010, à 20:02

Re : /* Topic des codeurs couche-tard [1] */

#1660 Le 29/07/2010, à 20:05

Re : /* Topic des codeurs couche-tard [1] */

#1661 Le 29/07/2010, à 20:11

Re : /* Topic des codeurs couche-tard [1] */

#1662 Le 29/07/2010, à 20:13

Re : /* Topic des codeurs couche-tard [1] */

#1663 Le 29/07/2010, à 20:16

Re : /* Topic des codeurs couche-tard [1] */

#1664 Le 29/07/2010, à 20:35

Re : /* Topic des codeurs couche-tard [1] */

#1665 Le 29/07/2010, à 20:36

Re : /* Topic des codeurs couche-tard [1] */

#1666 Le 29/07/2010, à 20:36

Re : /* Topic des codeurs couche-tard [1] */

#1667 Le 29/07/2010, à 21:32

Re : /* Topic des codeurs couche-tard [1] */

#1668 Le 29/07/2010, à 21:45

Re : /* Topic des codeurs couche-tard [1] */

#1669 Le 29/07/2010, à 22:06

Re : /* Topic des codeurs couche-tard [1] */

#1670 Le 29/07/2010, à 22:12

Re : /* Topic des codeurs couche-tard [1] */

#1671 Le 29/07/2010, à 22:33

Re : /* Topic des codeurs couche-tard [1] */

#1672 Le 29/07/2010, à 22:40

Re : /* Topic des codeurs couche-tard [1] */

#1673 Le 29/07/2010, à 23:03

Re : /* Topic des codeurs couche-tard [1] */

#1674 Le 29/07/2010, à 23:07

Re : /* Topic des codeurs couche-tard [1] */

#1675 Le 29/07/2010, à 23:45

Re : /* Topic des codeurs couche-tard [1] */

Pied de page des forums