Au revoir le robot - bonjour le marasme - page 11

Nouveau commentaire
 

Concernant le masquage du nom de la variable :

simpleton a déjà écrit sur le compilateur intel, situation similaire avec gcc et clang. Lors de la compilation dans un mode très strict (en termes de présence de messages) :

gcc(clang) -Wall -Wextra

le compilateur ne se plaint pas de ce problème. Les plaintes relatives à la dissimulation sont activées par une option distincte -Wshadow. C'est-à-dire que la vérification elle-même n'est pas difficile sur les compilateurs c++ (sauf MSVC). Mais je n'ai pas vu d'ide (basé sur gcc, par exemple, qt creator, code blocks ...) où -Wshadow est activé par défaut.

Pourquoi ? Probablement parce que pour la plupart des gens, l'utilité de ce message est discutable.

 
Pavlick:

Concernant le masquage du nom de la variable :

simpleton a déjà écrit sur le compilateur intel, situation similaire avec gcc et clang. Lors de la compilation en mode très strict (en termes de présence de messages) :

Vous semblez confondre le trompeur "mode compilateur strict" et le travail réel des analyseurs statiques, puisque vous ne les avez jamais utilisés.

Le compilateur termine la compilation en 1 à 2 minutes, alors que les analyseurs travailleront pendant plusieurs heures (PVS Studio) ou des dizaines d'heures (CPP Check) sur le même code. D'où la différence de qualité et de profondeur des résultats.

 

Salutations à tous.

Cela fait presque un an que la "folie" et le marasme des innovations dans MQL4 n'ont pas cessé. "Mais c'est toujours là ! (с).

Avant, ils reprochaient à "Metaquotes" la mauvaise langue, maintenant ils leur reprochent l'excès d'"eau". Les problèmes n'ont pas diminué.

Je peux ajouter ce qui suit de ma part.

Pour les traders, les non-programmeurs et les programmeurs novices, un algorithme et un code simples peuvent être mis en œuvre.

Si vous avez une grande base d'indices, de hiboux, etc. qui ne compilent pas dans les nouvelles versions, il est logique de regarder de près et de "secouer vos coffres". Veillez à conserver les éléments les plus utiles et ne perdez pas de temps à les réécrire et à les déboguer pour les nouvelles versions.

Les vrais programmeurs expérimentés ou ceux qui veulent le devenir, suivent toujours les innovations, les bugs et les problèmes sont leur pain. C'est l'écriture d'un code sans bogues qui compte comme une bonne programmation. Si vous n'avez pas l'énergie, le temps, la possibilité ou le désir de saisir toutes les innovations des "Metakvot", utilisez la langue que vous maîtrisez. Les DLL n'ont pas été supprimées. Introduisez vos propres algorithmes.

 
Andrei01:

Les environnements de test sont largement utilisés dans les produits logiciels pour la vérification fonctionnelle des conceptions de puces logicielles, où les exigences en matière de qualité du code sont très élevées. En outre, un shell fonctionnel fait partie intégrante de tout développement de code de conception de puce. D'un autre côté, de nombreux programmeurs n'ont même pas l'idée de tels tests fonctionnels lorsqu'ils rédigent des projets logiciels habituels, car écrire de tels tests à partir de zéro peut prendre plus de temps que la rédaction du projet lui-même et ne se justifie que lorsqu'il est nécessaire d'écrire un code de haute qualité ou qu'il existe de nombreuses versions du même projet. D'autre part, un environnement de test habilement écrit permet de gagner un temps considérable en matière de débogage et de vérification du code.

L'analyse statique est également utilisée, mais uniquement comme un contrôle syntaxique initial et très superficiel.

Les environnements de test sont des environnements de test. Un environnement de test est "confiné" au produit qu'il teste.

Je voulais parler des outils généraux - ceux qui n'ont "aucune idée" du produit analysé et qui peuvent donc analyser et trouver des problèmes dans n'importe quel produit.

 
Renat:

Simplet, quelle absurdité.

"Quelle absurdité" semble impliquer un décalage complet d'attitudes.

Renat:

Ce n'est que lorsque vous arriverez au niveau du contrôle total de la qualité que vous le comprendrez. Mais en attendant, tant que vous restez au niveau de perception d'un seul programmeur égoïste, vous continuerez à penser "il est raisonnable de ne pas me contrôler, que le contrôle se fera par des utilitaires séparés jamais exécutés".

Alors pourquoi le "contrôle total de la qualité" permet-il un niveau de contrôle de la qualité aussi bas ?

