Bonjour à tous,
 
Je développe depuis peu sous Ubuntu en C++. Je réalise un moteur 3D en raytracing avec photonmapping et ça marchait très bien sous windows.
Le passage sous linux m'a forcé à me séparer de quelques bibliothèques très pratiques que je dois reprogrammer, en particulier la gestion des matrices.
 
Le programme fonctionnait très bien jusqu'à maintenant. En le lancant, j'ai une erreur que je n'avais pas avant (sous Ubuntu), je ne sais pas pourquoi ça me le fait maintenant mais je connais avec gdb la ligne de code où ça plante et je ne comprends pas l'origine.
 
Le message d'erreur est le suivant : Program received signal SIGABRT, Aborted.
Cette ligne est précédée de pas mal de valeurs mais peu de texte.
 
Voici le code de la fonction à problème :
Cmatrix
Cmatrix::operator *(const Cmatrix &mat) const
{
 if (mNumCol!=mat.mNumRow)
  return Cmatrix(0, 0);
 
 int r, c, d;
 Cmatrix res(mNumRow, mat.mNumCol);
 
 for (r=0; r<res.mNumRow; r++)
  for (c=0; c<res.mNumCol; c++)
  {
   res[r][c] = 0.0;
 
   for (d=0; d<mNumCol; d++)
    res[r][c] += (*this)[r][d] * mat[d][c];
  }
 
 
 double w = res[res.mNumRow-1][res.mNumCol-1];
 
 if (w!=0.0 && w!=1.0)
  for (r=0; r<res.mNumRow; r++)
   for (c=0; c<res.mNumCol; c++)
    res[r][c] /= w;
 
 return res;
}
 
et ça plante à la dernière ligne : }
j'appelle la fonction ainsi : Vertex = Scale*Vertex;
 
Je me demande si je n'ai pas désinstallé involontairement une bibliothèque en supprimant des logiciels que j'essayais
Vous avez des pistes?

on espère tous pour toi que tu utilises std::vector<double>

Non, les variables membres de ma classe Cmatrix sont :
double *mData;
int mNumRow;
int mNumCol;
 
mData est un tableau à 1 dimension et j'accède aux données avec ces opérateurs :
double* operator [](int i) { return mData + i*mNumCol; }
const double* operator [](int i) const { return mData + i*mNumCol; }
 
Les matrices étant utilisées plusieurs millions de fois, je me passe de la classe vector pour augmenter la rapidité des calculs (j'ai fait des tests).

bah tu veux jouer au grand, alors assume. Sors ton debugger et bon courage.

edit: nan en fait les grands utilisent les multiarray de boost.

au fait, superbe exemple d'optimisation prématurée d'un truc ne fonctionnant même pas.

Merci Taz pour tes messages très constructifs...
Ca marchait très bien sous Windows et purify ne me trouvais aucune erreur ni warning, aucun dépassement de mémoire.
Et franchement, je ne vois pas du tout ce que vector apporterais dans ce cas.
Quelqu'un d'autre pour donner un avis constructif?

passer le debugger et vérifier les valeurs des variables en jeu ?

Oui, c'est la première chose que j'ai faite.
j'ai bien vérifié que les index n'allaient pas au dela des tableaux.
L'erreur se produit vraiment à la fin de la fonction, après même le return.

donc lors de la liberation de mémoire...

Ok, voici mon constructeur et destructeur :
 
Cmatrix::Cmatrix(int numRow, int numCol)
{
 mNumRow = 0;
 mNumCol = 0;
 mData = NULL;
 
 if (numRow>0 && numCol>0)
 {
  mNumRow = numRow;
  mNumCol = numCol;
  mData = new double[numRow*numCol];
  memset(mData, 0, sizeof(double)*numRow*numCol);
 }
}
 
 
Cmatrix::~Cmatrix()
{
 if (mData!=NULL)
  delete [] mData;
}
 
Entre temps, j'essaie de passer par des matrices à dimensions fixes (4x4 et 4x1) car je n'utilise que des matrice de transformation et des vecteurs.
Si je trouve la raison plus tard, après m'être familiarisé avec les outils de debugage de linux, je ne manquerais pas de donner son origine et sa solution (si j'en trouve une).

un tel code est complètement baisé ...

et donc utilise std::vector<> ou ouvre un livre

Je suis finalement repassé à des matrices de dimensions fixes et ça marche mieux.
J'ai ré-essayé avec vector mais les temps de calculs explosent, je préfère donc m'en passer tant que c'est possible.
Pour ceux que ça intéresse, voici quelques images générées par mon moteur  : http://s.a.partage.free.fr/raytracing.html

Boost::array n'a pas la lenteur de vector; donc si tes tableaux sont finalement fixes, ça vaut sans doute le coup d'y jeter un oeil.

Merci IrmatDen. Je pense rester sur des matrices à dimensions fixes pour ce cas là mais j'étudierai ça pour mes futurs développements.

Aucune raison. La différence est d'une seule indirection. Ton problème est ailleurs.