Typage statique et fonction

Version imprimable

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.
05/06/2013, 22h31
therwald

Citation:

Envoyé par qlt654

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.

Je ne comprends pas exactement ce que tu veux dire...si l'objet est non-modifiable (ce que tu pourrais assurer avec un type de retour du style const & Type) le problème des modifications concurrentes ne se pose pas. Concernant l'instanciation de l'instance, si elle est unique et que c'est une donnée membre de la fabrique comme te le suggère koala01, elle sera créée avant que la fonction puisse être appelée, donc pas de problème de concurrence d'appel à la fonction qui la renvoie (par référence const & IObjet dans ce cas).
La gestion de la durée d'existence est alors simple: tu crée la fabrique dans ta main, par exemple, puis tu la transmets par référence. Fin de main, sortie de scope, nettoyage automatique.
Si tu veux plusieurs instances parce que pramètres de construction différents, qu'est-ce qui t'interdit new + smart-pointer, exactement (pas plus coûteux en mémoire qu'une instance temporaire sur la pile...sauf que la pile est généralement plus petite que la heap) ?
06/06/2013, 00h21
JolyLoic

Généralement, pas d'allocation dynamique veut dire recherche d'un temps réel dur. Il y a des moyens pour contourner cette contrainte :
- Pendant la phase d'initialisation du ton programme, tu te moques souvent du temps réel, c'est pendant qu'il tourne que ça compte. Ne peux-tu pas créer dynamiquement tout ce dont tu as besoin pendant cette phase ?
- Variante du précédent, tu peux t'allouer des blocs de mémoire brute pendant cette phase, puis créer des objets dedans à la demande et en temps déterministe, car tu sais ce que tu fais dans ce bloc.
- Autre variante, quand la durée de vie de tes objets correspond bien à la durée d'exécution de tes fonction : Tu crées ces objets sur la pile
06/06/2013, 09h02
qlt654

Citation:

Envoyé par Ehonn

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

J'ai plusieurs thread qui vont avoir besoin de plusieurs objets du même type (mais différent). Le nombre d'objet n'est pas connu, la durée d'utilisation non plus.
Durant une exécution du programme, la fabrique créera plusieurs (dizaines de) milliers d'objets, pour 3types différents.

Citation:

Envoyé par koala01

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.

La fabrique existera jusqu'à la fin de la vie du programme.
Le problème c'est que je ne maitrise pas le nombre d'objet dont je pourrais avoir besoin.

Citation:

Envoyé par therwald

si l'objet est non-modifiable (ce que tu pourrais assurer avec un type de retour du style const & Type) le problème des modifications concurrentes ne se pose pas.

Si ma fabrique utilise un attribut A pour stocker l'objet fraichement créé, et qu'elle renvoie &A, même sans const l’utilisateur ne pourra pas le modifier (pas de setter publique).

Le problème c'est que si un autre (ou le même) utilisateur rappelle la fabrique pour créer un nouvel objet du même type,
- soit la fabrique restocke dans A l'objet nouvellement créé (et du coup modifie l'objet que le premier utilisateur avait récupéré avec &A)
- soit la fabrique possède une autre variable de stockage (dans ce cas il m'en faudrait des 10aine de millier)

Citation:

Envoyé par therwald

Si tu veux plusieurs instances parce que pramètres de construction différents, qu'est-ce qui t'interdit new + smart-pointer, exactement (pas plus coûteux en mémoire qu'une instance temporaire sur la pile...sauf que la pile est généralement plus petite que la heap) ?

Citation:

Envoyé par JolyLoic

Généralement, pas d'allocation dynamique veut dire recherche d'un temps réel dur.

Temps réel mou ici. Pour mon cas c'est une instruction que j'ai, relative à un éventuel besoin d'utiliser le programme sur un support avec une mémoire très limitée.
Je vais essayer d'avoir plus de précision sur les contours de cette restriction.
06/06/2013, 12h57
koala01

Citation:

Envoyé par qlt654

La fabrique existera jusqu'à la fin de la vie du programme.
Le problème c'est que je ne maitrise pas le nombre d'objet dont je pourrais avoir besoin.

Le nombre d'objet n'a absolument rien à faire dans l'histoire: ce qui importe, c'est de savoir quand chaque objet doit être détruit ;)

Que ton objet soit "maintenu" par la fabrique le temps que tu as besoin de l'objet ou que tu crées un tableau qui contient des pointeurs vers les différents objets (polymorphes) qui ont été créés, tu peux en avoir "autant que tu veux", cela ne posera aucun problème ;)

Par contre, pour éviter les fuites mémoire et les tentatives d'accès à un pointeur qui aurait été invalidé, ce qu'il faut impérativement, c'est savoir quand la mémoire allouée à l'objet doit être libérée ;)

