Pfff... Le graphe est supposé être une structure dynamique donc alloué dans le tas. Franchement, un graphe alloué sur la pile, c'est un graphe dont on connait exactement la structure à la compilation, ça limite son intérêt...
Toi tu es resté à l'époque du C ;) tu peux très bien faire du char a[plop.size()]; (bon je ne recommande pas non plus, un vector est généralement plus indiqué ;)
Quand je code en c++, je fais très peu de new (et de delete associé), et je trouve que forcer les gens à réfléchir lorsqu'il font le new à la visibilité de l'objet en question, de sa durée de vie, et de la pertinence du new est une excellente chose, et dans le cas où le new est pertinent, voir si un conteneur est utile (shared_ptr, uniq_ptr...)
De plus, je persiste à penser qu'avoir un destructeur qui est appelé de manière prédictible est une excellente chose (fermeture de ficher, connexion, trace...)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: la réponse est évidente
Posté par fearan . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Toi tu es resté à l'époque du C ;) tu peux très bien faire du char a[plop.size()]; (bon je ne recommande pas non plus, un vector est généralement plus indiqué ;)
Quand je code en c++, je fais très peu de new (et de delete associé), et je trouve que forcer les gens à réfléchir lorsqu'il font le new à la visibilité de l'objet en question, de sa durée de vie, et de la pertinence du new est une excellente chose, et dans le cas où le new est pertinent, voir si un conteneur est utile (shared_ptr, uniq_ptr...)
De plus, je persiste à penser qu'avoir un destructeur qui est appelé de manière prédictible est une excellente chose (fermeture de ficher, connexion, trace...)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent