[Résolu] Une classe Group héritant de Drawable

[L01man]

EDIT : une page sur le wiki a été créée.

Je pense qu'il manque un dernier enfant à Drawable pour que la famille soit complète. Dans d'autres frameworks, comme Pygame ou Pyglet, j'ai récemment remarqué que cette classe était déjà implémentée. Avant, j'avais vite trouvé le besoin de la créer, et je pense qu'à partir d'un certain niveau d'abstraction tout le monde en a besoin.

Code: [Sélectionner]

#ifndef GROUP_INCLUDED_HPP
#define GROUP_INCLUDED_HPP

#include "Drawable.hpp"

class Group : public sf::Drawable, public std::vector<sf::Drawable*> {
public:
Group();
~Group();

void render(sf::RenderTarget&) const;
};

#endif

Code: [Sélectionner]

#include "group.hpp"

Group::Group() :
sf::Drawable(),
std::vector<sf::Drawable*>() {
}
Group::~Group() {
for(std::vector<sf::Drawable*>::iterator i = begin(); i != end(); ++i) {
delete *i;
}
}

void Group::render(sf::RenderTarget& Tar) const {
for(std::vector<sf::Drawable*>::iterator i = begin(); i != end(); ++i) {
Tar.draw(*i);
}
}

[Laurent]

Ouaip, sauf qu'il y a un choix à faire quant à l'ownership des éléments, et que ce choix sera certainement différent pour chacun. Et comme la moitié du code de la classe concerne ce truc, ça ne servirait à rien d'en fournir une version officielle qui de toute façon ne satisfera jamais à 100% les gens.

[L01man]

Excuse-moi, que veux-tu dire par "ownership des éléments" ?

[Laurent]

Qui prend la responsabilité de les détruire.

[lezebulon]

Ca serait pas plus cool d'hériter de std::vector<std::unique_ptr<sf::Drawable*>> et du coup pas de prise de tête d'ownership? (et de destructeur)

[Nexus]

Je pense que hériter de std::vector est une mauvaise idée en général. Il serait mieux de garder std::vector comme membre et d'offrir quelques méthodes pour l'accès (si nécessaire).

Et lezebulon, tu veux dire std::unique_ptr<sf::Drawable> sans étoile

[Laurent]

Ca serait pas plus cool d'hériter de std::vector<std::unique_ptr<sf::Drawable*>> et du coup pas de prise de tête d'ownership? (et de destructeur)

Mon point n'était pas technique mais conceptuel : parfois tu voudras que le groupe prenne l'ownership des éléments, et parfois au contraire tu voudras simplement qu'il stocke des pointeurs vers des objets gérés ailleurs. On ne peut pas trancher définitivement.

[L01man]

Ah, le problème est donc Group::~Group(). Dans ce cas, on peut ajouter une variable "hasOwnership" qui détermine si, à sa destruction, le groupe détruit ses items ou non.

[Laurent]

Et peut-être que quelqu'un voudra des responsabilités partagés, et donc utiliser des std::shared_ptr dans sa classe Group.

On peut toujours trouver des solutions techniques qui semblent résoudre le problème immédiat, mais si on prend du recul ça ne marche pas. Comme je l'ai déjà dit c'est un problème de conception, ça ne sert à rien d'ajouter des booléens ou autre.

[L01man]

Je vois. Pourtant, dans Pygame & cie., cette classe est bien présente et semble convenir à tous ! A vrai dire, les cas de figure qui seraient problématiques ne me viennent pas à l'esprit. On devrait les énumérer pour voir si une solution est possible. Par exemple, rendre Group abstraite pour que chacun l'implémente comme il veut ou fournir plusieurs Group qui couvrent toutes les utilisations.
En ce qui me concerne, je vois trois utilisations :

• mettre ensemble les backgrounds, les tirs, ou les tiles ou autres éléments pour des calculs de collision sur leur ensemble par exemple ;
• créer des couches pour l'ordre d'affichage ;
• créer un objet complexe composé de parties articulées - des Sprite par exemple -, qui sont positionnées à partir des coordonnées de ce Group.

Dans le premier cas, le Group est sensé n'être détruit qu'à la fin du programme. Dans le deuxième, aussi. Dans le troisième, le Group est bien considéré comme un objet et pas comme un "tiroir", et ses éléments lui appartiennent. Donc, pour tous ces cas, il est normal que le Group détienne l'ownership.
On peut aussi très bien copier l'adresse d'un élément vers un autre endroit et faire un erase() pour que le Group n'ait plus cet ownership.

[Laurent]

Pourtant, dans Pygame & cie., cette classe est bien présente et semble convenir à tous !

Python est un langage interprété qui possède un ramasse-miettes, il n'y a pas notion explicite d'ownership pour le programmeur.

Par exemple, rendre Group abstraite pour que chacun l'implémente comme il veut

Ca n'avancerait pas beaucoup les gens dans ce cas, ça ne ferait que leur imposer une interface figée.

ou fournir plusieurs Group qui couvrent toutes les utilisations.

Plusieurs variantes d'une classe pour une seule fonctionnalité bien spécifique, ça ferait un peu bourrin pour SFML

[L01man]

D'accord x). Pourrait-on au moins en proposer une version dans les tutoriels, afin que les débutants aient une base ?

[Laurent]

Pas dans les tutoriels non, mais mets-en une sur le wiki si tu veux

[L01man]

C'est fait.

[Laurent]

Pourquoi est-ce que personne ne lit jamais les règles avant de créer des pages sur le wiki ? C'est vraiment pénible

Sinon :
- tu devrais indiquer que ton code est pour SFML 1.6
-- pourquoi ne pas le faire en 2.0 ? plus personne n'utilisera 1.6 bientôt
- le code de ton destructeur a trop de lignes de code pour ce qu'il fait