Fonctionnement des pointeurs en C++

Bonjour, Je suis en train d’écrire une petite librairie de manipulation de vecteur et matrice, et je voulais avoir un comportement proche du GLSL, c’est-à-dire pouvoir récupérer mes composantes de vecteur par « bloc » (par exemple sur un vec3 v je peux faire v.xz() pour manipuler uniquement la première et la troisième coordonnées). Pour pouvoir ensuite assigner directement les composantes par bloc, j’ai utilisé dans mes classes non pas des flottants, mais des pointeurs (sur des flottants). Cela donne pour vec2 (j’omets l’en-tête qui n’a rien d’intéressant) :

#include "math/vec2.hpp"



Vec2::Vec2(void) : m_x(new float(0)), m_y(new float(0)) {}

Vec2::Vec2(float x, float y) : m_x(new float(x)), m_y(new float(y)) {}

Vec2::Vec2(float* x, float* y) : m_x(x), m_y(y) {}

Vec2::~Vec2(void) {
    delete m_x;
    delete m_y;

    m_x = nullptr;
    m_y = nullptr;
}


float& Vec2::x(void) {
    return *m_x;
}

float& Vec2::y(void) {
    return *m_y;
}


std::ostream& Vec2::display(std::ostream& os) const {
    os << "(" << *m_x << " ; " << *m_y << ")";

    return os;
}


std::ostream& operator<<(std::ostream& os, const Vec2& vec) {
    return vec.display(os);
}

J’ai ensuite réalisé quelques tests :

#include <iostream>


#include "math/vec2.hpp"


int main(int, char**) {
    Vec2 v1 = Vec2(1.2, 2);

    {
        Vec2 v2 = Vec2(&(v1.x()), &(v1.y()));

        std::cout << "v1 = " << v1 << std::endl;
        std::cout << "v2 = " << v2 << std::endl;

        // Modifier l'un revient à modifier l'autre
        v2.y() = 3.141592;

        std::cout << "v1 = " << v1 << std::endl;
        std::cout << "v2 = " << v2 << std::endl;

        // Les composantes ont la même adresse
        std::cout << "@v1.x = " << &(v1.x()) << std::endl << "@v2.x = " << &(v2.x()) << std::endl;
    }
    
    std::cout << "v1 = " << v1 << std::endl;

    return 0;
}

Et là je m’attendais à avoir une erreur de segmentation, en effet la variable v2 à la fin du scope est détruite, donc son destructeur est appelé, ce qui détruit aussi les deux composantes m_x et m_y, tout du moins je pensais que c’est ce qui se passerait. Mais le vecteur v1 s’affiche correctement. Je me questionne donc sur le fonctionnement du new et du delete en C++ dans ce contexte, et est-ce qu’il y a un risque que la variable v1 puisse avoir un comportement indéterminé au fur et à mesure du code après une telle opération (comme si la place des composantes en mémoire pouvait être réallouée pour autre chose) ? Dans le cas ou ce ne serait pas le cas, j’aimerais savoir si cette façon de fonctionner des objets vec est bonne ou si il y aurait une meilleure alternative ?

Je vous remercie d’avance pour vos réponses.

Merci pour votre réponse, j’ai tenté de passer le programme dans un sanitizer comme vous le suggériez, cela m’a permis de me rendre compte qu’effectivement le comportement du programme n’est pas normal. À l’origine, sous Windows, en apparence le vecteur v1 de mon précédent exemple semble s’en sortir après la destruction de v2, mais sous Linux (en WSL) ce n’est déjà plus le cas. Comme je compile avec gcc et g++ sous Windows, je n’ai pas réussi à passer le paramètre -fsanitize qui n’est, après recherche, pas supporté sous Windows. Je suis donc passé sous WSL et le sanitizer me montre bien une erreur d’accès à la mémoire.

Merci pour votre explication, cependant je crains ne pas avoir le niveau pour tout comprendre, notamment ce que sont les vues et responsables, auriez-vous une référence (fr ou en) où je pourrais me renseigner là-dessus ? Si je comprends bien, les vues sont liées aux objets vec<T> et les responsables aux vec<T&>, ce qui me donne une certaine intuition de ce que sont les vues et responsables.

Avec cet enchevêtrement de types et de références, je me demande si ce n’est pas trop compliqué de vouloir imiter le comportement du GLSL plutôt que d’avoir des fonctions plus classiques comme setXZ(float x, float z), et peut-être laisser un accès direct uniquement pour chaque composante seule. Pour un exercice de programmation cela peut être intéressant, mais je comptais intégrer ces classes dans un projet plus gros, j’ai peur que ce ne soit pas pratique à terme notamment pour le debugage (d’autant qu’il va falloir que je revois tout mon code, le nombre de référence se compte sur les doigts de la main, alors que les pointeurs… ).

Le GLSL doit certainement résoudre ses accès par groupes de composantes lors de la compilation, est-ce qu’une extension du langage serait une potentielle solution ? Je ne compte pas m’engager là-dedans, mais je me pose la question par curiosité.

Mon projet est effectivement complètement en C++ (hormis la SDL et gl3w), je l’ai globalement mis en pause avec la reprise des cours, mais je passerai sur un ou deux tutos revoir tout ça avant de reprendre.

Je n’ai pas tant de new et de delete que ça dedans, c’est surtout que je passe beaucoup d’objets par pointeur plutôt que par référence. J’avais déjà prévu de revoir la totalité du code, quand j’ai commencé à coder, je cherchais surtout à avoir un truc fonctionnel rapidement et je n’étais plus trop dans le C++ (notamment j’avais oublié l’existence des références). Mais c’est vrai que j’ai été étonné plus d’une fois de ne pas avoir d’erreur de mémoire, mais je sais maintenant que certains soucis nécessite un sanitizer pour être détectés. Je recompilerai le tout sur ma Debian pour vérifier ça.

Pour les classes vec, j’ai surtout voulu testé rapidement de coder sous Visual Studio (alors que j’étais sous vim et notepad++), et je me suis dit que ça pourrait être intéressant d’imiter glsl, mais en soit, ce sera des calculs de matrice pour la 3D, il y a peu de chances de devoir agir sur certaines composantes et pas d’autres. Ce qui m’a amené à poster c’est surtout le comportement du programme de test, je pensais avoir une erreur à l’exécution et au final, j’ai eu un comportement en apparence correct. Cela m’a aussi permis de confirmer que la structure initiale des classes était mauvaise.