La chose qui me pose problème est l'attribut brickColl_ de Ball qui est un pointeur vers l'objet brick. Cet attribut pointe vers la prochaine brick avec laquelle la balle va collisionner et est update à chaque instant t dans updateDt(). Cependant là ets le problème, après avoir update, j'essaye de visualiser la prochaine brick avec laquelle la balle va entrer en collision mais j'obtiens une segmentation fault, signe que j'accède à une zone mémoire non allouée. Je ne comprends malheureusement pas pourquoi ce pointeur brickColl_ serait vide ou alors mal initialisé. Si vous avez des pistes je suis preneur
Avec le code que tu donnes, un premier moyen pour que brickColl_ soit invalide dans un object Ball valide, c'est si tu appelles setBrick avec une valeur invalide. C'est facile de vérifier avec un assert dans setBrick.
Plus généralement, tu as un gros problème de non vérification des contrats de tes fonctions. Ajoute des asserts, pour garantir ces contrats (par exemple brickColl_ non null, position non negative, etc.)
(Hors sujet : ca manque aussi beaucoup de const)
Je sais pas a quoi sert setBrick, mais potentiellement, peut etre que Ball devrait avoir l'ownership de brickColl_ et donc que tu devrais utiliser un unique_ptr.
Une autre possibilité, c'est que ton setBrick affecte un objet valide, mais que celui-ci n'est plus valide ensuite. Si c'est le cas, ca montre un probleme plus general d'ownership (qui est propriétaire des objets Brick ?).
Une autre possibilité que je vois, c'est que c'est l'objet Ball lui même qui devient invalide. (Et donc que brickColl_ est invalidé en même temps, mais que l'erreur n'apparaît que pour brickColl_ et pas Ball).
Il faut lancer en mode debug et voir la call stack et les valeurs des variables lors du crash.
Donc globalement, un problème de qualité du code concernant la validité de tes pointeurs. Et une conception assez étrange ! Pourquoi Brick est copiable ? (tres clairement, c'est une sémantique d'entité). Pourquoi Ball contient une Brick ? Pourquoi Ball est chargé de calcul la future collision avec Brick ?
La ligne 211 est un excellent candidat à la segfault.
La recette pointeurs bruts (/nus) + copie oubliée est une excellente source de problèmes.
donc =>
- abandonne définitivement les pointeurs bruts. unique_ptr exclusivement, cela t’obligera à réfléchir aux responsabilités.
- arrête de passer tes paramètres par valeur, ça duplique les objets -> références constantes
- A propos le constructeur de copie de Brick est excessivement louche, vu qu'un champs est overridé, alors qu'il est ensuité affiché depuis une fonction qui prend une copie de la brique. Ca n'a pas de sens.
- (EDIT) sécurise les copies d'objets qui ont des pointeurs
- A propos les constructeurs des briques devraient être factorisés (C++11!, sorti il y a 11ans)
- Si je comprends bien il s'agit d'un casse-briques. Et que la balle soit responsable d'une brique n'a aucun sens pour moi.
Plutôt que d’avoir plein d’objets éparpillés qui essaient péniblement de communiquer entre eux et où on sait pas qui fait quoi, pourquoi ne pas avoir une classe principale qui représente le niveau et qui gère la balle, les briques, les collisions, etc ?
C'est sûre que dans un casse-brick, les briques et la balle sont totalement indépendant, et n'en ont rien a cirer de que fait l'un et l'autre.
C'est clairement à une entité supérieur (le jeux) de décider qui fait quoi en fonction de la situation: - deplacer la balle. - Verifier les collisions. - Faire disparaitre une brique. - ect ect ...
Pointeur d'une classe vers une autre
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.