striiiiiiiiiiiiiiing - Page 28

Folco (./809) :
Kevin -> J'y ai bien pensé, en pensant à ce que propose TIGCC, mais je voudrais éviter d'utiliser les extensions GNU...

JackosKing (./807) :
Ha les exceptions, ou la deresponsabilisation la plus totale....

Oui, mais le code est propre à l'oeil

JackosKing (./807) :
Et la liste d'init c'est un peu de la branlette de mamoutte pour pas grand chose, surtout dans ces cas!

Complètement ! Mais on fait comment pour s'en passer ? Je me prends une volée de bois vert de g++ si je le fais pas...

Laisse JS tranquile, à pars troller il ne fait rien d'interessant actuellement

Brunni (./810) :
Heu si tu fais ça tu déclares une variable locale (tu voulais initialiser ta variable d'instance non?)

Non, j'initialise une variable membre de l'objet.

Godzil (./811) :

Folco (./809) :
Kevin -> J'y ai bien pensé, en pensant à ce que propose TIGCC, mais je voudrais éviter d'utiliser les extensions GNU...

JackosKing (./807) :
Ha les exceptions, ou la deresponsabilisation la plus totale....

Oui, mais le code est propre à l'oeil

JackosKing (./807) :
Et la liste d'init c'est un peu de la branlette de mamoutte pour pas grand chose, surtout dans ces cas!

Complètement ! Mais on fait comment pour s'en passer ? Je me prends une volée de bois vert de g++ si je le fais pas...

Laisse JS tranquile, à pars troller il ne fait rien d'interessant actuellement

Interessant comme remarque... bon aller je vais t'aider: programmation par contrat B.Meyer.

...le développer limité manie son code en fonction du language, l'artiste maitre de son art manie son code en fonction d'un design...

L'évolution des magouilles geek a une porté très limitée dans le temps...

[nosmile]

Brunni (./810) :
Ou alors tu passes un SDL_Rect et tu fais memcpy(&m_offset, &monRect, sizeof(monRect)) ou une copie membre à membre.

Ce n'est pas la peine d'utiliser memcpy pour ça, depuis l'ISO C90 (donc aussi en C++), il suffit de faire m_offset = monRect;.

Et sinon, il y a bien une méthode pour éviter les compound literals:

class SDL_Rect_Initialized : public SDL_Rect {
  public:
    SDL_Rect_Initialized(int offsetX, int offsetY, int width, int height)
      : SDL_Rect::offsetX(offsetX), SDL_Rect::offsetY(offsetY), SDL_Rect::width(width), SDL_Rect::height(height)
      {}
};

ensuite tu utilises SDL_Rect_Initialized(offsetX, offsetY, width, height) pour initialiser ton objet (et ce sera automatiquement converti en la classe de base).

Bien vu

Folco (./812) :

Brunni (./810) :
Heu si tu fais ça tu déclares une variable locale (tu voulais initialiser ta variable d'instance non?)

Non, j'initialise une variable membre de l'objet.

Justement pas ^^
KK> Quel con, je sors tout de suite l'artillerie lourde

Brunni -> Oui mais en fait je m'en fous D'ailleurs je fait autrement maintenant, mais t'avais raison

Je me demande comment on peut détruire proprement un objet alloué sur la pile... ça fait con, hein
Il me semble qu'un objet est détruit à la fin du bloc qui l'a créé, mais il possède aussi un destructeur. Je vois donc :

    OBJECT Truc;
    [...]
    ~Truc();

Mais il parait que c'est cracra

Autre méthode :

label:
    OBJECT Truc;
        while (machin)
        {
            OBJECT Truc;
            [...]
        }
        // ici machin est détruit

    goto label;   // et hop, on recommence

Autre méthode, allouer sur le tas, et faire un delete...
Quel est le mieux ?

Ben Flan t'as déjà dit qu'on n'appelle pas le destructeur à la main pour supprimer un objet, non ?

On n'apelle JAMAIS un contructeur, ni un destructeur a la main ! (d'ailleurs le compilateur devrait te gueuler dessus si tu le tente)

en gros pour répondre à la question, quand tu mets un objet sur la pile, anéfé il est détruit en sortant du bloc, mais en prime le destructeur est appelé automatiquement avant

Et ça vous arrive de créer un bloc juste pour obtenir la destruction d'un objet ?

Dans le cas d'une boucle infinie (attendant un message EXIT_POGRAM par exemple), là où je gère mes modules, j'ai besoin de détruire un module avant d'en construire un autre. Si l'objet est sur la pile, je n'ai d'autre choix que de sortir d'un bloc "artificiel", juste pour provoquer sa destruction.
Si je l'alloue en RAM, je ferai un delete, et je n'aurai pas ce bloc bizaroïde. Je ne sais ce qui est le mieux.

Folco (./822) :
Et ça vous arrive de créer un bloc juste pour obtenir la destruction d'un objet ?

Pas vraiment.
En général, les ressources que l'utilisateur peut vouloir gérer à la main, comme par exemple un fichier, ont des méthodes pour signaler explicitement qu'on ne s'en sert plus. Par exemple le couple File.open() -> close(), le Thread.run() -> stop(), le Dispose / Release d'autres APIs, etc.
Ainsi l'objet peut toujours vivre mais ce qu'on lui a demandé de faire est terminé.
C'est aussi une bonne habitude de se faire la réflexion, car pour la plupart des langages actuels on ne peut plus compter sur le destructeur (i.e. il n'y a même pas de garantie qu'il soit appelé avant la fin de l'appli).

Euh normalement si, non ? C'est juste qu'on ne sait pas précisément à quel moment il sera appelé il me semble. Parce que ne pas l'appeler du tout, ça pose problème si tu as des ressources non managées associées.

Brunni (./823) :
Ainsi l'objet peut toujours vivre mais ce qu'on lui a demandé de faire est terminé.

La partie la plus importante du release se passe au niveau de l'OS j'imagine, mais un close ne signifie pas libérer l'objet à priori (ou alors, il invente une manière pour s'autodétruire, je sais pas, mais ya un truc ).

Brunni (./823) :
car pour la plupart des langages actuels on ne peut plus compter sur le destructeur (i.e. il n'y a même pas de garantie qu'il soit appelé avant la fin de l'appli)

Euh, j'ai pris le goût à l'objet, mais je veux rester dans les langages où l'on maitrise un minimum ce qui se passe hein (contre-troll )

Bon sinon ça répond pas à ma question, laissez tomber je vais allouer sur le tas

Folco (./822) :
Et ça vous arrive de créer un bloc juste pour obtenir la destruction d'un objet ?

Ca tu veux dire ?
func() { [...] code(); [...] { ObjetBlabla bla; bla->bli(); [...] } /* La bla est détruit */ [...] code() }

Zerosquare (./824) :
Euh normalement si, non ?

Ouais c'est à peu près ça.
Globalement, t'as la garantie que si tu as pas triché ou fait des trucs trop dégueu, tous tes objets soient détruits proprement avant la fin de l'application. (Avec le CLR par exemple, la libération de mémoire est zappée pour la plupart des objets (je passe les détails) en cas d'erreur fatale, ou quand tu apelles Environment.FailFast())

C'est juste qu'on ne sait pas précisément à quel moment il sera appelé il me semble.

C'est plus vicieux même, tu ne sais même pas dans quel ordre les destructeurs seront appelés.

Parce que ne pas l'appeler du tout, ça pose problème si tu as des ressources non managées associées.

Oui et non. La plupart des ressources seront des ressources de l'OS allouées au processus donc rien de très grave, mais en effet il peut y avoir certain types de ressources qui ne seront pas libérés comme ça (mais beaucoup moins depuis la mort de la mémoire partagée entre processus)

Enfin pour le reste, comme a dit Brunni, un objet qui doit être libéré de manière déterministe doit avoir un mécanisme associé pour ce faire… Soit avec une méthode close(), release() ou que sais-je encore, ce qui marchera si l'objet est sur la pile… Soit (pour le C++) en utilisant new et delete qui sont aussi là pour ça !

Zerosquare (./824) :
Euh normalement si, non ? C'est juste qu'on ne sait pas précisément à quel moment il sera appelé il me semble. Parce que ne pas l'appeler du tout, ça pose problème si tu as des ressources non managées associées.

->

Brunni (./823) :
(i.e. il n'y a même pas de garantie qu'il soit appelé avant la fin de l'appli).

Folco (./825) :
Euh, j'ai pris le goût à l'objet, mais je veux rester dans les langages où l'on maitrise un minimum ce qui se passe hein (contre-troll )

Justement tu maîtriseras mieux le flux de ton programme avec des appels de méthodes explicites, et tu ne te reposeras pas sur l'effet de bord de destruction de variable en fin de bloc. Bref pour la compréhension => new/delete, pour la vitesse => pile, c'est assez évident.

GoldenCrystal (./827) :
Globalement, t'as la garantie que si tu as pas triché ou fait des trucs trop dégueu, tous tes objets soient détruits proprement avant la fin de l'application. (Avec le CLR par exemple, la libération de mémoire est zappée pour la plupart des objets (je passe les détails) en cas d'erreur fatale, ou quand tu apelles Environment.FailFast())

Ce qui est valable pour une framework comme .NET, mais pas forcement pour de l'objet static comme le C++. Le destructeur d'un objet en C++ est appelé des qu'on sort de la fonction si l'objet est instancié sur la pile.

IE: l'execution en C++ est 100% déterminé a la compilation, ce qui n'est pas le cas en C# (par exemple)

Brunni (./828) :
(i.e. il n'y a même pas de garantie qu'il soit appelé avant la fin de l'appli).

La phrase est ambiguë... j'avais compris ça comme "aucune garantie qu'il soit appelé tout court". Tu voulais dire que ça pouvait être différé jusqu'au moment où on quitte l'appli, mais que ce serait appelé quand même, c'est ça ?

Folco (./825) :
Euh, j'ai pris le goût à l'objet, mais je veux rester dans les langages où l'on maitrise un minimum ce qui se passe hein (contre-troll )

Heu y avait pas de troll, si? Mais si tu y tiens, je peux me lâcher
Hum alors je t'ai déjà dit que tu devrais faire de l'objective-C? Ha non. Mais pour le Java au moins c'est le cas (d'ailleurs à l'heure qu'il est tu maîtriserais probablement mieux ce qui se passe en Java qu'actuellement en C++ - si jamais tu maîtrises un jour le C++, ce qu'à la limite seul Kevin peut prétendre). Pour en revenir à l'Objective-C je suis à peu près sûr que tu adorerais la gestion de la mémoire.
Voilà c'était les trolls du soir

Zerosquare (./830) :

Brunni (./828) :
(i.e. il n'y a même pas de garantie qu'il soit appelé avant la fin de l'appli).

La phrase est ambiguë... j'avais compris ça comme "aucune garantie qu'il soit appelé tout court". Tu voulais dire que ça pouvait être différé jusqu'au moment où on quitte l'appli, mais que ce serait appelé quand même, c'est ça ?

Oui

./829 > Bah je sais mais on parlait bien des langages modernes (./823) non ?
En plus ce que tu dis est faux: exit() ne va apeller tous les destructeurs, (contrairement à .NET justement) donc non, ce n'est pas entièrement déterministe.

Et pas besoin de prendre des langages récents, si on prend fstream en C++ par exemple on a bien open() et close() pour manipuler les fichiers.

Folco> Si tu alloues tes objets sur la pile, ils seront automatiquement désalloués à un moment, normalement tu n’as pas besoin de t’en soucier.

Oui, mais « un moment » c'est pas assez précis.
Si son objet C++ fait que 4 (ou 8 ) octets, c'est du gâchis (mémoire et performance) de l'allouer dynamiquement. Par contre si son objet alloue 250 Mo derrière, il peut être intéressant de contrôler plus précisément son fonctionnement. Bref cf. encore ce qu'a dit Brunni avec les .close() & compagnie

(Ah oui, et pour les blocs de code: perso quand j'utilise des blocs, c'est surtout pour réutiliser des noms de variable plusieurs fois dans la fonction. Le reste c'est annexe )

Godzil, ./826 -> voilà, c'est exactement ce que je veux dire.

Brunni (./831) :
Heu y avait pas de troll, si? Mais si tu y tiens, je peux me lâcher

Désolé, je voyais "Java" écris en filigramme dans tout ton post

Sasume (./834) :
Folco> Si tu alloues tes objets sur la pile, ils seront automatiquement désalloués à un moment, normalement tu n’as pas besoin de t’en soucier.

Oui, ce qui m'embête c'est ce cas :
Module1 entraine la création de Module2
Module2 entraine la création de Module1
Module1 entraine la création de Module2
Module2 entraine la création de Module1
etc..., sans que la création de Module(n) entraine la destruction de Module(n-1)

Tu me diras qu'avant d'avoir un overflow de la pile, j'ai de quoi faire, sûrement, sur un PC. Mais quoi qu'il en soit, je ne trouve pas ça propre. Donc même si mes objets devraient être détruits de manière usuelle (appel de leur destructeur à la sortie du TaskManager qui aura créé tous ces modules), je préfère ne pas avoir une situation foireuse et potentiellement dangereuse.

Ah parce qu’à chaque fois tu empiles les appels de fonction ?

GoldenCrystal (./832) :
./829 > Bah je sais mais on parlait bien des langages modernes (./823) non ?
En plus ce que tu dis est faux: exit() ne va apeller tous les destructeurs, (contrairement à .NET justement) donc non, ce n'est pas entièrement déterministe.

Bien sur que si c'est deterministe. un "exit" est une sortie d'urgence, pas un moyen propre de quitter une application

Folco (./836) :
Oui, ce qui m'embête c'est ce cas :
Module1 entraine la création de Module2
Module2 entraine la création de Module1
Module1 entraine la création de Module2
Module2 entraine la création de Module1
etc..., sans que la création de Module(n) entraine la destruction de Module(n-1)

Tu me diras qu'avant d'avoir un overflow de la pile, j'ai de quoi faire, sûrement, sur un PC. Mais quoi qu'il en soit, je ne trouve pas ça propre. Donc même si mes objets devraient être détruits de manière usuelle (appel de leur destructeur à la sortie du TaskManager qui aura créé tous ces modules), je préfère ne pas avoir une situation foireuse et potentiellement dangereuse.

Heu, vousrais-tu dire que tu as quelque part une récursion infinie, ou légèrement différemment, un cycle ?
Car Module1 => Module2 => Module1 => Module2 => …, je vois pas le truc.
Pour les références circulaires, on utilise des pointeurs, sinon ça peut même pas compiler.

Sasume (./837) :
Ah parce qu’à chaque fois tu empiles les appels de fonction ?

J'ai deux situations :
- Module1 fait charger Module2 par le TaskManager, et Module2 en quittant demande au TM de repasser la main au module précédant : je dois donc empiler.
- Module1 fait charger Module2, mais n'attends pas de retour : le TM doit donc décharger Module1 avant de charger le 2.

Ces deux situations sont voulues, je dois donc être capable de détruire Module1 si j'en ai envie. Dans le cas d'un cycle (merci GC ^^), il est bien évident que je dois demander le déchargement du module précédent.

---

Souci avec une liste d'initialisation d'un objet (pour changer...) :

        std::vector<Module> *m_ModuleList;
        std::vector<int> *m_TaskList;

Ces deux pointeurs sont des attributs d'un objet. Donc quand je crée cet objet, deux vecteurs sont créés, et *m_ModuleList et *m_TaskList prennent comme valeur l'adresse des-dits vecteurs.
Et donc dans ma liste d'init, je mets quoi ? Je vais pas initialiser l'adresse des vecteurs à autre chose pour le plaisir, non ? Et g++ râle si je ne mets rien...
Comment faire propre ? (à moins que je n'ai pas compris le mécanisme de la création des objets :/)