Erreurs, bugs, questions - page 2637
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
Je vais peut-être vous surprendre, mais les jeunes programmeurs d'aujourd'hui considèrent la POO comme une programmation plus facile que la programmation procédurale.
Vous pensez en termes d'il y a 25 ans. Les jeunes d'aujourd'hui absorbent OOP avec le lait de leur mère. Apprenez l'OOP si vous voulez être dans la tendance, sinon vous ne ferez rien d'autre que de râler.
Mais c'est vraiment le cas. Laissez les vieux programmeurs essayer de résoudre les tâches des Olympiades pour les écoliers.
Ce qu'ils ont étudié auparavant à l'université, des sujets tels que la programmation dynamique, la théorie des graphes, la programmation orientée objet, les classes, etc. Les écoliers actuels de 9-10 classes (pas tous bien sûr) résolvent de tels problèmes en quelques minutes.
Et c'est naturel. Loi de la nature :)
Oui, je comprends la POO, mais pas autant que je le voudrais, bien sûr.
Ce n'est pas un grief mais une suggestion constructive.
Pour que le développeur n'ait pas à écrire une fonction pour allouer deux mallocs, ils obligent les utilisateurs à apprendre la POO.
Bien sûr, il s'agit du progrès et de la popularisation de la langue. Eh bien, vous pouvez voir à quel point ils aiment et comprennent la POO ici.
Tu vois, Nikolay, tout ce qui est dans le wrapper est du code inutile à exécuter, je ne pense pas que nous ayons besoin de l'expliquer.
Je n'ai pas besoin de vous parler des compilateurs d'optimisation modernes - nous ne savons pas quelles instructions ils appliqueront.
Je vais peut-être aussi vous surprendre en vous disant que même les programmeurs américains préfèrent écrire dans le style procédural, non pas parce que la POO est mauvaise, mais parce que le code est plus simple et plus rapide.
Et s'il n'y a pas de tâches objet dans le projet, pourquoi utiliser des wrappers, qui doivent d'une manière ou d'une autre être compris, pour les jeunes ;))
C'est pourquoi je ne suis pas d'accord avec vous sur le fait que les jeunes absorbent avidement les OOP.
Je pense en C, qui est la base de la logique du langage mql.
C est né en 1972, donc il a 48 ans ;))
Mais de toute façon, le C est l'un des langages les plus rapides. Vous savez pourquoi ? Parce qu'il n'a pas d'enveloppeurs de classe.
Eh bien, ce n'est pas vrai du tout. C'est juste qu'il y a encore beaucoup de langages utilisés sans POO. C, par exemple. Au Canada, par exemple, la plupart des institutions gouvernementales sont assises sur Kobol et ne peuvent pas s'en débarrasser.
https://www.tiobe.com/tiobe-index/
Roman, honnêtement, je ne comprends pas pourquoi vous vous acharnez à changer les dimensions de la matrice - quelles difficultés cela peut-il poser ?
Vous n'avez pas besoin de pointeurs ou de POE pour cela.
De toute façon, pour un ordinateur, un tableau de n'importe quelle dimension est un tableau unidimensionnel.
Travaillez donc avec un tableau dynamique unidimensionnel. Et formez des matrices virtuelles et redimensionnez-les comme vous le souhaitez à l'aide de fonctions.
Par exemple, quelque chose comme :
En pratique, je n'utilise que des tableaux unidimensionnels dans mon code, bien que je traite également des tableaux multidimensionnels sur la base de tableaux unidimensionnels.
C'est pourquoi j'aimerais vous demander de créer des fonctions comme ArrayResize uniquement pour les matrices ArrayResizeMx(A, n, m)
tout est fait, je ne veux pas de solutions toutes faites utilisant la POO (vous n'êtes pas obligé de connaître la POO, utilisez les solutions toutes faites !)
utilisez ALGLIB , il existe une méthode pour redimensionner la matrice Resize().... mais tout est toujours fait par OOP ))))
SZS : cherchez dans le forum, il y a eu de nombreuses fois sur ce sujet, il y avait des exemples, vous pouvez envelopper une structure avec un champ de tableau dans un tableau de ces structures - ce sera sans OOP, mais pour moi tout cela semble encombrant
Je pense en C, qui est la base de la logique mql.
Le langage C est né en 1972, il a donc 48 ans).
Mais de toute façon, le C est l'un des langages les plus rapides. Vous savez pourquoi ? Parce qu'il n'a pas d'enveloppeurs de classe.
Je ne me souviens pas du C pur, je l'ai étudié à l'université il y a longtemps, mais si je ne me trompe pas, le C n'avait pas de tableaux dynamiques en tant que tels, mais vous pouviez travailler avec des pointeurs vers la mémoire, et le travail sur l'allocation de la mémoire et le contrôle de l'accès à la mémoire était entièrement à la charge du programmeur, ce qui est essentiellement la même enveloppe...
OK, ça pourrait être un bon argument, il n'y a pas de raison de continuer.
Roman, honnêtement, je ne comprends pas pourquoi vous avez fait tout un plat de la modification des dimensions de la matrice - quelles difficultés cela peut-il poser ?
Vous n'avez pas besoin de pointeurs ou de POE pour cela.
De toute façon, pour un ordinateur, un tableau de n'importe quelle dimension est un tableau unidimensionnel.
Travaillez donc avec un tableau dynamique unidimensionnel. En attendant, formez des matrices virtuelles et redimensionnez-les comme vous le souhaitez à l'aide de fonctions.
Il est clair que toute dimension est un tableau unidimensionnel pour l'ordinateur.
Tout est une question d'ergonomie du langage. Si nous voyons la dimension [][] dans le code, nous pouvons visuellement comprendre qu'il s'agit d'une matrice et non d'un tableau unidimensionnel.
La lisibilité du code est bien supérieure à celle de deviner ce que contient [][].
Je n'aurais jamais pensé rencontrer un tel manque de compréhension lorsqu'on m'a demandé d'ajouter une fonction sur l'allocation de mémoire pour les matrices.
Vous utilisez tous ArrayResize, c'est pratique et vous ne vous en préoccupez pas. Quel problème représente pour un développeur l'écriture d'une fonction d'allocation de mémoire pourun tableau multidimensionnel?
C'est vrai, il n'y a pas de problèmes ni d'obstacles, et il est pratique pour les utilisateurs d'organiser leur code. J'ai donc décidé de porter une grande et bonne bibliothèque C de méthodes numériques vers mql,
mais je n'ai pas d'outils mql normaux pour cela. Une fois de plus, il existe des béquilles, ce qui enlève toute envie de construire du code inefficace.
Je comprends la POO, mais pas autant que je le voudrais, bien sûr.
Ce n'est pas un grief mais une suggestion constructive.
Pour que le développeur ne doive pas écrire une fonction pour allouer deux mallocs, ils obligent les utilisateurs à apprendre la POO.
Bien sûr, il s'agit du progrès et de la popularisation de la langue. Eh bien, vous pouvez voir à quel point ils aiment et comprennent la POO ici.
Tu vois, Nikolay, tout ce qui est dans le wrapper est du code inutile à exécuter, je ne pense pas que nous ayons besoin de l'expliquer.
Je n'ai pas besoin de vous parler des compilateurs d'optimisation modernes - nous ne savons pas quelles instructions ils appliqueront.
Je vais peut-être aussi vous surprendre en vous disant que même les programmeurs américains préfèrent écrire dans le style procédural, non pas parce que la POO est mauvaise, mais parce que le code est plus simple et plus rapide.
Et s'il n'y a pas de tâches objet dans le projet, pourquoi utiliser des wrappers, qui doivent être compris d'une manière ou d'une autre, pour les jeunes ;))
C'est pourquoi je ne suis pas d'accord avec vous sur le fait que les jeunes absorbent avidement les OOP.
Je pense en C, qui est la base de la logique du langage mql.
C est né en 1972, donc il a 48 ans ;))
Mais de toute façon, le C est l'un des langages les plus rapides. Vous savez pourquoi ? Parce qu'il n'a pas d'enveloppeurs de classe.
MQL est construit en C++.
Roman, afin d'introduire ces fonctionnalités que vous mentionnez, MQL devra introduire beaucoup de choses supplémentaires en termes de travail avec la mémoire. Et c'est une complication pour les débutants.
Vous avez dit vous-même que cela doit être plus facile pour les non-professionnels.
C'est une situation du type "Je suis bon pour apprendre à pédaler sur un vélo, c'est tellement simple et compréhensible. Mettons des pédales dans la BMW, ce sera plus facile." :)
c'est-à-dire que je suis généralement d'avis que les styles procédural et POO sont tous deux boiteux et peu pratiques))
tout est fait, je ne veux pas de solutions toutes faites utilisant la POO (vous n'êtes pas obligé de connaître la POO, utilisez les solutions toutes faites !)
utilisez ALGLIB , il y a une méthode pour redimensionner la matrice Resize().... mais tout est fait avec OOP ))))
SZS : cherchez dans le forum, il y a eu de nombreuses fois sur ce sujet, il y avait des exemples, vous pouvez envelopper une structure avec un champ de tableau dans un tableau de ces structures - ce sera sans OOP, mais pour moi tout cela semble encombrant
Le problème, c'est qu'en C, vous ne vous souvenez pas du C pur, vous l'avez étudié à l'université, mais si je ne me trompe pas, il n'y avait pas de tableaux dynamiques, mais vous pouviez travailler avec des pointeurs vers la mémoire, et le travail d'allocation de la mémoire et de contrôle de l'accès à la mémoire était laissé entièrement au programmeur, ce serait la même enveloppe...
OK, cela pourrait devenir un grand argument et il n'y a aucune raison de continuer.
J'ai essayé ALGLIB, il y a un problème avec l'impression depuis un objet, la fonction ArrayPrint n'imprime pas les objets.
Mais de [][] imprime une belle matrice, même avec des en-têtes, encore une fois, il est facile de voir quand vous avez besoin de suivre visuellement le résultat du calcul.
Oui, j'ai regardé certains sujets sur le forum, mais je ne suis pas impressionné. C'est pourquoi tout semble lourd et inefficace. Le C est un langage très élégant et mql a tendance à le corrompre.
Oui, le C peut allouer de la mémoire pour les matrices dynamiques par le biais de pointeurs, mais dans mql il n'y a pas de pointeurs sur les variables, donc encore une fois nous devons passer aux objets.
Lorsque les utilisateurs n'ont besoin que d'une seule fonction ArrayResizeMx(A, n, m, k) et qu'elle se trouve dans l'implémentation native, vous comprenez la différence.
Eh bien, il est inutile de continuer, s'ils en ont entendu parler et le feront, merci beaucoup. Mais la fonction est vraiment utile et nécessaire.
Spéculation à haute voix, mais c'est plutôt un appel au développeur.
Pour ce Zloy, ne le prenez pas personnellement.
Ainsi, les matrices dynamiques ne peuvent être traitées que par des objets ou des structures. Une autre béquille est créée en général.
Il n'y a pas de pointeurs sur les variables dans mql, nous devons donc utiliser l'approche objet où les pointeurs sont disponibles.
Ainsi, pour utiliser les matrices dynamiques, un utilisateur doit connaître la POO et travailler avec des pointeurs, et de plus, en exécution MQL.
Combien d'entre eux ont cette connaissance ? Vous connaissez la réponse vous-même. Je n'ai pas de difficultés à comprendre l'approche objet, mais pour ceux qui ne connaissent pas la POO
Ils créent un seuil artificiel pour l'utilisation du langage, en particulier lorsqu'il s'agit de matrices dynamiques.
À mon sens, un développeur devrait au contraire s'intéresser à rendre le langage plus facile à utiliser, plutôt que de le compliquer.
En d'autres termes, ils doivent développer les fonctions qui sont nécessaires à l'utilisateur pour travailler confortablement avec la langue.
Et d'autant plus avec les matrices, qui sont presque la base des méthodes numériques.
Pour cette raison, je voudrais vous demander de créer des fonctions similaires à ArrayResize uniquement pour les matrices ArrayResizeMx(A, n, m),
et peut-être aussi pour ceux qui sont multidimensionnels. En d'autres termes, donner la possibilité de travailler avec des matrices non pas comme avec des objets, mais comme avec des tableaux habituels dans le style C.
En particulier pour la représentation visuelle des matrices, la fonction ArrayPrint(A, 0) imprime les matrices à partir de tableaux, et non d'objets.
Les développeurs ont été très précis à ce sujet. Ici
Les développeurs ont été très précis à ce sujet. Ici
Pas besoin d'aller loin, le prochain post, avec des questions spécifiques de Prival,
Je le connais depuis longtemps, depuis à peu près la même époque, un développeur militaire compétent, et quoi, pourquoi il est parti d'ici, la réponse est évidente.
Cela fait dix ans, est-ce que quelque chose a changé ?
Comme il était rempli d'algorithmes simples, il est resté à ce niveau. Où sont les solutions professionnelles ?
Mais nous écrivons plus à python que pour donner des outils pour écrire ces solutions professionnelles et pour développer notre kodobase.
C'est là qu'est l'erreur, il n'y a pas d'outils, pas de programmeurs de niveau approprié.
Ok, je vais dormir maintenant, je n'ai pas encore dormi. Bonne chance à tous.
Donc c'est une question de procédure...
Le procédural, c'est B, tout est élémentaire là-dedans, il y a juste plus d'occasions de se tirer une balle dans le pied.
Je pense que tu t'es trompé et que tu voulais dire fonctionnel. Mais ça n'a pas d'importance.
Si vous en recevez autant et régulièrement, vous pouvez commander un plugin pour chrome ;)
Non, ce n'est pas constructif, avec une telle logique vous pouvez commander un terminal pour vous-même (ou l'écrire vous-même), et beaucoup d'autres choses, et vous pouvez oublier complètement MQL.