Par exemple :

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

Le constructeur est appelé lorsqu'un objet est créé dans la méthode2 :

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

Pourquoi tout va bien quand un objet est créé dynamiquement, c'est-à-dire que le constructeur privé est disponible à partir de la méthode de l'objet, mais quand l'objet est créé automatiquement, le constructeur privé est soudainement indisponible ?

Personnellement, j'ai renoncé à faire quoi que ce soit d'un peu plus compliqué que simple dans MQL, car c'est très difficile pour moi : je me heurte toujours à quelque chose qui ne fonctionne pas.

Mais je n'ai pas de tels problèmes avec les compilateurs C/C++.

Et le problème "il est raisonnable de ne pas me contrôler, que le contrôle soit séparé ne jamais courir les services publics" est directement lié à la psychologie. Ici, la psychologie doit être corrigée pour que le programmeur puisse se forcer, plutôt que d'essayer d'adapter la technologie à la psychologie afin de contourner cette dernière.

Je n'invente rien, certains utilitaires sont utilisés avec succès sur une base régulière devant moi, et le résultat de leur travail est également utilisé avec succès plus tard pour éliminer les bugs.

Renat:

Les problèmes sont combattus, mais en parallèle, nous ajoutons et améliorons beaucoup de choses.

Peut-être les priorités sont-elles déplacées vers l'ajout et l'amélioration au détriment de la qualité. Mais alors, il ne s'agit plus d'un contrôle total de celui-ci.

Renat:

Vendredi, il y aura une version de MT4 avec de nettes améliorations dans la vitesse d'exécution et les tests.

Dans ce cas, je veux dire la disponibilité de constructeurs privés à partir de méthodes d'objets, non seulement pour le cas de la création dynamique d'objets - y aura-t-il des améliorations dans l'opérabilité du langage ?

Renat:

Contrairement à C++, MQL est absolument sûr (s'il n'y a pas de sortie vers la dll) en raison du rejet des liens bruts, et en général - c'est un langage géré.

Ok, supposons que "C++ est dangereux et suicidaire" et que "MQL est absolument sûr".

Pourquoi prendrait-on comme base pour MQL un langage qui est si loin du critère de sécurité de ce que l'on voulait, c'est-à-dire créer un langage "absolument sûr" basé exactement sur le langage "dangereux et suicidaire" ?

 
Pavlick:

OK ?


Bonjour, Pavlik !

C'est encore moi, Panza !

J'ai testé votre code pour appeler le script sur différents mt4.

et j'ai découvert des choses étranges !

Votre code fonctionne bien sur MT4 build 670 by Pepperston.

(Australie), mais il ne veut pas fonctionner sur MT4 build 670 Alpari !

user32.dll estappelébizarrementsur alpari!

Les 2 premières dlls sont appelées (bien que ce ne soit pas dans le code !)

puisuser32.dllest appelé,mais il est jeté dans une bibliothèque !

mais vous devez aussi l'appeler depuis la bibliothèque !

Il semble qu'Alpari ait du mal à répondre à l'appel.

c'est-à-dire qu'il y a une interférence évidente du code !

Je joins 2 photos pour comparaison !

je souhaite le succès !

Panza

oo-bild zu gross !

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

















 
simpleton:

"Quelle absurdité" - cela signifie apparemment un décalage complet des positions.

Cela signifie que quelqu'un est sciemment plus expérimenté pour diriger le lancement de plusieurs produits logiciels sur un marché concurrent.


Pourquoi le "contrôle de la qualité totale" permet-il un niveau de contrôle de la qualité aussi bas ?

Il n'est pas nécessaire de passer d'une discussion sur les principes généraux du contrôle de la qualité aux défauts spécifiques d'une solution particulière. Une telle méthode est inacceptable, car il est toujours possible de trouver un défaut dans n'importe quel produit.

Par exemple :

Le constructeur est appelé lorsqu'un objet est créé dans la méthode2 :

Pourquoi tout va bien quand un objet est créé dynamiquement, c'est-à-dire que le constructeur privé est disponible à partir de la méthode de l'objet, mais quand un objet est créé automatiquement, le constructeur privé est soudainement indisponible ?

C'est juste une conséquence de la surprotection"la méthode de classestatique n'a pas le droit d'entrer dans le contenu de la classe". Dans ce cas, cependant, le contrôle d'accès doit être assoupli.

Personnellement, j'ai renoncé à faire quoi que ce soit d'un peu plus complexe que simple dans MQL, car c'est très difficile pour moi : je me heurte toujours à quelque chose qui ne fonctionne pas.

Donnez-moi un exemple concret, et pas un cas de "j'ai tordu les choses exprès, fermé les accès et ensuite commencé à faire appel à un comportement limite".


Je n'ai pas de tels problèmes avec les compilateurs C/C++.

Les problèmes y sont d'un autre ordre. Et ils sont sciemment supérieurs de plusieurs ordres de grandeur si l'on tient compte du fait que l'on n'utilise pas d'analyseurs statiques.


Et le problème "il est raisonnable de ne pas me contrôler, que le contrôle soit séparé ne jamais courir les services publics" est directement lié à la psychologie. Ici, la psychologie doit être corrigée pour que le programmeur puisse se forcer, plutôt que d'essayer d'adapter la technologie à la psychologie afin de contourner cette dernière.

Je n'invente rien, des utilitaires individuels sont régulièrement utilisés avec succès sous mes yeux, et le résultat de leur travail est également utilisé avec succès par la suite pour éliminer les bugs.

Peut-être les priorités sont-elles déplacées vers l'ajout et l'amélioration au détriment de la qualité. Mais alors, il ne s'agit plus d'un contrôle total de celui-ci.

C'est déjà un simple jeu de mots. Votre position a déjà été clairement exposée plus tôt : "Je ne peux pas être contrôlé", donc oui, "devant quelqu'un, quelque part, on consomme, mais personne ne se tient au-dessus de moi avec un bâton et je ne consomme pas".


Et les améliorations en termes d'opérabilité du langage - dans ce cas, je veux dire la disponibilité d'un constructeur privé à partir de méthodes d'objets, non seulement pour le cas de la création dynamique d'objets - seront-elles déjà présentes ?

Et vous aimez fabriquer des dispositifs de déclenchement délibérés dans vos programmes "simples" : "Je vais cacher le constructeur en privé, créer une méthode statique et ensuite l'utiliser pour ciseler le constructeur caché" ?


Ok, disons que "C++ est dangereux et suicidaire" et que "MQL est absolument sûr".

Pourquoi prendrait-on une langue si éloignée du critère de sécurité comme base du MQL, c'est-à-dire créer une langue "absolument sûre" sur la base de la très "dangereuse et suicidaire" ?

Êtes-vous capable de trouver une "base différente" pour un langage générique ?

Pour que tous les autres programmeurs puissent recevoir le langage et commencer à écrire dedans avec plaisir après quelques heures et ne pas le jeter avec dégoût et réprimande ? Les traders ont regardé l'Easy Language et l'ont jeté, alors que MQL4/MQL5 sont utilisés et développés avec grand plaisir.

Les langages les plus couramment utilisés sont basés sur les principes de base des constructions comme en C/C++. Nous avons donc pris le cadre bien connu, supprimé les choses les plus dangereuses avec les liens, ajouté la GDN et obtenu un langage sûr et sécurisé.

Par conséquent, nous sommes en hausse et les concurrents vont dans la mauvaise direction, mais moins chère, comme ils le pensent.

 
Renat:
Cela signifie que quelqu'un a plus d'expérience pour diriger sciemment le lancement de plusieurs produits logiciels sur un marché concurrent.

Au fait, à propos de l'expérience de gestion. Il y a 5 ans, nous nous disputions sur le forum mql5 à propos des perspectives de MT5, je disais alors que le temps nous le dira. Cinq ans ont passé et nous constatons que la communauté a rejeté MT5. L'expérience en matière de gestion ne garantit pas contre les erreurs. Même si l'on a de l'expérience dans un domaine, on peut toujours faire des erreurs. Au sujet du marché concurrentiel, ou plutôt des concurrents, à la toute fin.

Toutefois, dans ce cas, il ne s'agit pas de l'expérience de nombreux logiciels, mais de la qualité du produit et, en particulier, du compilateur et des outils et méthodes permettant d'atteindre une qualité élevée.

Renat:
Nous ne devrions pas déplacer la discussion des principes généraux de contrôle de la qualité vers les défauts spécifiques d'une solution particulière. Vous ne pouvez pas le faire car vous êtes toujours susceptible de trouver tous les défauts de chaque produit.


C'est juste une conséquence de la surprotection "la méthode de classe statique n'a pas le droit d'entrer dans le contenu de la classe". Bien que dans ce cas, nous devons relâcher le contrôle d'accès.

