Discussion :

[qlt654]

Bonjour à tous,

Je bloque actuellement sur un problème de typage :

Dans une première fonction j'instancie un ObjetA, et je renvoie un pointeur de type InterfaceObjetA, qui point sur cet objet.
Le type dynamique de la valeur de retour est donc un InterfaceObjetA, et son type statique un ObjetA

Cependant, dans le programme appelant, le pointeur retourné à perdu son type statique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
IObjetA* builder(...) {
    ObjetA instance(...);
    IObjetA *pInstance = &instance;
    cout << typeid(*pInstance).name() << endl;  // renvoie => ObjectA
    return pInstance;
}
 
int main() {
    IObjetA *pointeur;
    pointeur = builder(...);
    cout << typeid(*pointeur).name() << endl; // renvoie => IObjetA
}

Est-ce dû à une erreur d'écriture de ma part ou dois-je trouver un autre moyen de créer mes objets
(je précise, pour mon application je n'ai pas le droit d'utiliser d'allocation dynamique)

Merci d'avance de votre aide

[PilloBuenaGente]

Bonjour,

A la fin de la fonction "Builder", l'"ObjectA" est détruit.

Sans allocation dynamique, dans ce cas, "ObjectA" devra être déclaré dans le main, ou une classe/structure prévue pour.

[Ehonn]

Bonjour

instance est détruit à la fin de la fonction builder. Tu peux donc te poser la question «sur quoi pointe le pointeur qui est retournée par la fonction ?»

(Peut-être que tu pourrais détailler ce que tu veux faire (pour que l'on puisse t'aider plus))
(Pourquoi as-tu besoin du polymorphisme d'inclusion (?) ?)

[qlt654]

Je dispose d'une famille d'objet (Interface, classe abstraite, classes concrètes) et je voudrais en créer une fabrique pour permettre l'utilisation de cette famille, sans avoir besoin de connaitre directement les classes concrètes, mais en accédant juste à l'interface.

[ternel]

Alors, tes fonctions doivent retourner des pointeurs alloués, probablement via des shared_ptr ou unique_ptr (cf boost ou C++11)

[qlt654]

Alors, tes fonctions doivent retourner des pointeurs alloués, probablement via des shared_ptr ou unique_ptr (cf boost ou C++11)

Ne s'agit-il pas d'allocation dynamique ? Si oui je ne peux pas utiliser cette solution

[therwald]

Ne s'agit-il pas d'allocation dynamique ? Si oui je ne peux pas utiliser cette solution

Ta fabrique est bien censée renvoyer un objet distinct à chaque appel? Dans ce cas, si tu veux du polymorphisme, tu n'as pas d'autre choix que de faire de l'allocation dynamique.
En effet, sois tu renvoies un pointeur -> pour renvoyer à chaque appel un nouvel objet il faut une allocation dynamique
Sois tu renvoies un objet par copie -> dans ce cas pas besoin d'allocation dynamique, mais pas de polymorphisme, puisque la copie va détruire le type dynamique (tu vois la relation) de l'objet initial, en créant une copie que sera forcément du type statique de retour de ta fonction (ce qu'on appelle du slicing)...
Si en revanche tu peux renvoyer le même objet à chaque appel, alors tu n'as qu'à en faire un membre de ta fabrique, et renvoyer un pointeur sur ce membre, en faisant attention à ce que ta fabrique continue d'exister au moins jusqu'à la dernière utilisation d'un pointeur (ou une référence) qu'elle a renvoyé (sinon ton pointeur sera invalide, et tu vas labourer la mémoire, avec un comportement imprévisible (résultats aberrants, plantage...olé!).

[qlt654]

Hm, c'est ce que je craignais.
Je ne peux pas stocker les objets à créer dans la fabrique (beaucoup trop d'objets). Je vais donc devoir renoncer à la fabrique, mon code perdra en évolutivité.

A moins qu'il existe un subterfuge ?

[Ehonn]

Dans ce cas, si tu veux du polymorphisme, tu n'as pas d'autre choix que de faire de l'allocation dynamique.

Attention au raccourci, il existe deux types de polymorphisme, d'inclusion et paramétrique (qui ne nécessite pas d'allocation dynamique).

Hm, c'est ce que je craignais.
Je ne peux pas stocker les objets à créer dans la fabrique (beaucoup trop d'objets). Je vais donc devoir renoncer à la fabrique, mon code perdra en évolutivité.

A moins qu'il existe un subterfuge ?

Ça dépend ce que tu veux faire avec ta factory mais tu peux peut-être astucieusement la remplacer par de la programmation générique. Il suffit que tes types offrent la même interface pour pouvoir les utiliser sans se soucier de leur vrai type.

[therwald]

Je ne peux pas stocker les objets à créer dans la fabrique (beaucoup trop d'objets).

À usage unique (genre variable locale)? Sinon, il faut bien qu'ils soient stockés quelque part...
Si tu t'interdis le new, pas trop de "trucs", non...si ce n'est que les smart pointers gèrent automatiquement la paire new/delete pour toi...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
std::unique_ptr<IObject> Factory::createIObject(...){
    return std::unique_ptr<Iobject> ref(new Object(...));
}
...

Ce qui donne côté appelant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void fonctionAppelantLaFactory(...){
    ...
    std::unique_ptr<IObject> myIobject=factory.createIObject(...);
    ...
    /*std::unique_ptr est détruit automatiquement en sortie de scope, et effectue le delete sur le pointeur à ce moment*/
}

Mais pour que ton objet vive assez longtemps pour être utilisé au retour de la fonction, il doit être alloué dynamiquement. Ceci dit, en utilisant un smart pointer (comme cela t'avait été suggéré) tu gère le principal inconvénient de l'allocation dynamique (pourquoi cette interdiction? question de contexte technique? règle interne?) à savoir le risque de fuite ou pire de 'dangling pointers'.

[therwald]

Attention au raccourci, il existe deux types de polymorphisme, d'inclusion et paramétrique (qui ne nécessite pas d'allocation dynamique).

Pour ce qui est de différencier type statique et effectif pour ne montrer qu'une interface, c'est du polymorphisme d'inclusion...ça semble être le sujet de la discussion ici.
Si l'unique intérêt de la fabrique est de centraliser en le dissimulant au reste du code les détails de construction de l'objet, il n'y a à la limite pas besoin de polymorphisme du tout...simplement réaliser l'initialisation de l'objet dans la factory et renvoyer une copie suffit...

EDIT: une copie avec type statique=type effectif, s'entend!

[Ehonn]

Pour ce qui est de différencier type statique et effectif pour ne montrer qu'une interface, c'est du polymorphisme d'inclusion...

Ça dépend de ce que tu appelles «une seule interface» mais je suis clairement en désaccord avec toi (car je pense qu'on ne veut pas différencier le type statique et dynamique, mais, que l'on veut avoir un comportement selon le type (mais qu'on se fiche de connaître type) (du polymorphisme en gros ^^)).

Par exemple lorsque tu utilises un std::accumulate pour moi il y a qu'une seule interface (pour l'utilisateur) est pourtant l'appel de la fonction est valide du moment que ton type définit l'opérateur d'affection et l'opérateur +.
On a donc différent type std::vector<int>, std::list<double>, float [] qui ont une interface commune :
- les containeurs peuvent être parcourus par des "input_iterator"
- le type contenu à un operateur = et +

Donc peut être que l'écriture d'une fonction générique suffit à résoudre le (vrai) problème ici.

[qlt654]

À usage unique (genre variable locale)? Sinon, il faut bien qu'ils soient stockés quelque part...

Usage unique en effet. Je pourrais stocker un Objet de chaque type dans la fabrique, et renvoyer un pointeur sur cet objet, mais le problème c'est que je ne serais dans ce cas pas en mesure de prouver que la valeur pointée n'a pas été re-modifiée avant son utilisation

pourquoi cette interdiction? question de contexte technique? règle interne?

Règle interne lié au contexte technique, et qui m’embête bien ...

Si l'unique intérêt de la fabrique est de centraliser en le dissimulant au reste du code les détails de construction de l'objet, il n'y a à la limite pas besoin de polymorphisme du tout...simplement réaliser l'initialisation de l'objet dans la factory et renvoyer une copie suffit...

Plus que la manière dont l'objet est créé, c'est son vrai type que j'aimerais caché.

Ça dépend ce que tu veux faire avec ta factory mais tu peux peut-être astucieusement la remplacer par de la programmation générique. Il suffit que tes types offrent la même interface pour pouvoir les utiliser sans se soucier de leur vrai type.

Je ne maitrise pas trop la programmation générique, mais je ne suis pas sûr que ça puisse s'appliquer à mon cas.


Je vais me renseigner sur la programmation générique, sinon je me passerais de fabrique. Merci de votre aide !

[therwald]

mais le problème c'est que je ne serais dans ce cas pas en mesure de prouver que la valeur pointée n'a pas été re-modifiée avant son utilisation

L'objet en question doit-il être modifiable par l'appelant? Sinon, avec une utilisation judicieuse de const...

[ternel]

Dans les cours sur le C++, nous en avons au moins un parlant de design patterns, tu devrais t'y intéresser de plus près.

Ils contiennent des exemples d'implémentations.

[therwald]

Ça dépend de ce que tu appelles «une seule interface» mais je suis clairement en désaccord avec toi (car je pense qu'on ne veut pas différencier le type statique et dynamique, mais, que l'on veut avoir un comportement selon le type (mais qu'on se fiche de connaître type) (du polymorphisme en gros ^^))

Tu parles en général, et moi du cas présent...d'où le désaccord...

[Ehonn]

Sinon, pour "réglé" ton souci, tu peux déclarer ta variable static dans la fonction. Selon l'importance / la propreté voulue du projet, ce hack pourrait convenir.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// g++ -Wall -Wextra -std=c++11 -pedantic main.cpp -o main && ./main
// g++ -Wall -Wextra -pedantic main.cpp -o main && ./main
 
#include <iostream>
#include <vector>
#include <list>
#include <algorithm>
#include <typeinfo>
 
 
struct IObjetA { virtual ~IObjetA() { } };
 
struct ObjetA : public IObjetA { };
 
IObjetA * create_builder()
{
	static ObjetA instance;
	IObjetA * pInstance = &instance;
	std::cout << typeid(*pInstance).name() << std::endl;  // renvoie => ObjectA
	return pInstance;
}
 
int main()
{
	IObjetA * pointeur = create_builder();
	std::cout << typeid(*pointeur).name() << std::endl; // renvoie => IObjetA
 
	return 0;
}

[qlt654]

L'objet en question doit-il être modifiable par l'appelant? Sinon, avec une utilisation judicieuse de const...

Non modifiable, mais programme multitâches. Il y a donc un risque qu'une tâche appelle la fabrique juste après une autre, modifiant ainsi la valeur pointée pour les deux.
J'ai en plus besoin d'une certaine persistance de l'instance (pour une durée inconnue) et d'avoir plusieurs instances du même type.

Sinon, pour "régler" ton souci, tu peux déclarer ta variable static dans la fonction. Selon l'importance / la propreté voulue du projet, ce hack pourrait convenir.

Même problème que plus haut

Je pense que ce que j'essaie de faire est juste impossible avec les contraintes que je me suis fixées. Je dois revoir l'objectif ou les contraintes.

Merci de votre aide

[Ehonn]

J'ai en plus besoin d'une certaine persistance de l'instance (pour une durée inconnue) et d'avoir plusieurs instances du même type.

Je n'arrive pas à voir le souci avec static :
- durée de vie = quasiment tout le programme
- plusieurs instances du même type = une fonction par instance voulue (ou utilisation de tableau)

Grosso modo, à part la propreté, qu'est-ce qui t'embête à utiliser des variables globales ?

[koala01]

Salut

Bon, d'abord, le principe de la fabrique est... de fabriquer des objets, ni plus, ni moins.

Cet objet, une fois créé, il faut bien qu'il soit "maintenu" quelque part.

Si tu le connais sous son type réel (par exemple : la classe Derivee hérite de la classe Base et tu connais ton objet de type Derivee comme étant ... du type Derivee), tu peux simplement renvoyer une valeur du type indiqué et travailler avec.

Si tu connais ton objet de type Derivee comme étant du type Base, tu devras renvoyer ton objet sous la forme d'une référence ou d'un pointeur pour profiter du polymorphisme, MAIS il faudra que ton objet existe au minimum jusqu'à la dernière utilisation de ton pointeur ou de ta référence!!!

Il y a donc trois solutions:

Soit, tu crées dans la fonction une variable statique que tu renvoyes sous forme de référence ou de pointeur, mais chaque appel à la fonction renverra la même donnée.

Soit tu créer une variable membre de la classe qui te permettra d'avoir plusieurs instances de l'objet, mais qui obligera la fabrique à exister au minimum jusqu'à la dernière utilisation du pointeur ou de la référence.

Soit enfin, tu crées ton objet de manière dynamique (avec new) et tu délègue "à autre chose" le soin de décider quand ton objet pourra être détruit.

Vu que tu veux travailler dans un contexte multitâches et que chaque tâche doit disposer de son objet propre, la première solution est, d'office, à rejeter.

Maintenant, il faut savoir que la différence, en terme d'utilisation de mémoire, entre la deuxième et la troisième solution sera minime : A partir du moment où ton objet est créé, il prendra d'office un espace mémoire clairement défini, seulement, la deuxième solution impliquera que tu devra placer ta fabrique dans une boucle (pour que chaque exécution, éventuellement threadée, puisse avoir son propre objet), avec comme résultat que, si tu effectue 50 fois la boucle, tu créeras... 50 fois la fabrique.

Il serait sans doute (très certainement ) dommage de devoir créer 50 fabriques différentes pour avoir 50 objets différents... Ce n'est pas le role que l'on attend de la part de la fabrique:

C'est un peu comme si une marque connue de voitures construisait une usine, construisait une seule voiture, démontait l'usine, et recommençait ce cinéma pour chaque voiture qu'elle doit construire!

Ca éviterait surement le chômage dans le bâtiment, mais ca ne serait pas forcément efficace

L'idée de la fabrique est donc : tu la crées une fois, puis, à chaque fois que tu as besoin d'un nouvel objet, tu le lui demandes.

Une fois qu'il a été créé, c'est à toi de savoir à quel moment il est "logique et opportun" de le détruire.

Cela implique généralement qu'il y a un nouvel acteur à mettre en place: un "gestionnaire" (bouh, je n'aime pas ce mot, mais c'est le meilleur que j'aie en stock ) qui va "recevoir" et "maintenir" tous les objets créés par la fabrique et qui, en fonction d'une logique qui lui est propre (cela pourrait très bien être un flag au niveau de l'objet) décidera du meilleur moment pour détruire les objets devenus inutiles.