Typage statique et fonction

Version imprimable

Voir 40 message(s) de cette discussion en une page

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:

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

04/06/2013, 17h28
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.
04/06/2013, 17h28
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 (?) ?)
05/06/2013, 07h51
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.
05/06/2013, 09h30
ternel

Alors, tes fonctions doivent retourner des pointeurs alloués, probablement via des shared_ptr ou unique_ptr (cf boost ou C++11)
05/06/2013, 09h41
qlt654

Citation:

Envoyé par leternel

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
05/06/2013, 10h37
therwald

Citation:

Envoyé par qlt654

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é!).
05/06/2013, 11h18
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 ?
05/06/2013, 11h55
Ehonn

Citation:

Envoyé par therwald

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).

Citation:

Envoyé par 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 ?

Ç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.

Citation:

Envoyé par qlt654

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:

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:

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'.

05/06/2013, 12h12
therwald

Citation:

Envoyé par Ehonn

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!
05/06/2013, 12h31
Ehonn

Citation:

Envoyé par therwald

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.
05/06/2013, 14h09
qlt654

Citation:

Envoyé par therwald

À 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

Citation:

Envoyé par therwald

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

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

Citation:

Envoyé par therwald

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é.

Citation:

Envoyé par Ehonn

Ç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 !
05/06/2013, 14h24
therwald

Citation:

Envoyé par qlt654

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...
05/06/2013, 14h26
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.
05/06/2013, 14h26
therwald

Citation:

Envoyé par Ehonn

Ç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...

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:

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;
}

05/06/2013, 15h34
qlt654

Citation:

Envoyé par therwald

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.

Citation:

Envoyé par Ehonn

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
05/06/2013, 16h51
Ehonn

Citation:

Envoyé par qlt654

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 ?
05/06/2013, 17h09
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 :D) 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 :D

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 :aie:) 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.

Voir 40 message(s) de cette discussion en une page