Aide sur la POO - page 4

Nouveau commentaire
 
Vasiliy Sokolov #:

Officiellement, oui. Officieusement, beaucoup de choses indiquent qu'elle existe :

  • Il n'y a pas de pointeurs dans MQL. Au lieu de cela, ils sont remplacés par quelque chose qui leur ressemble beaucoup.
  • Il n'y a pas d'allocation directe de mémoire dans MQL, comme en C par exemple ;
  • Les programmes en MQL sont exécutés par une certaine machine virtuelle. Renat en a parlé brièvement et pas une seule fois ;
  • On peut définir l'instance de la classe qui sera libérée automatiquement. Il existe donc un mécanisme qui surveille ces instances et les libère si nécessaire. Qu'est-ce que c'est si ce n'est un collecteur d'ordures ?
  • Toute instance initialisée par le biais d'un pointeur et qui n'est pas correctement libérée sera marquée comme objet fuité à la sortie. Leur nombre et la taille totale de la mémoire perdue seront imprimés. Un programme avec une fuite de mémoire ne sera même pas validé dans Market. Ainsi, tous les objets, même ceux attribués manuellement, sont comptabilisés, connus et connus du système. C'est l'une des tâches classiques que le collecteur d'ordures résout.

Il y a une indication suffisante et complète qu'il n'y a pas de collecteur de déchets dans emcool - la suppression est obligatoire après le nouveau.

 
Dmitry Fedoseev #:

Il y a une indication suffisante et suffisante qu'il n'y a pas de collecteur de déchets dans emcool - la suppression est obligatoire après le nouveau.

Autant que je me souvienne, l'un des développeurs a reconnu qu'il y avait un collecteur d'ordures. Mais pour l'utilisateur, il "n'existe pas en quelque sorte".

Eh bien, à propos de la paire nouveau-supprimé - je suis tout à fait pour. En général, les objets qui ont demandé des ressources doivent en être responsables. Il existe des exceptions, comme la "fabrique d'objets", mais dans ce cas, il est expressément prévu que la responsabilité des objets créés incombe à celui qui a demandé ces objets à la fabrique.

Je n'aime pas la situation dans les langues où il y a du nouveau et où la suppression n'est pas nécessaire, car le "système fera le ménage". Non seulement cela réduit potentiellement les performances (lorsque les objets inutiles ne sont pas encore supprimés), mais cela détend également le codeur, lui permettant de ne pas se soucier des conséquences de ses actions.

 
Georgiy Merts #:

Je n'aime vraiment pas la situation dans les langues où new est là, mais où delete n'est pas nécessaire, en disant "le système va supprimer le superflu". Non seulement cela réduit potentiellement les performances (lorsque les objets inutiles ne sont pas encore supprimés), mais cela détend également le codeur, lui permettant de ne pas se soucier des conséquences de ses actions.

En revanche, la productivité est généralement améliorée. La suppression manuelle prend beaucoup de temps dans le fil principal. + la suppression se fait élément par élément. Comparez les deux versions du script dans ce fil, par exemple. La différence de vitesse est de plusieurs fois. L'efficacité de la mémoire augmente également. Parce que le collecteur d'ordures déplace des objets compactés les uns avec les autres. Si vous le gérez manuellement, il crée des trous de mémoire libres qui ne sont pas si faciles à réutiliser. De plus, le ramasseur de déchets travaille dans un autre thread. Le temps de base n'est pas perdu. En somme, un plus.

 
Vasiliy Sokolov #:

Au contraire, la productivité est généralement accrue. La suppression manuelle prend beaucoup de temps dans le courant principal. + la suppression se fait élément par élément. Comparez deux versions du script dans ce fil, par exemple. La différence de vitesse est de plusieurs fois. L'efficacité de la mémoire augmente également. Parce que le collecteur d'ordures déplace des objets compactés les uns avec les autres. Si vous le gérez manuellement, il crée des trous de mémoire libres qui ne sont pas si faciles à réutiliser. De plus, le ramasseur de déchets travaille dans un autre thread. Le temps de base n'est pas perdu. Dans l'ensemble, c'est juste un plus.

Vasily, je suis désolé, mais vous ne comprenez pas du tout ce dont vous essayez de parler. Pas du tout et en aucun cas.

Lisez au moins Wikipédia pour savoir ce qu'est un collecteur d'ordures. Sa principale particularité est de supprimer les objets avec lesquels la communication a été perdue.

Seulement dans ce cas, il s'agirait d'un collecteur d'ordures. Ces deux scripts sont d'une autre histoire. Le don de Dieu ne doit pas être confondu avec un œuf.

Et pourquoi un garbage collector augmenterait-il soudainement la productivité ? Il s'agit d'une protection de plus entre le code utile et le matériel, et pas des moindres.

 
Georgiy Merts #:

Si je me souviens bien, l'un des développeurs a reconnu que le collecteur d'ordures existe bel et bien. Mais pour l'utilisateur, c'est "un peu parti".

///

Il doit s'agir du "ramasseur de déchets" qui envoie un message sur les fuites de mémoire à la fin du travail.

Peut-être même qu'il supprime les objets abandonnés. Mais même si ça les supprime, il y a un gros...

