Vous connaissez FreeAndNil() , mais l’utilisez-vous ? À quelle fréquence? L’utilisez-vous correctement ? Comme pour la plupart des choses dans le développement de logiciels, c’est un sujet compliqué. Voyons donc ce que les experts ont à dire. Nous allons débattre des détails lors d’une discussion amicale avec certains de vos MVP préférés.

• Cet article de blog comprendra la rediffusion, des diapositives et plus encore après le webinaire.

Le sondage dit…

Lorsque vous vous inscrivez au webinaire , nous avons inclus un court sondage pour voir où vous en êtes sur la question. Au cours du webinaire, nous comparerons le consensus général avec celui de notre panel d’experts MVP.

Encore plus de MVP ont pesé sur le sujet et j’ai quelques teasers sur la façon dont ils ont voté…

J’ai laissé la légende selon laquelle les graphiques signifient pour l’instant, vous devez rejoindre le webinaire pour voir les détails, mais l’utilisation de FreeAndNil () est assez également répartie si nous regroupons les réponses en généralités pour et contre.

Si nous décomposons les choses en détails, c’est un peu plus nuancé. Encore une fois, sans la légende, pour le moment.

Faire des chèques assignés est similaire, mais des différences un peu plus prononcées.

• Q : J’ai une devise : si vous avez créé quelque chose, détruisez-le à la fin de la routine ! C’est pourquoi j’utilise beaucoup FreeAndNIl() !
• R : Ce n’est pas toujours possible, mais je comprends ce que vous voulez dire.
• Q : L’instanciation à la demande est souvent un modèle judicieux, et vous n’aurez donc rien à placer dans votre pointeur !
• R : Joli point
• Q : Est-ce que ce type fait de la vraie programmation ?
• A: oui, beaucoup.,Oui, c’est un codeur extrêmement expérimenté et très respecté. Je te promets 🙂
• Q : Appelez votre objet factice « Nil » 😛
• R : Bon point.
• Q: Je suis assis corrigé.
• R : lol
• Q: nil est un excellent moyen de confirmer qu’il n’y a rien de référencé, et si vous êtes TOUJOURS libre avec FreeAndNil, votre code maintiendra automatiquement que le pointeur sera nil s’il n’est pas valide, sinon c’est toujours un objet valide.
• R : Cela signifie nil, mais il y a des moments où vous n’avez pas besoin de l’attribuer à nil, ou lorsque vous pouvez masquer autre chose.
• Q : Comment pouvez-vous dire « toujours utiliser des interfaces » et ensuite dire également « vous ne devez jamais détruire quelque chose que vous n’avez pas créé » – complètement incohérent !
• R : J’ai dit : « si vous le pouvez, utilisez des interfaces » et le point concernant le codage vers une interface est que le comptage de références est explicitement conçu pour gérer cela.
• Q : Il existe des tonnes de cas d’utilisation pour Assigned et FreeAndNil. Si vous ne les utilisez pas, soit vous n’utilisez pas de tels cas d’utilisation, soit vous êtes un mauvais programmeur. Dire qu’il n’y a aucune raison de les utiliser, ou que si vous les utilisez, vous ne devriez pas l’être, est complètement faux.
• A: Je crois que ce que Nick dit, c’est que l’utilisation de FreeAndNil et des chèques assignés est une odeur de code dont vous pourriez avoir besoin pour prendre une conception différente. De plus, la surutilisation de FreeAndNil obscurcit également les choses.
• Q : Il existe de nombreuses circonstances où le code responsable de la libération d’un objet n’est pas le même code qui a créé l’objet. L’exemple le plus évident est un modèle de gestion de mémoire de comptage de références.
• R : bien sûr
• Q : Devrait également obtenir une vue de développement C++
• R : Oui, certains MVP utilisent les deux.
• Q : F# utilise le type Option (type union avec Some et None) pour éviter nil, et je pense que cela nécessite une prise en charge dans le langage (dans le système de type). Delphi fournit-il ce type de support ?
• R : pas que je sache…
• Q : Pourquoi voudriez-vous libérer un objet et ne pas définir le pointeur vers lui sur nil ?
• R : Si la référence n’est plus là parce qu’elle sort immédiatement du champ d’application, l’affectation n’est pas nécessaire.
• Q : Ce qu’Olaf vient d’expliquer porte un nom : la programmation culte du cargo.
• R : C’était un concept auquel je pensais entrer dans ce webinaire. Je suis un grand partisan de la programmation basée sur des preuves. , Tbh, j’ai dû chercher ce que signifie « Cargo Cult ». Oui je suis d’accord. Mais comme je l’ai dit, si vous êtes sur votre propre route, ou s’il y a des conducteurs sûrs, alors FreeAndNil() est maintenant utile. Ce que je vois dans la nature est cependant bien différent. N’oubliez pas que je travaille fréquemment avec des équipes externes, avec des compétences très différentes. Beaucoup d’entre eux n’ont pas (encore) la balise « Save Driver »
• Q : L’article de wikipedia contient même cette déclaration : « Les vérifications obsessionnelles et redondantes des valeurs nulles ou le fait de tester si une collection est vide avant d’itérer ses valeurs peuvent être un signe de programmation culte du cargo. »
• R : lol
• Q : Nous utilisons des méthodes de lecture de propriété qui incluent des vérifications pour l’attribution d’une variable « f » et la construisons à la demande… parfois, la construction de cette variable « f » a des ramifications (par exemple, une demande à une base de données ou une construction de formulaire). ne construisez pas chaque variable « f » à l’avance. Et nous sommes libres et gratuits pour vous aider à garantir que les appels ultérieurs vers la propriété sont gérés et initialisés de manière appropriée.
• R : bien sûr
• Q : FreeAndNil simule les variables locales C++ unique_ptr. Delphi 10.4 a enfin introduit RAII, donc il peut y avoir un truc unique_ptr plus explicite maintenant, mais je dois maintenir le code Delphi 7, et donc je continue à utiliser FreeAndNil comme unique_ptr qui manque
• R : C’est toujours frustrant quand je dois aussi travailler avec du code pour d’anciens compilateurs.
• Q : « Il n’y a pas de mal à laisser un pointeur sur un objet qui a été libéré » – vraiment ? Avez-vous déjà eu à déboguer quelque chose ?
• R : C’est vrai, je ne suis pas d’accord avec le genre de dénigrement spécieux des compétences en programmation, mais je vois ce que vous dites, c’est-à-dire « cela peut causer des problèmes avec le débogueur, vous n’êtes donc pas d’accord ».
• Q: peut-être devriez-vous expliquer la différence exacte entre x.free et FreeAndNil(x) Je pense que tout le monde ici n’est pas conscient de la différence
• R : FreeAndNil(x) free est l’objet, identique à x.free, mais il définit également la référence sur nil. Si vous ne définissez pas la référence sur nil, elle pointera toujours vers l’objet libéré.
• Q : Un champ de classe qui fait référence à un objet doit être nil jusqu’à ce que l’objet soit créé, et lorsque l’objet est libéré, il doit être mis à nil. Cette conversation est absurde pour moi.
• Q : Exemples de code ?
• R : Si vous regardez les diapositives, il y a quelques articles de blog qui renvoient au code.
  Avons-nous besoin de vérifier la référence de l’objet

 https://developpeur-pascal.fr/faut-il-vraiment-utiliser-freeandnil-dont-nos-programmes-en-pascal.html https://corneliusconcepts.tech/delphi-debates-freeandnil

