Re: Très rapide review

En fait il ne faut pas voir comment ta fonction est définie mais comment elle va être utilisée.

Si tu reviens au c, tu as deux solutions :

int a;
function1(a);
function2(&a);

Sans connaitre la définition des fonctions, tu sais (le langage te le garantie) que a ne sera pas modifier par function1. Je sais que je peut faire ce que je veux avec a après, je sais que je casserai rien.

Pour function2, tu sais pas. Ça peut être modifié, ou pas. Ça peut être stocké (pour lecture ou modification future) ou pas. Mais tu sais qu'il faut faire attention.

Si tu es en C++ et que ta as des références

int a;
function1(a);

Ben là... Mais le c++ ne garantie rien car function1 peut prendre une référence.
L'usage (le mien) voudrait que tu ais la garantie que a soit pas modifié. C'est pour ça que je déconseille très fortement la référence non constante. Le but est de garder la sémantique des passages d'argument du c.

Dans ton premier cas, la fonction sera utilisée de la sorte:

CastellumBox box1;
CastellumBox* p_box2 = new CastellumBox();
layer.addBrick(&box1);
layer.addBrick(p_box2);

C'est clair, tu attends une adresse parce que tu veux faire un truc avec. L'utilisateur doit faire attention à ce qu'il fait.

Dans ton deuxième cas :

CastellumBox box1;
CastellumBox* p_box2 = new CastellumBox();
layer.addBrick(box1);
layer.addBrick(*p_box2);

Là, c'est le drame. Tu "demandes" une valeur à l'utilisateur alors que justement tu veux une adresse. Donc : jamais de référence non constante comme argument de fonction. Reste avec un passage d'adresse.

À noter que dans ton cas, il ne faut pas utiliser les références constante non plus (même si tu ne modifie pas castellumBox).

class CastellumLayer{
 void addBrick(const CastellumBox& castellumBox);
 std::vector<const castellumBox*> _bricks;
};
void CastellumLayer::addBrick(const CastellumBox& castellumBox) {
 _bricks.push_back(&castellumBox);
 _bricks.sort(box_zindex_compare);
}

Ton code compile et tu ne modifie pas castellumBox mais tu stockes l’adresse pour l'utiliser plus tard. Tu casses le contrat (purement implicite) de la fonction vers le code appelant : "Fait ce que tu veux avec, moi j'en ai fini, je l'utilise plus".
Si tu fais un delete après l'appel de la fonction:

CastellumBox* p_box = new CastellumBox();
layer.addBrick(*p_box);
delete p_box;

Le code semble correcte, tu passes une valeur et tu supprime le contenant après utilisation, mais ton programme va se taper un segfault bien méchant (car pas obligatoirement tout de suite et au même endroit)

Avec un passage par adresse :

CastellumBox* p_box = new CastellumBox();
layer.addBrick(p_box);
delete p_box;

Rien ne t’empêche de faire l'erreur, mais c'est moins clean : tu passes le contenant et tu le supprimes après. Ça mais la puce à l'oreille.
Après on peut jouer avec les les smart pointer, shared_pointer et unique_ptr pour rajouter une sémantique de "propriété de l'objet" mais ça fait des posts trop long :)

Il reste un cas (le seul?), où le passage par recopie est nécessaire : Quand tu veux explicitement une copie de l'objet (pour la modifier ou la stocker sans interférer avec l'objet d'origine)

Matthieu Gautier|irc:starmad