La différence est qu'il ne les supprime qu'à la fin du travail. Et si dans un cycle de plusieurs milliers de nouveaux objets sont créés ?

de nouveaux objets ? Le programme sera inopérant, pas assez de mémoire.

Un véritable assembleur supprime les objets perdus au cours de l'opération de programmation, et non pas les objets perdus.

seulement à la fin du programme. C'est pourquoi un style de programmation spécial est autorisé.

nous pouvons multiplier des objets dans n'importe quelles conditions et en n'importe quelle quantité.

 
Vasiliy Sokolov #:

Au contraire, la productivité est généralement accrue. La suppression manuelle nécessite un temps considérable dans le courant principal. + la suppression se fait élément par élément. Comparez deux versions du script dans ce fil, par exemple. La différence de vitesse est de plusieurs fois. L'efficacité de la mémoire augmente également. Parce que le collecteur d'ordures déplace des objets compactés les uns avec les autres. Si vous le gérez manuellement, il crée des trous de mémoire libres qui ne sont pas si faciles à réutiliser. De plus, le ramasseur de déchets travaille dans un autre thread. Le temps de base n'est pas perdu. En somme, un plus.

Hmm... Et dans un collecteur d'ordures, la suppression n'est pas élémentaire ? Sans compter que l'autre fil, lorsqu'il n'y a pas de cœurs libres, est exécuté par le même cœur, et ralentit le fil principal.

À mon avis, en général, si l'on y réfléchit bien, l'enlèvement des ordures par l'utilisateur est toujours plus efficace que l'enlèvement par le ramasseur d'ordures. Cependant, si vous ne vous en souciez pas, le collecteur d'ordures gagne certainement.

C'est pourquoi je n'aime pas le ramasseur de déchets, car il encourage ce même traitement indifférent des ressources.

 
Dmitry Fedoseev #:

Ce doit être l'"assembleur" qui donne le message sur les fuites de mémoire lorsque le travail est terminé.

Il supprime même probablement les objets restants. Mais même s'il les supprime, il y a un gros...

La différence est qu'il ne les supprime qu'à la fin du travail. Et si dans un cycle de plusieurs milliers de nouveaux objets sont créés ?

de nouveaux objets ? Le programme sera inopérant, pas assez de mémoire.

Un véritable assembleur supprime les objets perdus au cours de l'opération de programmation, et non pas les objets perdus.

seulement à la fin du programme. C'est pourquoi un style de programmation spécial est autorisé.

nous pouvons multiplier des objets dans n'importe quelles conditions et en n'importe quelle quantité.

C'est vrai. C'est pourquoi je n'aime pas travailler avec l'assembleur - l'utilisateur ne fait pas attention au nombre d'objets qu'il a créés et à leur emplacement.

Au fond, cela simplifie même le développement d'une certaine manière - vous ne devez pas vous souvenir de supprimer celui qui est occupé. Builder trouve le moment où l'objet n'est plus référencé, et il le supprime. Mais cette position me dégoûte. C'est à cause de cette position que nous avons des programmes qui tournent de plus en plus lentement, qui nécessitent des ressources matérielles de plus en plus puissantes pour des tâches de complexité similaire.

 
Dmitry Fedoseev #:

Vasily, je suis désolé, mais vous ne comprenez rien du tout à ce que vous essayez d'argumenter. Rien du tout et en aucune façon.

Dmitry, excusez-moi, connaissez-vous un autre langage de programmation que le mukl ? Non, vous ne le faites pas. Et vous n'avez toujours pas appris à travailler avec des objets et des pointeurs, c'est clair dans les quelques codes et même articles que vous avez publiés. C'est pourquoi je ne peux même pas répondre sérieusement à ce commentaire sans talent et franchement stupide. Lisez enfin wikipedia, apprenez ce qu'est un collecteur d'ordures et comment il est organisé, lisez enfin au moins une fois ce à quoi vous essayez de vous référer. Jusqu'à présent, tout cela ressemble à un chien qui aboie sur une caravane : insensé et sans pitié.
 
Georgiy Merts #:

Hmmm... Et dans le collecteur de déchets, la suppression n'est pas élémentaire ? Sans parler du fait qu'un autre thread, lorsqu'il n'y a pas de cœurs libres - est fait par le même cœur, et ralentit le thread principal.

À mon avis, en général, si l'on y réfléchit bien, l'enlèvement des ordures par l'utilisateur est toujours plus efficace que l'enlèvement par le ramasseur d'ordures. Cependant, si vous ne vous en souciez pas, le collecteur d'ordures gagne certainement.

C'est pourquoi je n'aime pas le ramasseur de déchets, il encourage ce même traitement indifférent des ressources.

Plutôt que de faire des hypothèses sur le fonctionnement d'un ramasseur d'ordures, il suffit de comparer la vitesse de suppression automatique des objets à celle de la suppression manuelle. Tous les fantasmes disparaîtront d'un coup.

 
Vasiliy Sokolov #:

comparer les vitesses de la suppression automatique des objets et de la suppression manuelle des objets.

La réponse est de préférence immédiate. On n'a pas toujours le temps de faire des expériences.

123456789
Nouveau commentaire
Raison: