Je pense que c'est un effet de bord. Soit la segfault paraît lors de l'appel aux sous-fonctions dans ton switch (gdb + bt roulaizent), soit c'est ton tableau de parameters qui est mal déclaré. En admettant que ta macro MAX_EQ_PARAMETERS ne puisse pas être définie pour une raison ou une autre (ex: oubli du #include idoine), ta déclaration sera alors résolue en
double parameters[];
Ce qui reste correct d'un point de vue syntaxique, mais qui définit un pointeur sans la mémoire qui va derrière. Cela suffirait à expliquer tes segfaults intermittentes : Lorsque tu écriras dans ce tableau, tes données n'iront pas se loger dans un endroit prévu à cet effet mais dans l'espace réservé aux variables membres que tu définis plus loin ! Donc, tu as la place de semer la pagaille un bon moment avant de planter. En fait, ton programme pourra continuer à faire le con tant qu'il ne sortira pas du segment de mémoire alloué pour ta classe entière, lequel segment aura probablement une taille alignée sur une page quelquonque. Ceci pourrait expliquer les différences de plantage en fonction des plateformes.
[^] # Re: Autre suggestion
Posté par Obsidian . En réponse au message problème d'acces à une méthode. Évalué à 2.
double parameters[];
Ce qui reste correct d'un point de vue syntaxique, mais qui définit un pointeur sans la mémoire qui va derrière. Cela suffirait à expliquer tes segfaults intermittentes : Lorsque tu écriras dans ce tableau, tes données n'iront pas se loger dans un endroit prévu à cet effet mais dans l'espace réservé aux variables membres que tu définis plus loin ! Donc, tu as la place de semer la pagaille un bon moment avant de planter. En fait, ton programme pourra continuer à faire le con tant qu'il ne sortira pas du segment de mémoire alloué pour ta classe entière, lequel segment aura probablement une taille alignée sur une page quelquonque. Ceci pourrait expliquer les différences de plantage en fonction des plateformes.