Création d'une interface graphique pour les MQL en mode graphique. - page 11
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
Comment cela peut-il être encore le cas ?
Toutes les possibilités d'interopérabilité existent depuis longtemps. La prise en charge des DLL en général a été introduite en 2004.
Nos langages évoluent constamment et deviennent plus puissants et plus fonctionnels. Et l'écosystème est plus puissant que celui de n'importe qui d'autre.
Bien joué ! Et je suis sûr que ça ne peut que s'améliorer ! L'absence de rigidité est la meilleure caractéristique d'une équipe et du succès des développeurs ! ))
Bien joué ! Et je suis sûr que ça ne peut que s'améliorer ! L'absence de rigidité est la meilleure caractéristique d'une équipe et du succès des développeurs ! ))
Notre parti est notre timonier ! A bas la rigidité, place aux lignes de parti ! Allez ! !!
Bien joué ! Et je suis sûr que ça ne peut que s'améliorer ! L'absence de rigidité est la meilleure caractéristique d'une équipe et du succès des développeurs ! ))
Elle le sera, surtout lorsque nous gèlerons les versions 32 bits en septembre et que nous ne prendrons en charge que les versions de la plate-forme 64 bits.
Nous préparons maintenant une mise à niveau sérieuse du compilateur avec le transfert de certaines fonctions système dans les programmes MQL5, ce qui améliorera considérablement l'optimiseur et accélérera le code résultant des programmes MQL5.
Nous publierons des benchmarks de performance complets pour la comparaison avec C++, ainsi que le code source, afin que chacun puisse les vérifier par lui-même.
Comment cela peut-il être encore le cas ?
Toutes les possibilités d'interopérabilité existent depuis longtemps. La prise en charge des DLL en général a été introduite en 2004.
Nos langages évoluent constamment et deviennent plus puissants et plus fonctionnels. Et l'écosystème est plus puissant que celui de n'importe qui d'autre.
C'est à un niveau, désolé, quelque part comme Borland C++ à la fin des années 80. Donnez-nous une API complète avec des événements, des colonnes, implémentable comme un objet COM - le terminal n'aurait pas de prix.
Pourquoi pardonner ? Arrêtez de divaguer, s'il vous plaît.
Nous disposons d'un langage d'application puissant qui a montré, par l'écosystème que nous avons construit, que nous allons dans la bonne direction. Protéger les utilisateurs, les développeurs et nous-mêmes.
C'est une entreprise, pas une plateforme pour les populistes.
C'est un niveau, désolé, quelque part comme Borland C++ à la fin des années 80. Donnez-moi une API entièrement fonctionnelle avec des événements, des coliboxes, mise en œuvre comme un objet COM - et le terminal n'aura aucune valeur.
Bien qu'il devienne rapidement obsolète, il serait cool pour l'interface COM du terminal.
Seulement, cela ne correspond pas vraiment au temps réel :-(.
Pourquoi pardonner ? Arrêtez de divaguer, s'il vous plaît.
Nous disposons d'un langage d'application qui a montré par l'écosystème construit que nous allons dans la bonne direction. Protéger les utilisateurs, les développeurs et nous-mêmes.
C'est une entreprise, pas une plateforme pour les populistes.
Une interface COM pour le terminal serait cool, bien qu'elle devienne rapidement obsolète.
Mais cela ne correspond pas vraiment au temps réel :-(.
Nous le ferons, surtout lorsque nous gèlerons les versions 32 bits en septembre et ne prendrons en charge que les versions 64 bits de la plate-forme.
Nous préparons maintenant une mise à niveau sérieuse du compilateur, en déplaçant certaines fonctions du système dans les programmes MQL5, ce qui améliorera considérablement l'optimiseur et accélérera le code résultant des programmes MQL5.
Nous publierons des benchmarks de performance complets pour la comparaison avec C++, ainsi que le code source, afin que chacun puisse les vérifier par lui-même.
Renat, avant de désactiver x32, assurez-vous d'exécuter x64 sous votre nom d'hôte. Si vous n'en avez pas envie/besoin, dites-le moi aussi, afin que nous ayons le temps de réfléchir aux différentes options.
Et passons sur l'émotion féminine et allons-y avec les chiffres. Quelle charge le CPU doit-il supporter pour desservir ce terrible goulot d'étranglement ? Le moteur CLR tourne constamment dans Windows de toute façon et nous ne sommes pas les seuls à l'utiliser. Tout d'abord, c'est le vent lui-même qui l'utilise.
Tout le truc .net, # est une machine lente et maladroite, comment peut-on comparer du code géré et du code natif ?
"Et la machine CLR tourne constamment dans le vent de toute façon, nous ne sommes pas les seuls à l'utiliser. C'est surtout le vent lui-même qui l'utilise" - je compatis. En regardant la mémoire, voici ma consommation de mémoire par le système (linux) :
MiB Mem : 2998.9 total, 2411.2 libre, 38.9 utilisé, 548.8 buff/cache
38,9 Mo, inaccessible par Windows avec ses machines virtuelles, même si je n'utilise pas de swap :
MiB Swap : 8192.0 total, 8192.0 libre, 0.0 utilisé. 2474.6 avail Mem
Et vous pouvez dire sans émotions - en quoi les formulaires en C# sont meilleurs qu'en C++/FLTK, par exemple il y a un éditeur de formulaire - FLUID, bien que non nécessaire à mon avis, une simple fenêtre, une douzaine ou deux douzaines de chaînes ?