striiiiiiiiiiiiiiing - Page 57

(oui)
(Perso je le fais souvent… Et il y a un autre modèle un peu plus avancé où le parent prend possession de l'enfant: children->parent = this; quand ce n'est pas le parent qui le crée.)

oui, c'est très courant comme pratique. ça permet aussi de savoir si ton objet est attaché à un parent ou non quand il est créé séparément
la méthode Conteneur::addObject(Contenu *) va appeller la méthode Contenu::setParent(Conteneur *) pour lui dire qui est son parent
et la methode Conteneur::removeObject(Contenu *) appellera Contenu::setParent(NULL) poru dire au fils qu'il est détaché du parent

Ok, merci beaucoup.

Vous voyez, la dernière fois que je me suis planté et que je suis resté bloqué, c'est parce que je ne voulais pas utiliser ce mécanisme : ça met en place une dépendance.
Donc à moins de créer une dépendance très polyvalente utilisant le polymorphisme pour pouvoir établir des filiations dans tous les sens (parent* peut pointer sur un objet de n'imorte quel type en gros), je créais les dépendances entre classes qu'on m'avait tant décriées.

Ma solution de passage de message marchait, mais était complexe et overkill pour le problème à résoudre. La, j'ai simplement besoin qu'une icone puisse dire à une autre de se désactiver par exemple : je n'ai qu'à remonter au parent immédiat pour lui dire de le faire sur un objet "frère", ça reste très simple.

hooooo... hiiiissssse !!!! (<- extirpation d'un vieux topic).

Une question, de stratégie. Pour un programme qui n'a pas besoin d'être conçu en un assemblage de pièces détachées (comme en entreprise où l'on veut pouvoir réutiliser du code pour différents projets), mieux vaut-il avoir quelques variables globales, ou un objet global pour les contrôler tous (© Tolkien) et fournir les accesseurs kivonbien au reste du programme ? Je suis parti sur la seconde idée, sans y voir d'inconvénient, mais peut-être est-ce une très mauvaise idée ?

Folco (./1684) :
comme en entreprise où l'on veut pouvoir réutiliser du code pour différents projets

Je l'avais déjà remarqué, mais tu surestimes beaucoup le monde de l'entreprise, tu sais



Heu, sinon, sérieusement, si tes variables globales ne peuvent vraiment pas être rattachées à un concept (une classe), tu peux les grouper dans une classe utilitaire, oué. J'aime bien centraliser aussi.

Mais souvent, une var globale est quand même rattachée à un module. Dans ce cas là, c'est largement préférable de passer par un attribut statique de la classe concernée.

Ok, merci bien.

(et me casse pas mes rêves quand même )

(désolé )

Folco (./1684) :
comme en entreprise où l'on veut pouvoir réutiliser du code pour différents projets

aaah, tu veux dire le copier coller?
ouais, c'est bien, ca

Euh, bon, je sais pas ce qu'il en est réellement à ce niveau, mais j'imagine qu'un patron doit quand même être content de pouvoir réutiliser du code qui a demandé deux semaines de dev à trois bonshommes, non ?

(mais teeellement vrai)

Edit : oui et non... de ce que j'ai pu voir, il y a des bibliothèques génériques qui peuvent être développées, mais en règle générale elles sont plus spécifiques à un dev en particulier qui s'est fait son petit toolkit qu'autre chose. Concernant les progiciels développés sur plusieurs années par des prestataires qui peuvent changer, c'est autrement plus trash : chaque prestataire inclut à chaque fois ses librairies pour pas se faire chier, ça fait de très jolis monstres mutants à la fin . Après, la solution qu'indique momotte est extrêmement fréquente (parfois même en cross code... on copie-colle un bout de C en Java, un bout de Java en PHP, on adapte un bout de ci à ça, etc.). C'est crade, mais ça évite de s'emmerder avec telle ou telle compatibilité, règle de nommage ou que sais-je. Puis ça permet de récupérer un bout de ci, un bout de ça... un peu comme quand on se fait une cabane, c'est tellement plus classe avec un vieux pneu en guise de marchepied qu'on a soi-même récupéré !

Bon je capte rien, expliquez-moi comment c'est en vrai

Es-tu bien certain de vouloir connaître la Vérité ?

ouep, huhuhu

(cross ^^)

Ah ok merci. Donc en vrai c'est une alchimie abominable quoi

Souvent, oué.

Ici on a une app qui est tellement bordélique que plein de fonctions sont implémentées n fois car les devs ne savaient pas qu'elles étaient déjà dispo
(Heureusement, je ne travaille pas sur ce projet \o/)

Bon, je te rassure, quand on commence un nouveau projet, on se dit toujours "on va faire ça proprement, pour une fois"
Et il y a quand même des domaines où c'est un peu plus sérieux (tout ce qui est embarqué), mais je ne sais pas s'il y a de la reprise d'existant d'un projet à l'autre...

Nil (./1697) :
Et il y a quand même des domaines où c'est un peu plus sérieux (tout ce qui est embarqué)

Mwhahahaha
(bon, si tu parles embarqué au sens transports/aéronautique/spatial peut-être, et encore, faudrait demander à Ximoon)

Bon, ok

(oué, parce que bon, il suffit de voir sur AMS, déjà %D)

warning: missing parameter

iwannabear (./1688) :

Folco (./1684) :
comme en entreprise où l'on veut pouvoir réutiliser du code pour différents projets

aaah, tu veux dire le copier coller?
ouais, c'est bien, ca

Tellement
Bon remarque ça n'empêche pas de bien coder au moins en surface, parce que le copier/coller c'est bien quand tu peux ensuite épurer et te limiter aux objets fournissant ce que tu as besoin. Par contre si le petit objet au milieu dont tu as besoin a des dépendances qui transitivement référencent tout le projet d'origine, tu pourras moins facilement justifier
(problème qui au passage n'existait pas au temps béni des "main.c qui font tout")

tout ce qu'on fait chez nous est carrément project specific, sauf les trucs sérieux pour cartes, mais là c'est une autre histoire.

Couechieune :

Quand on déclare un objet globalement, cet objet est construit avant l'entrée dans main. Comment faire pour intercepter une exception du constructeur de cet objet à ce moment-là ?

N'est-on pas dans un cas où il faut lancer une fonction GlobalObj.CheckInit() ?

Je ne pense pas que tu puisses, mais je pense que c'est une très mauvaise idée de laisser ton objet s'initialiser automatiquement avant le main surtout s'il peut lancer une exception. Tu ne maitrises pas du tout l'ordre de création et de destruction de ton objet et ça peut avoir des conséquences fâcheuses s'il dépend de l'existence d'un autre objet. tu ne pourras pas assurer que tes objets sont crées dans le bon ordre. (plus de détails dans la c++ faq lite)

T'as deux solutions pour remédier à ça :
- Tu conserves tes objets en global, mais le constructeur ne fait pas grand chose. Le code qui dépend d'autre chose, qui peut échouer, qui est plus sensible, tu le mets dans une méthode init() que tu appelles toi même une fois rentré dans le main. tu fais pareil avec une méthode shutdown() que tu appelles avant de quitter main. On oeut trouver cette méthode bof, ton objet peut être construit et pas initialisé, c'est pas RAII

- Tu remplaces tes objets globaux par des pointeurs globaux et tu alloues les objets toi même une fois rentré dans le main.

Il y a des chances.

Vu que même en entourant le constructeur lui-même d'un try/catch (oui, c'est possible), l'exception est relancée à la fin du catch... Je dirais que tu as intérêt à écrire un objet dont le constructeur (et les constructeurs des objets contenus directement) ne lance pas d'exceptions (ou avale celles qui sont lancées) et règle une variable à la place.

Sinon, tu peux toujours faire des singletons.

(rohlala le genre de saletés qui sont autorisées en c++ )

(c'est le principe du c++ : tu peux tout faire (même de l'asm), à toi d'être raisonnable )

Enfin pour l'Asm, c'est en extension, hein, ça n'est pas présent sur le modèle de série!

ok pour l'asm