Discussion :

[therwald]

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

[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

[qlt654]

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.

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.

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)

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

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.

[koala01]

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

[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

[ternel]

tu peux très bien avoir un vector de pointeurs dans les contextes, et utiliser une factory "allouante".

[therwald]

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?

[qlt654]

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.

[therwald]

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?