Je ne traduis pas, les principes généraux, la théorie - pas pour la théorie elle-même, mais pour l'application dans la pratique. Vous ne trouverez pas de "défauts" aussi graves dans les mêmes compilateurs C/C++.

Si vous dites que dans ce cas "une méthode de classe statique n'a pas le droit d'entrer dans le contenu de la classe", alors pourquoi dans le cas de la création d'un objet dynamique a-t-elle déjà ce droit ?

Qu'en est-il du fait qu'une méthode non statique se comporte exactement de la même manière ?

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

Mêmes erreurs :

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

OK, considérons une interdiction de "monter dans le contenu de la classe" :

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

L'objet b est créé en appelant le constructeur copy, puis une affectation est effectuée en appelant l'opérateur =, la méthode f() est appelée, et tous ces constructeurs, opérateurs et méthodes sont privés, ce qui signifie que la méthode statique method() est autorisée à "caresser la classe" :

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Examinons un autre exemple, très proche du premier :

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Erreur de compilation, - le constructeur et le destructeur sont tous deux indisponibles :

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Maintenant, sans rien changer du tout, initialisez la variable a avec une valeur différente de la valeur par défaut dans le constructeur :

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Maintenant l'exemple se compile et s'exécute :

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

Comment une méthode statique est-elle devenue soudainement autorisée à "pénétrer dans le contenu de la classe" ?

Il est assez évident qu'il ne s'agit pas d'une "surprotection" dans ce cas, mais d'un bug trivial. Le contrôle total de la qualité est une déclaration plutôt bruyante, mais les faits sont des choses têtues.

Renat:
Donnez un exemple concret, pas un cas de "j'ai fait exprès de tordre les choses de cette façon, j'ai fermé les accès, puis j'ai commencé à faire appel au comportement limite".

S'il vous plaît, un singleton classique, à savoir le singleton Myers décrit dans la section de l'exemple C++ du lien :

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

Il se traduit même en MQL4++ avec la nouvelle fonctionnalité ouverte :

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

Il compile et exécute :

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

Toute tentative de créer un objet autrement qu'en appelant OnlyOne::Instance() entraînera une erreur de compilation.

Et à propos de "j'ai délibérément déformé les choses, fermé des accès, puis commencé à faire appel à des comportements limites" - est-ce que quelque chose a été utilisé de manière inappropriée ?

Il y a des mécanismes dans la langue - j'ai le droit de l'utiliser comme je veux dans les limites autorisées par la langue. C'est du moins ce qui se passe avec les compilateurs C++.

S'il y a des erreurs dans la mise en œuvre de la langue, eh bien, oui, des erreurs. Vous parlez de contrôle total de la qualité - donc, en pratique, éliminez les erreurs de mise en œuvre dans le compilateur MQL4++, de sorte que les erreurs soient presque aussi difficiles à trouver que dans les compilateurs C++, puisque vous avez un tel contrôle. Je continue de penser que l'analyseur syntaxique ne permettra pas de se débarrasser d'erreurs comme celles que j'ai démontrées.

Renat:
Et aimez-vous mettre des pas délibérés dans vos programmes "simples" "cacher le constructeur en privé, créer une méthode statique et ensuite ciseler le constructeur caché à partir de celle-ci" ?

Il ne s'agit pas de ce que j'aime ou n'aime pas. Il y a un outil. Pourquoi devrais-je refuser d'utiliser toutes ses capacités ?

Ce n'est même pas "j'aime ça" dans ce cas. C'est Myers, d'ailleurs, qui l'aime tant. Et d'une manière ou d'une autre, personne n'essaie de l'accuser d'essayer de "faire délibérément trébucher" les compilateurs C++.

Renat:
Êtes-vous en mesure de proposer un "cadre différent" pour les langages génériques ?

Pour que tout autre programmeur puisse recevoir un langage et commencer à écrire dedans avec plaisir après quelques heures et ne pas le jeter avec dégoût et réprimande ? Les traders ont regardé le langage facile et l'ont jeté, alors que MQL4/MQL5 sont joyeusement utilisés et développés.

Les langages les plus répandus sont basés sur les principes de base des constructions comme en C/C++. Nous avons donc pris un cadre familier, supprimé les éléments les plus dangereux avec les références, ajouté la gestion des droits numériques et obtenu un langage sûr et sécurisé.

En conséquence, nous sommes au sommet, tandis que les concurrents vont dans la mauvaise direction, mais moins cher, comme ils le pensent.