Après, à partir du moment où tu as un objet par thread, que tu aies 1, 5 ou 150 threads, tu auras le nombre d'objets correspondant ;)
06/06/2013, 14h02
qlt654
Dans la cas d'objets statiques, leurs destructions interviendraient uniquement à la fin du scope.
Donc, dans le cas ou je choisirais de stocker les objets dans des attributs de la fabrique, à la fin de la fabrique.

Il faut donc, si je choisis cette solution (qui me semble, sans allocation dynamique la plus viable) que je détermine le nombre de d'objet dont j'ai besoin en simultané, et la durée de persistance donc j'ai besoin.

ça va me demander un petit peu d'étude, mais je pense que j'y vois beaucoup plus clair sur la nature même de mon problème :

Sans fabrique :
- Les objets doivent être instanciés (statiquement) dans les contextes
- Dans les contextes, je sais combien d'objets j'ai besoin et sur quelle persistance
- Cela implique que les contextes aient la connaissance de la structure de la famille d'objet (ce que j'aurais voulu éviter)
Avec une fabrique :
- Les objets doivent être instanciés (statiquement) dans la fabrique
- Depuis la fabrique, il est délicat de prévoir combien d'attribut de stockage d'objet je dois avoir
- La fabrique permet aux contextes de ne connaitre que l'interface de la famille d'objet
Je pense qu'en poussant un peu plus la conception des contextes, j'aurais une plus grande visibilité et je devrais pouvoir trouver un compromis viable.

En tout cas, merci à tous pour votre aide.
La conclusion : l'instanciation dynamique c'est quand même vachement sympa ;)
06/06/2013, 16h29
ternel

tu peux très bien avoir un vector de pointeurs dans les contextes, et utiliser une factory "allouante".
06/06/2013, 22h51
therwald

Citation:

Envoyé par qlt654

Temps réel mou ici. Pour mon cas c'est une instruction que j'ai, relative à un éventuel besoin d'utiliser le programme sur un support avec une mémoire très limitée.
Je vais essayer d'avoir plus de précision sur les contours de cette restriction.

Si le problème c'est uniquement la taille de la mémoire, ce n'est pas un vraiement un problème de real-time, non?
Le coût d'un [smart]-pointer n'est pas nul, mais pas extravagant non plus, j'imagine? De plus une référence coût la même chose qu'un pointeur à priori?
07/06/2013, 07h54
qlt654

Citation:

Envoyé par therwald

Si le problème c'est uniquement la taille de la mémoire, ce n'est pas un vraiement un problème de real-time, non?
Le coût d'un [smart]-pointer n'est pas nul, mais pas extravagant non plus, j'imagine? De plus une référence coût la même chose qu'un pointeur à priori?

Le risque a priori c'est d'avoir un dépassement de mémoire en cours d'exécution, ou plutôt de ne pas être capable de garantir que ça n'arrivera pas.
07/06/2013, 14h43
therwald

Citation:

Envoyé par qlt654

Le risque a priori c'est d'avoir un dépassement de mémoire en cours d'exécution, ou plutôt de ne pas être capable de garantir que ça n'arrivera pas.

Mais ça peut arriver sur la pile aussi, donc finalement c'est pas seulement une question de dynamique vs statique, c'est plutôt qu'il faut savoir combien d'objets on utilisera simultanément au max, et trouver un moyen de borner strictement ce nombre. Après la question dynamique vs statique devient secondaire, non?