Pourquoi y a-t-il si peu d'experts dans la base de données MQL5 ? - page 9
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
MyStruct" - la déclaration en avant n'est pas prise en charge
Et voilà. Comment se débarrasser des dépendances cycliques en architecture ?
Ne me dites pas qu'ils ne peuvent pas exister dans une architecture normale. Le seul moyen (béquille) est de repenser l'architecture en ajoutant un tas de classes de base inutiles, ce qui se transforme en véritable casse-tête à cause de l'absence d'héritage multiple, que vous avez rejeté, si j'ai bien compris, pour ne pas vous embêter à implémenter des dépendances en losange.
Mais vous auriez pu simplement implémenter la déclaration...
Eh bien, voyons si les "utilisateurs novices impartiaux" sont capables d'écrire "quelque chose de vraiment fondamental" dans MQL5, par opposition aux "programmeurs de systèmes professionnels".
Où ai-je écrit qu'ils ne peuvent pas, ma chère ? Oui, ils peuvent, mais ce sera quelque chose de grossier et de lourd.
Et voilà. Comment se débarrasser des dépendances cycliques en architecture ?
Nous ne permettons pas encore les descriptions en avant à cause du système de sécurité dans les cas d'utilisation complexes.
Nous avons un langage avec des contrôles très stricts à la fois à la construction et à l'exécution. Nous ne pouvons pas nous permettre d'avoir un code potentiellement fuyant à cause de contrôles relâchés. Le fait est que ces descriptions pourraient se trouver dans des bibliothèques complètement différentes et qu'il n'existe pas encore de moyen strict de contrôler l'utilisation dans de tels cas. En gros, il serait possible (cela ne peut pas être fait maintenant) de mener une attaque en bordant une classe de gauchers avec d'autres méthodes.
Il existe déjà une solution au problème des déclarations anticipées de dépendances externes et cycliques, mais nous la mettrons en œuvre après avoir lancé le terminal 64 bits (compilateur, terminal, éditeur et testeur). Nous avons déjà préparé une version publique 32/64 bits aujourd'hui - nous la publierons cette semaine.
Jusqu'à ce que vous commenciez à écrire vous-même un compilateur de code géré, en mettant directement l'accent sur la sécurité pour le terminal/l'environnement d'exécution (C#/Java n'a rien à voir avec cela, car ils ne sont pas sécurisés pour l'environnement), il est difficile de comprendre les raisons des actions des développeurs.
Eh bien, voyons si les "utilisateurs novices impartiaux" peuvent écrire "quelque chose de vraiment fondamental" dans MQL5 en dépit des "programmeurs de systèmes professionnels".
LeXpert:
Où ai-je écrit qu'ils ne peuvent pas, ma chère ? Oui, ils peuvent, mais ce sera quelque chose de grossier et de dur.
Et voilà. Comment se débarrasser des dépendances cycliques en architecture ?
Ne me dites pas qu'ils ne peuvent pas exister dans une architecture normale. Le seul moyen (béquille) est de redessiner l'architecture en ajoutant un tas de classes de base inutiles, ce qui se transforme en véritable casse-tête à cause de l'absence d'héritage multiple, que vous avez rejeté, si j'ai bien compris, pour ne pas vous embêter à implémenter des dépendances en losange.
Mais vous auriez pu simplement implémenter la déclaration...
Où ai-je écrit qu'ils ne peuvent pas, ma chère ? Oui, ils peuvent, mais ça va être une chose désordonnée et lourde.
Avec tout le respect que je vous dois, permettez-moi de dire que, à en juger par le forum 5, ce sont les experts qui murmurent et râlent le plus. Alors que les amateurs ordinaires hurlent et créent... Vous êtes un expert, alors soyez à la hauteur de votre niveau. Désolé, si quoi que ce soit.
C'est parce que tout est relatif,
Ceux qui n'ont jamais été au volant d'un Japonais à conduite à droite ne peuvent pas comprendre comment il est possible de changer la boîte de vitesses avec la main gauche.
Et un débutant s'en moque, il ne sait pas comment le décaler, à droite ou à gauche.
C'est parce que tout est relatif,
Ceux qui n'ont jamais été au volant d'un Japonais à conduite à droite ne comprennent pas comment il est possible de changer la boîte de vitesses avec la main gauche.
et un débutant s'en fiche, il ne peut pas le déplacer avec sa main droite ou sa main gauche.
Voilà, tu as tout gâché. :)
Quelqu'un qui est habitué à conduire une voiture étrangère avec une automatique ne peut pas se déplacer dans une shakha avec une boîte de vitesses détraquée. Mais celui qui a roulé en "classique" donnera une longueur d'avance à n'importe quel pro en "japonais", s'il conduit en "japonais". Je suis juste philosophe, je suis de bonne humeur... Remarquez que je n'ai pas dit "débutants", j'ai dit "amateurs".
Et voilà, tu as tout gâché. :)
Quiconque est habitué à conduire une voiture étrangère avec une automatique ne peut pas se déplacer dans une shakha avec une boîte de vitesses détraquée. Mais lui, qui roule dans une voiture "classique", donnera une longueur d'avance à n'importe quel pro dans une voiture "japonaise", s'il roule dans une voiture "japonaise". Je suis juste philosophe, je suis de bonne humeur... Remarquez que je n'ai pas dit "débutants", j'ai dit "amateurs".
Il existe déjà une solution au problème des déclarations anticipées des dépendances externes et cycliques, mais nous la mettrons en œuvre après le lancement du terminal 64 bits (compilateur, terminal, éditeur et testeur). Nous avons déjà préparé une version publique 32/64 bits aujourd'hui - nous la publierons cette semaine.
Jusqu'à ce que vous commenciez à écrire vous-même un compilateur de code géré, en mettant directement l'accent sur la sécurité pour le terminal/l'environnement d'exécution (C#/Java n'a rien à voir avec cela, car il n'est pas sûr pour l'environnement), il est difficile de comprendre les raisons de certaines actions des développeurs.
Voici la solution pour les constructeurs d'objets - aussi. Les raisons de les rendre inutiles ne sont pas claires.
Ils ne prennent pas de paramètres. Devrions-nous émuler les paramètres maintenant, en utilisant des variables globales pour le faire ?
Il n'existe aucun mécanisme permettant de signaler qu'un objet n'a pas été créé parce qu'une erreur irrécupérable s'est produite lors de la création (initialisation) de l'un des sous-objets. On peut ajouter une fonction d'initialisation à toutes les classes utilisées dans les sous-objets, et appeler les fonctions d'initialisation des sous-objets à partir de la fonction correspondante de la classe de l'objet lui-même, ce qui permettra de renvoyer un code d'erreur. Mais, premièrement, on devrait appeler cette fonction explicitement juste après la création de l'objet et après l'exécution de son constructeur "sous" (ainsi que la fonction de désinitialisation avant la destruction de l'objet par le destructeur), et, deuxièmement, lors de la modification de la classe principale, par exemple, lors de l'ajout d'un sous-objet, on pourrait facilement oublier d'inclure, et aussi au bon endroit, pour fournir la séquence appropriée, l'appel de la fonction d'initialisation du sous-objet ajouté depuis la fonction d'initialisation de la classe principale (la même chose s'applique à la fonction de désinitialisation). Après tout, pratiquement personne n'écrit un ouvrage entier d'un seul coup en partant de zéro. En conséquence, vous obtenez un code semi-écrit et non sécurisé.
Et la version déclarée comme telle il y a plus d'un mois n'incluait pas une solution aussi importante...
Vous suscitez beaucoup d'inquiétude en mélangeant les choses et en créant des problèmes qui ne vous concernent pas. Si tu as si peur d'écrire, alors abandonne.
Vous savez ce qui freine un mauvais danseur.
Avec tout le respect que je vous dois, permettez-moi de constater que ce sont les experts qui râlent et grognent le plus, à en juger par le 5e forum.
Il y a donc beaucoup de raisons de râler. Assez rapidement après la sortie de la première version bêta publique, j'ai commencé à écrire un système de trading. Presque immédiatement, les constructeurs normaux m'ont manqué, puis j'ai tout laissé tomber, car il était impossible d'obtenir un pointeur sans le créer explicitement avec l'opérateur new. Déjà à l'époque, j'avais suggéré la possibilité d'importer des classes, comme un ajout logique à la lumière de la complexité croissante des programmes et de leur structure (fichiers d'en-tête et de bibliothèque ou d'objets - dans certains cas seulement les déclarations requises, dans d'autres cas l'implémentation).
Les classes d'importation et les déclarations en avant résolvent complètement le problème du placement du code.
Un constructeur de copie simplifie le problème des constructeurs.
Le problème qui m'a fait arrêter est résolu. Il existe désormais une construction GetPointer(this). Tout le reste est (jusqu'à présent) soluble dans le langage, mais cela me gâche la vie.
Vous êtes l'expert, soyez approprié à votre niveau, parce que les connaisseurs cherchent des opportunités et les ignorants cherchent des raisons... Désolé, si quoi que ce soit.
Alors je continue à écrire. Parler ici n'interfère pas avec l'écriture du code. Pas besoin de t'excuser pour ça, je suis allé trop loin.