Ce n'est pas une tâche facile et ne peut être résolue d'emblée. Vous devez faire des efforts, et pas des moindres. La grande majorité des utilisateurs de MQL ne sont pas des programmeurs. Il faut en tenir compte dans la conception de la langue. Mais la tâche peut être résolue, j'en suis sûr.

Il suffirait d'ajouter quelques structures à l'ancien MQL4 et de nettoyer certaines choses comme les priorités des opérations, comme cela a été fait pour MQL4++ et ce serait un compromis raisonnable. Le succès de MT4 est dû en grande partie à l'absence d'"intelligence" du langage. Ce n'est pas le cas aujourd'hui. Et il y a beaucoup plus d'erreurs dans l'implémentation du compilateur, car MQL4++ est beaucoup plus compliqué que l'ancien MQL4 et l'équipe de développement n'a guère changé.

Renat:
Par conséquent, nous sommes à la hausse alors que nos concurrents vont dans la mauvaise direction, mais moins cher, comme ils le croient.

Là, je suis d'accord avec vous, mais je pense que c'est surtout parce que les concurrents font des choses incompréhensibles.

 
Renat:
Cela signifie que quelqu'un est sciemment plus expérimenté pour diriger la sortie de nombreux produits logiciels sur le marché concurrent.


Nous n'avons pas besoin de passer de la discussion des principes généraux du contrôle de la qualité aux défauts spécifiques d'une solution particulière. Une telle méthode est inacceptable, car il est toujours possible de trouver un défaut dans n'importe quel produit.

C'est juste une conséquence de la surprotection "une méthode de classe statique n'a pas le droit d'accéder au contenu de la classe". Bien que dans ce cas, vous devez relâcher le contrôle d'accès.

Donnez-nous un exemple concret, pas un cas du type "j'ai tout tordu exprès, j'ai verrouillé les accès, puis j'ai fait appel au comportement limite".


Les problèmes y sont d'un autre ordre. Et ils sont sciemment supérieurs de plusieurs ordres de grandeur si l'on tient compte du fait que l'on n'utilise pas d'analyseurs statiques.


C'est déjà un jeu de mots. Votre position a déjà été clairement exposée précédemment "Je ne peux pas être contrôlé", donc oui "devant quelqu'un, quelque part en train de consommer, mais personne ne se tient au-dessus de moi avec un bâton et je ne consomme pas".


Vous aimez mettre des pas délibérés dans vos programmes "simples" "cacher le constructeur en privé, créer une méthode statique et ensuite ciseler le constructeur caché à partir de celle-ci" ?


Êtes-vous en mesure de proposer une "base différente" pour les langues de commonplan ?

Pour que tous les autres programmeurs puissent recevoir un langage et commencer à écrire dedans avec plaisir après quelques heures et ne pas le jeter avec dégoût et réprimande ? Les traders ont regardé le langage facile et l'ont jeté, alors que MQL4/MQL5 sont joyeusement utilisés et développés.

Les langages les plus répandus sont basés sur les principes de base de la construction comme en C/C++. Nous avons donc pris le cadre bien connu, supprimé les éléments les plus dangereux des liens, ajouté la gestion des droits numériques et obtenu un langage sûr et sécurisé.

En conséquence, nous sommes au sommet, tandis que nos concurrents vont dans la mauvaise direction, mais moins cher, comme ils le pensent.

 

Bonjour aux membres du forum !

Je voudrais profiter de la présence de Renate sur ce fil.

J'aimerais faire quelques suggestions pour améliorer MT4 !

Tout le monde sait qu'avec le temps, MT4 fonctionne de moins en moins bien.

alors il n'obéit pas à la souris - finito !

Nous devons passer à un nouveau MT4 et supprimer

tous les éléments (indicateurs, eXperts) !

C'est un travail de tous les jours !

Bien que maintenant il existe des programmes de réparation pour DL, DRIVER, etc...

Pourquoi ne pas faire un compilateur pour MT4 ?

Vous devez avoir 2 МТ4 (un valide et l'autre en état de marche).

et les comparer périodiquement et corriger les erreurs dans le MT4 en fonctionnement.

La deuxième suggestion est de construire non seulement des graphiques de prix, mais aussi des graphiques d'activité.

produire des graphiques de croissance du prix multiplié par le volume !

de cette façon, vous seriez immédiatement visible ce qui se passe (négociation réelle ou encaissement).

stopes)

Je pense que c'est facile pour les personnes ayant un haut niveau de compréhension !

Panza

1...45678910111213141516
Nouveau commentaire