Des idées ambitieuses ! !! - page 4
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Calmez-vous.
Pourquoi est-ce un non-sens ? Il suffit de calculer le nombre de pointeurs nécessaires pour atteindre la bonne donnée ou fonction.
Si vous savez certainement compter. :)
Voulez-vous vous calmer ? Que faire ? Lorsque vous créez une nouvelle instance d'une classe - c'est-à-dire une variable de type classe, cela crée un duplicata de la table de relation et c'est tout.
L'accès aux données, à la fois dans la classe et dans la variable habituelle, est le même en vitesse, toutes les mesures descriptives sur la division des droits d'accès à l'intérieur des classes (privé, public) - tout cela au niveau du compilateur, le code compilé ne fonctionne qu'avec les cellules de la mémoire physique.
Supposons qu'il y ait une "classe dynamique complexe" qui est astucieusement créée à la volée à partir d'autres classes astucieusement créées. Et alors ? Après tout, tout sera calculé par une fonction spécifique. Etait-ce vraiment la peine de construire un jardin pour de tels tours de cirque ?
La maladie progresse-t-elle ? On vous l'a dit plusieurs fois, la POO libère le programmeur des actions routinières de préparation des données, du contrôle du contenu des données et c'est au programmeur de décider comment implémenter les méthodes à l'intérieur de la classe ou appeler des fonctions tierces.
La POO fait également partie du passé. La tendance actuelle est la programmation orientée vers le matériel, qui est principalement en C, par exemple CUDA. Avec la sortie des processeurs dotés d'un GPU, cette situation sera encore améliorée. Les fabricants de processeurs prévoient de ne plus commercialiser uniquement des cœurs de processeurs universels.
Ici je ne suis pas compétent, et dans votre bouche cette information ne semble pas crédible
SZZY : pourquoi je vous écris, n'écrivez pas de bêtises sur les forums techniques, partagez vos connaissances et si vous ne savez pas quelque chose, demandez-le moi.
allez-vous vous calmer ? qu'est-ce qu'il faut faire ? lorsque vous créez une nouvelle instance d'une classe - c'est-à-dire une variable de type classe, cela crée un duplicata de la table de relation et c'est tout.
l'accès aux données, qu'elles soient dans une classe ou dans une variable ordinaire, est le même en termes de vitesse, toutes les mesures descriptives pour séparer les droits d'accès au sein des classes (privat, public) sont toutes au niveau du compilateur, le code compilé ne fonctionne qu'avec des cellules de mémoire physique
Voici donc une question pour un expert. Une classe est constituée de trois tableaux dynamiques (la taille au moment de la compilation est inconnue).
Maintenant, veuillez calculer et comparer le nombre d'opérations pour accéder à un tableau statique arbitraire et à un tableau dynamique dans la classe.
Je ne suis pas compétent ici, et dans votre bouche cette information ne semble pas crédible
Qu'est-ce que la logique du programme a à voir avec la présentation des données ? Ces choses ne sont pas du tout liées.
La logique du programme est constituée d'opérations arithmétiques sur des données d'entrée quelconques, tandis que la représentation des données est simplement constituée de données dans un format ou un autre.
Et par définition, il est impossible de réduire le code du programme avec la POO puisqu'il apparaît des pointeurs externes aux objets pour accéder aux données internes (fonctions et variables) au lieu d'un accès direct. Mais comme le calcul des pointeurs et des références mémoire est une opération très lente, les performances diminuent en conséquence.
Développer des applications OOP n'est pas la même chose que développer des bibliothèques de classes. À proprement parler, un développeur de bibliothèque ne devrait pas du tout se soucier de l'usage qui sera fait de sa bibliothèque par ceux qui écrivent eux-mêmes les programmes d'application. Par exemple, un fabricant de marteaux ne se soucie pas du tout de l'usage que vous faites de son produit - pour planter des clous ou casser des noix. Sa tâche consiste à créer un outil. De même, dans la POO, les classes sont des outils permettant de résoudre un certain nombre de tâches, généralement très vastes et pas toujours clairement définies (qui sait, peut-être utilisez-vous un marteau pour tuer des cafards ?)
Une fois encore, pour résoudre les tâches les plus simples, vous n'avez pas besoin de la POO. Mais d'un autre côté, vous ne pensez pas que tous ceux qui veulent planter un clou doivent se fabriquer un marteau, n'est-ce pas ?
Bien sûr, vous pouvez argumenter que nous avons une bibliothèque de fonctions, pourquoi avons-nous besoin de plus de classes ? Mais dans ce cas, vous vous privez des commodités offertes par les mécanismes d'héritage, les extensions de type, la surcharge, etc. En gros, vous pouvez visser un moteur fait maison sur un marteau et le faire fonctionner à votre façon, mais vous n'avez pas besoin de comprendre le mécanisme du marteau ; tout ce que vous devez savoir, c'est qu'il peut être utilisé pour planter des clous.
Alors, croyez-moi, la POO facilite vraiment la vie des programmeurs qui écrivent des applications. Par ailleurs, les capacités des bibliothèques MQL5 sont encore très limitées, mais c'est une question de temps, et les développeurs de bibliothèques s'en chargeront (même si, bien entendu, il peut s'agir - mais ce n'est pas une obligation - des mêmes personnes). Avec un système bien développé de bibliothèques de classes, il suffit à un utilisateur-programmeur d'écrire une ou deux lignes comme "1. programme, voici les données" "2. programme, compte" dans un programme, presque sans se demander comment il fonctionne en détail. Cela n'est pas possible avec la programmation orientée structure.
Il me semble que votre parti pris contre la POO est le résultat du fait que soit vous n'avez pas rencontré de tâches suffisamment complexes, soit vous ne voulez tout simplement pas le faire par paresse ou pour une autre raison. Je dirais ça pour rien. Cependant, le maître est le maître.
Voici la question d'un expert. Une classe est constituée de trois tableaux dynamiques (la taille au moment de la compilation est inconnue).
Maintenant, veuillez calculer et comparer le nombre d'opérations pour accéder à un tableau statique arbitraire et à un tableau dynamique dans une classe.
Vous travaillez avec des tableaux dynamiques ou statiques, et l'endroit où vous utilisez les tableaux dynamiques n'a pas d'importance : dans une classe ou simplement dans une variable.
Le fait que travailler avec des tableaux dynamiques prenne un peu plus de temps est "difficile à comprendre" - il y a un contrôle pour les dépassements de tableau et le gestionnaire d'allocation de mémoire dynamique sera souvent appelé
alsu:
1. Mais dans ce cas, vous vous privez de la commodité offerte par les mécanismes d'héritage, d'extensions de type, de surcharge, etc. En gros, vous pouvez boulonner un moteur artisanal à un marteau et le faire fonctionner à votre façon, mais vous n'avez pas besoin de comprendre la mécanique du marteau ; tout ce que vous devez savoir, c'est que vous pouvez planter des clous avec.
2. Avec un système bien développé de bibliothèques de classes, il suffit à un utilisateur-programmeur d'écrire une ou deux lignes comme "1. programme, voici les données" "2. programme, compte" dans un programme, presque sans demander comment il fonctionne en détail. Dans la programmation orientée structure, cela ne peut être réalisé.
1. Dans le RPP, vous devez également vous occuper des classes - ce qu'elles font exactement. Comme s'il s'agissait d'une fonction quelconque. Mais avec les classes, il est plus difficile de retracer toute la chaîne, c'est pourquoi on passe généralement plus de temps à étudier leur structure, au même niveau de fonctionnalité.
2. Dans la programmation orientée vers la structure, vous pouvez également organiser de telles actions sans aucun problème, sans devoir entrer dans des détails que quelqu'un a déjà abordés auparavant.
Il s'agit de travailler avec des tableaux dynamiques ou statiques, et l'endroit où vous utilisez les tableaux dynamiques n'a pas d'importance : dans une classe ou dans une variable.
Ok, je vais poser une question plus simple. Comparez le nombre d'opérations lors de l'accès à une variable d'un tableau unidimensionnel et d'un tableau bidimensionnel.
Et maintenant vous allez soutenir qu'il n'y a presque aucune différence ?
Ok, alors je vais poser une question plus simple. Comparez le nombre d'opérations lors de l'accès à une variable dans un tableau unidimensionnel et un tableau bidimensionnel.
Allez-vous prétendre qu'il n'y a presque aucune différence ?
S'agit-il également d'une question de POO ?
Si non, alors : si le tableau est statique - alors il n'y aura pas de différence de performance lors de l'accès aux tableaux unidimensionnels et bidimensionnels, parce que les données des tableaux multidimensionnels sont stockées en mémoire par chaînes, comme si vous avez le tableau x[20] et le tableau y[2][10], alors les données y seront enregistrées en mémoire : d'abord y[0] et ensuite y[1], qui sera physiquement situé comme x[20]
s'il y a un certain retard dans les performances, il est insignifiant et ne se produit qu'en raison du contrôle de dépassement de tableau
Si le tableau est dynamique, cela dépend du fabricant du compilateur - la part du code du gestionnaire de mémoire qui est optimisée (dans Delphi, la plupart du module System est écrit en ASM), parce que l'allocation de mémoire pour un tableau dynamique multidimensionnel est un peu plus compliquée, mais alors, généralement le problème n'est pas dans les tableaux dynamiques, mais dans le programmeur - comment justifié et souvent il appelle l'allocation de mémoire pour un tableau dynamique.
SZS : merci pour le chat - mais je ne peux pas pour votre manque de compréhension des choses élémentaires de passer autant de temps - commencez à lire vous-même
S'agit-il également d'une question de POO ?
si non, alors : si le tableau est statique - alors il n'y aura pas de différence de performance lors de l'accès à un tableau unidimensionnel et bidimensionnel, parce que les données d'un tableau multidimensionnel sont stockées en mémoire sous forme de chaînes, comme si vous avez un tableau x[20] et un tableau y[2][10], alors les données y seront enregistrées en mémoire : d'abord y[0] et ensuite y[1], qui sera physiquement situé comme x[20]
Vous avez tort car vous ne connaissez pas les choses les plus simples.
Les données d'un tableau quelconque sont stockées en mémoire de manière linéaire. Du premier au dernier, pour accéder à un élément x[15], il faut calculer l'adresse du début du tableau plus l'offset 15, qui sera l'adresse de la variable pour calculer cette variable. Si nous avons un tableau à deux dimensions, par exemple, x[2][5], nous calculons d'abord le décalage pour la deuxième ligne, puis nous y ajoutons le décalage pour le 5e élément, soit deux fois plus d'opérations.