• Q : Je ne comprends vraiment pas la raison de ce débat. Je pensais que cela allait expliquer pourquoi FreeAndNil devrait être utilisé au lieu d’utiliser .Free puis := nil. Ici, nous semblons discuter de l’utilisation de FreeAndNil sur des objets que je n’ai jamais créés. Je pense que j’ai perdu le fil !
• R : La discussion porte sur les avantages et les inconvénients de l’utilisation de FreeAndNil et des références non attribuées.
• Q : J’ai développé SafeMM3 et j’ai trouvé un bogue dans FireMonkey. Le destructeur a utilisé « Free » pour une référence qui est censée disparaître puisqu’il s’agit après tout d’un destructeur, mais une opération SetFocus promenait des pointeurs pendants. Vous pouvez rarement être sûr que la dernière opération sur référence est vraiment la dernière.
• R : bon point.
• Q :Le fait est que NIL est une vraie valeur vraie dans le code, et pour cette raison, on vérifiera ces situations (comme rejeter un NIL comme l’indique Nick), et en tant que tel, NIL ne disparaît pas, il est donc logique de NIL quelque chose à assurez-vous que la mémoire est bien NIL et non une ancienne valeur aléatoire d’autrefois. Ceci est particulièrement important lorsque vous écrivez du code haute performance de bas niveau, mais évidemment beaucoup moins important lorsque l’on écrit principalement du code de haut niveau, en scriptant essentiellement des modules existants ensemble. Les interfaces ont absolument de nombreuses utilisations intéressantes, mais parfois nous avons simplement besoin de pointeurs vers des enregistrements ou des classes, et là, garder une trace de NIL ou non NIL est assez critique. Par conséquent, FreeAndNil a ses utilités, mais x.Free aussi ; et x==nul ; Si ce dernier échoue, alors FreeAndNil peut échouer et nous parlons d’un scénario multithread,
• A: Joli point Kim.
• Q : Faux. Vous ne devez pas toujours créer une classe dans son constructeur. S’il est courant de créer l’objet lors de sa première utilisation, puis de le laisser créé pour le réutiliser.
• R : Je vois qu’il y a pas mal de gens qui partagent ce point de vue.
• Q : Le modèle d’objet nul (c’est ce que Nick a appelé l’objet factice) est acceptable pour les injectables, mais pas pour de nombreux creatables
• Q : Récemment, j’ai eu un gros crash à cause de l’accès à un objet libéré qui n’était pas nul. C’est vraiment difficile à détecter. Si la variable sort de la portée, nil n’est pas vraiment nécessaire, mais vous devez vérifier très attentivement le code pour éviter de l’utiliser par la suite.
• R : À mon avis, s’il y a une chance que votre référence soit encore utilisée plus tard, alors vous devriez l’attribuer à nil avec FreeAndNil.
• Q : Action := caFree Quand je fais cela, dois-je mettre un pointeur nil ? MaClasse := TMaClasse.Create; MyClass := nil quand j’utilise Action := caFree
• Q : La question clé devrait probablement être… y a-t-il un véritable inconvénient à utiliser freeandnil ?
• R : Obscurcit les choses et peut introduire des erreurs avec une initialisation paresseuse.
• Q : L’utilisation d’interfaces n’est normalement pas une question de gestion de la mémoire, mélanger les deux (avec le manque de documentation explicite) est toute une série de catastrophes qui attendent de se produire. J’ai vu beaucoup de code contenant des références d’interface à des objets qui ont été libérés lorsque le nombre de références est passé à zéro. Une discipline de gestion de la mémoire consistant à toujours libérer explicitement avec FreeAndNil semble devoir être intrinsèquement plus sûre.
• R : peut -être
• Q : Je pense que sur une application multithreading, il est logique d’utiliser Assigned() et FreeAndNil(), lorsque les instances peuvent être utilisées temporairement ou que les interactions avec des services/serveurs distants peuvent être interrompues et nécessiter des reconnexions avec ces instances temporaires.
• R : Oui, je pense que plusieurs des MVP sont d’accord avec vous.
• Q : Ada.Unchecked_Deallocation fonctionne comme FreeAndNil. Il en va de même pour la procédure Delete, elle détruit le curseur passé. Dommage que les développeurs Delphi se tournent rarement vers les autres descendants de Pascal pour s’inspirer
• A: Je pense qu’il y a beaucoup plus d’investigations sur les techniques et les innovations de toutes les langues – pas seulement des descendants de Pascal – que vous pourriez réaliser. Par exemple, les déclarations de variables en ligne (que je détestais personnellement lorsqu’elles sont sorties) sont inspirées par d’autres langages qui faisaient cela. Ils sont très « non-Pascal » mais se sont avérés avoir des avantages très distincts qui étaient trop convaincants pour être ignorés.
• Q : Vous ne devez pas toujours créer tous les objets d’une classe dans son constructeur. Il est courant, du moins pour nous, de créer le ou les objets uniquement si et quand ils sont nécessaires, puis de les laisser créés pour les réutiliser. Ensuite, lorsque la classe est détruite, elle doit détruire les instances créées. Assigned et FreeAndNill sont essentiels pour cela.
• A : Initialisation paresseuse, oui
• Q : Je dois laisser tomber, mais bonne discussion !
• R : Merci Gary.
• Q : Pour les ordinateurs d’aujourd’hui, le ou les cycles CPU pour FreeAndNil sont insignifiants, même pour les moteurs 3D ou autre. Ce n’est pas 1980 !
• R : comme Nick et Thomas l’ont souligné, cela oblige le développeur à se demander pourquoi FreeAndNil, donc cela prend plus de cycles de développement.
• Q :J’apprends à développer une application mobile avec Delphi 10.4 CE FMX, et j’ai beaucoup de doutes et je ne les trouve nulle part, sauf dans les groupes de télégrammes ou les vidéos 99coders – qui a une didactique fantastique, en plus de Márcio, Gledson Prego , Anderson Fiori et MobiusOne, qui nous a beaucoup aidés. Mais cela ne suffit pas pour une application aussi ancienne que Delphi. Mes doutes sont : 1) Quelle est la bonne méthode et où dois-je détruire les objets (*) qui sont instanciés dans une fonction/procédure dans la section VAR ? (*)jsonarray, jsonobject, frame, etc… >> 1a) ces objets les détruisent-ils avec FreeAndNil, disposeOf, .free, =nil ? >> 1b) quelle est la méthode la meilleure et la plus efficace pour détruire ces objets ? >> 1c) quel est le bon endroit (événement) pour les détruire ? à la fermeture, onDestroy ? 2) Pourquoi Delphi provoque-t-il tant de fuites de mémoire d’objets que nous sommes sûrs qu’ils sont en train d’être détruits ?
• Q : C’est une excellente session (Marco)
• A: Oui, il semble populaire.
• Q : Pourriez-vous expliquer pourquoi FreeAndNil() n’est pas thread-safe ?
• R : Ce n’est pas atomique. Vous devez verrouiller la référence avant l’appel à FreeAndNil.
• Q : « Dangling Pointers » – un modèle de gestion de mémoire coopératif doit garantir que les consommateurs d’objets sont avertis lorsqu’un objet est libéré.
• Q : FreeAndNil est défini sur nil avant qu’il ne se libère. Ainsi, bien que vous puissiez avoir un changement de contexte avant d’avoir libéré l’objet, vous aurez déjà défini le pointeur sur nil…
• Q : Si la libération est la dernière action, alors Free(). Si une variable est utilisée plusieurs fois, alors FreeAndNill() ?
• A : si vous allez réutiliser la référence, alors FreeAndNil
• Q : Que fait réellement FreeAndNil ? Pourquoi .Free ne définit-il pas la référence à nil ?
• R : Free vérifie la référence pour voir si elle est assignée, et si c’est le cas, alors il détruit l’objet, mais il fait toujours référence à l’objet détruit. FreeAndNil lui attribue en outre la référence au nil.
• Q : Malheureusement, les variables en ligne ne fonctionnent toujours pas. si vous utilisez les outils de recherche de référence ou de refactoring « après » une variable en ligne dans une unité, cela casse ces outils 🙁
• R : Il y a encore du travail et des RSP en rapport avec la refactorisation et les variables en ligne. La refactorisation (et tout comme le reformatage automatique) peut être un problème pour les nouvelles constructions de langage.
• Q : Le seul avantage spécifique que Pascal avait sur les langages basés sur C… l’obligation de déclarer la section d’interface ET les variables avant utilisation. La façon dont cela permet d’avoir une vue d’ensemble du code simplement en y jetant un coup d’œil.
• R : oui
• Q : Trouvez mon projet SafeMM3 sur OSDN. Contrairement à SafeMM et SafeMM2, il est compatible avec Delphi récent, testé sur Delphi 10.2. J’ai trouvé des pointeurs pendants dans FireMonkey, produit par Naked Free
• R : faites attention aux pointeurs pendants.
• Q : Et puis cet avantage a été « compromis » par la déclaration de variable en ligne et même la déduction du type de données…. Brzzzzz….
• R : J’adore les variables en ligne.
• Q : Où sont les exemples ?
• A: J’ai posté quelques liens ci-dessus.
• Q : rappelez-vous, je viens du clipper/port où j’ai commencé à 14 ans et y suis resté jusqu’en 2021 où j’abandonnais et j’ai regardé une vidéo boostée par 99coders parlant de Delphi où le titre était quelque chose comme ceci : « delphi est mort ? » et cela a montré que vous pouvez faire beaucoup via delphi, en particulier pour les mobiles (android/ios) lol
• Q : Comment procédez-vous lorsque vous utilisez des DLL et que vous transmettez des objets en tant que paramètre ? Faites-vous une copie de l’objet et le renvoyez-vous en tant qu’objet de résultat ?
• R : Cela dépend je suppose.
• Q : une autre question de quelqu’un du Brésil : 3) pourquoi avez-vous essayé d’utiliser .DisposeOf si vous deviez revenir à FreeAndNil()
• Q : C++ – J’ai une formation en C++, c’est pourquoi j’ai trouvé le manque de documentation explicite autour des interfaces Delphi si exaspérant.
• R : ah oui
• Q : 4) veuillez donner un bon exemple d’utilisation efficace de freeAndNill() ne laissant aucune fuite de mémoire…
• Q : Ces points font apparaître les idées de propriété/d’emprunt dans Rust
• R : Oui, Rust s’est beaucoup inspiré de Delphi.
• Q : Je n’ai pas de question, mais je tiens à vous remercier pour le développement de Delphi. Merci)
• R : Merci ! Je suis content que Delphi soit là aussi !
• Q : qu’est-ce qu’une bonne source pour comprendre la structure de conception de l’interface ?
• A: Je crois que les livres de Nick Hodges en parlent
• Q : Les interfaces ne sont pas thread-safe. Seul le compteur de références à l’intérieur de TInterfacedObject l’est. Mais l’affectation d’interface est une opération non atomique et devrait être verrouillée.
• R : Oui, le livre de Dalija en parle longuement.
• Q : Il y avait un commentaire sur le « gaspillage des cycles CPU »… Combien d’instructions assembleur sont nécessaires pour « x = nil » ? Si cela est fait sur plusieurs objets dans une sorte de cycle/boucle, l’attribution de NIL peut avoir un impact sur les performances si les variables ne sont plus référencées après les avoir libérées, mais si les variables peuvent être référencées en dehors de la boucle plus tard, il est préférable de savoir si elles le sont faisant référence à un objet existant.
• A: Vérifiez la vue CPU et voyez.
• Q: MISRA C est tout au sujet de la programmation culte du fret. C autorise les déclarations sur une seule ligne, mais MISRA C les interdit. C’est donc une pratique assez industrielle. Rien à avoir honte
• R : ah
• Q : Beau débat !
• R : Il s’est avéré beaucoup plus populaire – et source de discorde – que nous ne le pensions !
• Q : @Nick, si vous envisagez de ne jamais utiliser FreeAndNil(), alors dans les applications basées sur des événements (pas si rares), comment pouvez-vous éviter de créer des objets à des moments inconnus et éviter de les créer deux fois ou plus ? Le cas typique est celui où l’utilisateur clique sur un bouton et exécute un descendant de TThread. Qu’en est-il si l’utilisateur clique 2 fois sur le même bouton, la 2ème fois alors que le 1er TThread lancé par le 1er clic n’est pas terminé.
• A : Peut-être empêcher le bouton d’être cliqué deux fois ? Cela semble être une préoccupation valable.
• Q : J’ai réussi à instancier un objet en utilisant « assigned ». J’ai seulement libéré l’objet de la mémoire avec « action: caFree » mais je n’ai pas indiqué « nil ». Comment est-ce possible ?
• R : À moins que vous n’appeliez FreeAndNil, ou que vous ne l’assigniez explicitement à Nil, alors free n’annule pas la référence.
• Q : exemple, où FreeAndNil affichera des erreurs dans le code : avec object.Free, vous n’obtiendrez pas d’exception si vous utilisez accidentellement l’objet. avec FreeAndNil(object) vous obtiendrez l’exception immédiatement !exemple : procedure TForm1.BT_Click(Sender: TObject); var sl : TStringList ; begin sl:=TStringList.Create ; essayez enfin sl.Free; //FreeAndNil(sl); fin; // — // autres trucs // — if (sl.Text = ”) then sl.Text:= ‘Hello World!’; fin;
• R : merci
• Q : Y a-t-il une situation dans laquelle j’ai besoin d’utiliser un objet libéré ? (le plus souvent j’ai besoin de « Nil » un var sans libérer l’objet). Ou, peut-être, FreeAndNil n’existe que pour être complet car x.free n’a pas pu « Nil » la var. Merci
• R : À mon avis, j’utilise FreeAndNil lorsqu’il existe d’autres références qui pourraient le référencer après qu’il soit nul.
• Q : Aucun code n’est exempt de bogue. Vous voulez que les bogues échouent tôt et durement. FreeAndNil aide à détecter les bogues « utiliser après la libération ».
• R : vrai
• Q : Je n’appelle jamais le destructeur directement, c’est le travail de Free, n’est-ce pas ?
• R : oui
• Q : J’utilise presque toujours freeandnil sur des composants tiers, ne faites jamais confiance au code des autres 😛
• Q : Je ne sais pas si appeler directement Destroy est réellement plus rapide que d’utiliser Free. Tout simplement parce que Destroy est un appel de méthode virtuelle. Quelqu’un doit fournir une référence pour prouver ce point
• R : vrai
• Q : La création d’un objet lors de sa première utilisation peut créer de nombreux problèmes lorsque vous essayez de faire quelque chose avec cet objet. J’en ai fait l’expérience lors de l’ajout de certaines fonctionnalités à InplaceEditor d’un TCustomGrid.
• Q : L’idéal serait de programmer de manière à ce que le compilateur aide à détecter les problèmes… beaucoup de discussions ici portent plutôt sur les compétences du programmeur.
• Q : Références de formulaire global – l’IDE créera automatiquement un pointeur global vers les formulaires…
• Q : Vous traitez donc l’IDE de fou ? En provenance de Jim ? C’est juste grossier !
• R : 🙂
• Q : En parlant de variables en ligne « non-Pascal », Ada depuis le début a un bloc declare-begin-end. Donc ce n’est pas « non-Pascal », c’est juste que tu ne connais pas encore Ada. Mais Ada ne s’arrête pas là. Delphi venait tout juste d’obtenir des « variables en ligne » alors que dans Ada, le développeur apprécie plus souvent les « constantes en ligne » à la place. En effet, si quelque chose est initialisé au début d’un bloc, il y a de fortes chances qu’il ne change jamais avant la fin de la portée. Marquer des éléments « constants » facilite la lisibilité et le raisonnement
• R : Oui ! = Pascal. ️
• Q : Si vous utilisez FreeAndNIL de manière persistante, il n’y a pas de cycle de développement supplémentaire lorsqu’il est utilisé. C’est seulement quand vous n’êtes pas cohérent dans votre utilisation…
• A: Je suppose que c’est un point valable.
• Q : Suis-je autorisé à dire à quel point j’ai apprécié cette discussion stimulante ? Merci!
• A: heureux de l’entendre.
• Q : Quels livres de Dalija Prasnikar recommanderiez-vous concernant le sujet d’aujourd’hui ?
• R : https://dalija.prasnikar.info/delphimm/index.html
• Q: Je vais jeter mes deux centimes dans le ring…. avec déclaration… essayez de ne pas les utiliser et ne les utilisez certainement pas pour plus d’une chose….. juste MHO
• R : Oui, c’est aussi mon avis – mais tout le monde n’est pas d’accord, apparemment – ​​d’où le débat.
• Q : lequel utiliser puis détruire : .free disposeOf =nil freeAndNil() ??? lequel libère vraiment de la mémoire et on se débarrasse de la merde « Memory Leak » ? obs.: delphi 10.4 CE / FMX / Mobile
• Q : Comment s’appelle le livre de Dalija ?
• R : https://dalija.prasnikar.info/delphitspatt/
• Q : Ce webinaire a été formidable. Je vais être honnête, je ne m’attendais pas à grand-chose, mais franchement, cela a été l’un des meilleurs webinaires de ces derniers temps…. Plus de la même chose s’il vous plaît !!
• R : C’est noté. Heureux que vous l’ayez apprécié.
• Q : Je n’ai jamais utilisé FreeAndNil. Jamais – à moins que Nick ne commence à l’utiliser 😀
• R : ah
• Q : Une discussion très intéressante sur le traitement des variables pointeurs…. J’ai l’habitude de jeter ou de remettre les pointeurs en mémoire après les avoir utilisés
• R : Oui. C’est un modèle.
• Q : Totalement d’accord avec la suggestion de Holger : s’il vous plaît, Delphi peut-il arrêter de créer une nouvelle application avec un formulaire construit autour de variables globales ? Vaut certainement un débat.
• R : J’y ai pensé aussi.
• Q : le lien fourni par vous ne fonctionne pas : https://developpeur-pascal.fr/faut-il-vraiment-utiliser-freeandnil-don’t-nos-programmes-en-pascal.html – ce lien ne fonctionne pas ( erreur 404)
• Q : Merci, j’ai apprécié la séance !
• Q : Suggérer de conserver et de publier également le chat
• Q : Je dois courir. Merci beaucoup !!! Bon travail.
• Q : Détruire seul est plus rapide que Libre. L’implémentation de Free est « IF Assigned(Self) THEN Destroy » ; donc en appelant Destroy directement, vous omettez un CALL et un contrôle « If Assigned » – vous appelez toujours le Destroy virtuel…
• Q : Si vous souhaitez vérifier la sécurité des threads des éléments d’interface, écrivez le descendant de TInterfacedObject qui appelle Sleep(10) dans AddRef et Release. J’ai écrit des références sans verrouillage avec la primitive Compare-And-Exchange qui réussit ce test. Je peux probablement aussi faire une référence faible thread-safe
• Q : Honnêtement, les nobles « gourous » n’ont répondu à aucune de mes questions. Il y a 11 hommes et femmes qui sont les crânes de Pascal/Delphe et moi qui part et qui vient du clipper/port, j’aimerais votre attention, même pour que je me sente chez moi !
• Q : J’essaie toujours, dans la mesure du possible, de créer l’objet et de libérer le même objet dans la même routine, de cette façon j’ai beaucoup plus de contrôle et beaucoup moins de risques de problèmes de mémoire et de référence.
• Q : Nous avons beaucoup parlé au fil des années de l’utilisation d’interfaces pour la gestion automatique de la mémoire… qu’en est-il maintenant des enregistrements gérés ? Pouvons-nous faire du RAII à delphi… y a-t-il un autre chemin ?
• A: oui, RAII introduit cela.
• Q : Si vous deviez compiler les questions et les réponses qui sont posées et les publier, ce serait excellent.
• A : Je verrai pour faire ça.
• Q : J’ai rejoint un peu tard, désolé si cela a été demandé et discuté avant ; si vous obtenez l’objet enfant comme dans (ParentObject.childObject) libéré de toute façon, puis vous freeAndNil parentObject… cela ne peut-il pas être sûr en raison du temps nécessaire pour libérer chaque objet peut se croiser et être séquentiel?
• R : Bonne question. Même si vous annulez la référence, l’objet sera toujours responsable de la libération de ses enfants, tandis que les enfants utilisent un modèle de notification pour informer le parent lorsqu’ils sont libérés.
• Q : Si vous lancez un thread en cliquant sur un bouton, il semble évident que vous devriez être prêt à exécuter plusieurs threads :-), vous ne libérerez pas d’objets partagés dans ce thread. Ou … vous désactivez le bouton.
• R : oui
• Q : combien coûte FreeAndNil de FreeAndNil manuel suivi de l’attribution manuelle de Free ?
• R : Du point de vue du processeur, il ne nécessite pas grand-chose, mais qu’est-ce qu’il communique ?
• Q : J’ai apprécié cette discussion animée entre de véritables experts en programmation.
• Q : Le Delphi RTL utilise GOTO 🙂
• R : oui
• Q : Merci, plus à ce sujet s’il vous plaît. +1
• R : bien sûr
• Q : Si vous détruisez un TJSONObject, détruit-il également tous les objets « GetValue as TJSONString » ?
• Q : Suggestion… ne pouvons-nous pas simplement avoir « ne pas utiliser avec »… voyons ce qu’il a essayé de faire… ce que les autres langues ont… et ce que nous pourrions commencer à faire à la place avec delphi moderne dans cette direction
• Q : Les événements de clic sur un bouton ne sont-ils pas générés à la suite d’un GetMessage dans la file d’attente des threads de l’interface utilisateur ? Le deuxième événement de clic ne sera pas livré tant que le premier n’aura pas été traité, à moins qu’il ne soit produit par programmation, ce qui poserait un problème de réentrance. Qu’est-ce que j’oublie ici?
• Q : Plus de goto dans le RTL depuis que j’ai commencé à optimiser certaines fonctions du système sans faire d’asm 😉
• Q : Ce n’est pas si simple de simplement désactiver le bouton, car les choses sont plus compliquées. J’utilise une chose telle que « demande » de la programmation fonctionnelle. Ainsi lors du premier clic sur le bouton, la demande comptée par référence est créée, dédiée au « premier clic ». Le thread peut alors faire certaines choses et interroger sa propre « demande » pour vérifier si elle est toujours demandée. Et après avoir entré Synchroniser, vérifiez également si cette « demande » spécifique est toujours en place. Lorsque le bouton clique pour la deuxième fois, l’ancienne demande est marquée comme obsolète et une nouvelle demande est déployée. De cette façon, le premier fil reçoit le message : va-t’en, nous n’avons plus besoin de toi
• Q : Souhait : des variables locales, statiques, qui survivent à travers les appels (utilisent actuellement des CONST locales assignables)
• Q : Merci

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---