NumberedObject dérive de RefCounted numberObjectSet.copy(nobj) au profit de numberObjectSet.add(nobj). Le nombre de ref est incrémenté à chaque fois que le pointeur est copié et décrémenté à chauqe fois que le pointeur est relaché.safeCopy est remplacé par safeAddrefCounted et conservés doivent dorénavant être alloués (à l'aide de new). Sans quoi ils vont être détruits à l'insu du plein gré du programmateur …getClone et ensuite de l'ajout au setDISOWN. La gestion mémoire de ces objets a été remplacée par l'utilisateion de incRef, decRef dans les .i (voir commit du 8 Avril). Objets en question : mtALE::AleMethodmtALE::PostStepmtFEM::ValueExtractormtFEMBase::ElementPropertiesmtGeo::AxemtMath::FunctionBaseincRef & decRef dans les fonctions où cela devient nécessaireValuesManagerValuesManager était pour le moins pas claire : les vecteurs étaient alloués dans le ValuesManager, pointeur stoqués à la fois dans le DataVectorSet de Metafor et dans chaque ValuesStruct et objets détruits par le DataVectorSetDataVectorSet de Metafor (double stoquage inutile)ValuesManager devient une std::map<UserNo,ValuesStruct*>VectorOnFile dans le ValuesManagerValuesStructValuesManager.getDataVector(no) pour créer des courbes dans l'interface python.DataCurveSet de Metafor (jamais utilisé)les libs (LibsVs2005_080509.rar sur le ftp de Romain) et juste l'“exe” dans le même repertoire (stp2e_080509.rar)…
ValuesManager (le numéro de l'extracteur) est stoqué à la fois dans le valuesManager & dans le vectorOnFile (pas fait déjà trop de modifs en cours)set par objets de la STLA R
— Luc PAPELEUX 2008/05/14