size_t
qui est beaucoup plus propre.pragma
). En effet, si j'avais pas désactivé les warnings relatifs à la perte de données par conversion implicite, j'aurais trouvé le bug tout de suite. J'ai donc réactivé certains warnings et j'ai modifié le code problématique. J'ai supprimé les pragma relatifs aux warnings VC6. Normalement, le code compile presque sans warnings en “level 3” (il en reste juste dans les fichiers wrap
générés par SWIG).int
restera codée sur 32 bits (plutôt 31 vu le bit de signe) en 64 bits. L'idéal est donc d'indexer ses tableaux avec des entiers non signés pouvant balayer toute la mémoire physique des systèmes d'exploitation 64 bits. L'idéal semble d'utiliser le type size_t
au lieu du int
. Toutes les fonctions size()
ont été corrigées dans ce sens. En pratique, ça veut dire qu'une boucle sur un vecteur qui s'écrivait for(int i=0; i<v.size(); ++i)
s'écrit for(size_t i; i<v.size(); ++i)
ou, encore 100x mieux for(std::vector::iterator it=v.begin(); it!=v.end(); ++it)
. Dans ce dernier cas, on ne se tracasse plus des types! Pour vous prouver que je ne suis pas le seul à me tracasser de ce problème, python 2.5 a introduit le type Py_ssize_t
pour les tableaux (ce type n'existe pas en 2.4). J'ai modifié Metafor en conséquence mais le code compile toujours avec python 2.4.ElementIterator
pour le vs2005. Il doit dériver obligatoirement de std::iterator
ou std::iterator_traits
pour pouvoir être compatible avec les algorithmes de la STL. A ce propos, l'itérateur actuel ne boucle pas sur les éléments non actifs. C'est pour cela que la boucle toDofSet
n'utilise pas les itérateurs (si c'était le cas, certains éléments, désactivés dès le démarrage, ne sont jamais initialisés. L'idéal serait d'utiliser toujours les itérateurs et de vérifier leur initialisation à l'activation (ce n'a pas été fait).metafor.lic
) n'est pas trouvé! (ça aurait évité un premier plantage Metafor au premier lancement chez GDTech).— Romain BOMAN 2007/03/08 08:43