Erreurs, bugs, questions - page 1572

 

CHART_SHIFT_SIZE ne fonctionne pas avec la tendance

void OnStart()
{
        ::ChartSetInteger( 0, CHART_SHIFT, true );
        for ( int i = 50; i >= 10; i-- )
        {
                ::ChartSetDouble( 0, CHART_SHIFT_SIZE, (double)i );
                ::ChartRedraw();
                ::Sleep( 100 );
        }
}
Dynamique comme dans test391.ex5 était attendu
Dossiers :
Test391.ex5  5 kb
 

Je ne peux pas télécharger mes fichiers depuis l'entrepôt via l'éditeur MT4 - je reçois une erreur.

2016.05.05 15:11:05.427 Storage failed to read http data (storage.mql5.com:443 read failed [12152])
 
Karputov Vladimir:

Je ne peux pas télécharger mes fichiers depuis l'entrepôtvia l'éditeur MT4- je reçois une erreur.

Et l'erreur ne concerne qu'un seul éditeur. Sur le même ordinateur, dans un autre dossier, MT4 et son éditeur ont facilement téléchargé les codes depuis le magasin.
 
Chers développeurs, veuillez introduire un espace de noms comme dans les langages C.
 

Combien de temps cela va-t-il durer, alors qu'à chaque fois que nous mettons à jour le build, le code ne compile plus ! Et s'il compile, il ne fonctionne pas de la même manière (ce qui est encore pire). Qui a besoin d'un tel langage de programmation ?

J'admire la patience d'A100 qui scrute scrupuleusement ces bugs, je suis tellement dégoûté.

Quelqu'un a suggéré ci-dessus que l'A100 devrait construire des tests pour vérifier le compilateur, mais il est amusant de constater que ce sont les utilisateurs qui doivent faire face à ce problème, et non les développeurs du compilateur.

Et surtout, tout cela est un travail de singe. Dépenser des années de travail acharné par une équipe de programmeurs (et donc beaucoup d'argent) et des années de travail acharné par les utilisateurs qui doivent réécrire leur code de nombreuses fois, et tout cela pour quoi ?Réinventer la roue appelée "le compilateur C++" (avec de légères modifications) au lieu d'utiliser simplement un compilateur open source (ou même d'en acheter un) et de le modifier pour répondre à ses besoins en quelques mois.

Mais non, les moyens simples ne sont pas pour nous... Il est bien plus important de se vanter d'avoir soi-même une bonne moustache, et chaque nouvelle construction nous permet de recréer petit à petit notre vélo.


Et en parlant de choses concrètes, je soutiens pleinement l'idée de A100 concernant la possibilité de désactiver l'optimisation, par exemple, pour faire des modes Debug et Release comme dans beaucoup de vrais compilateurs.

Personnellement, à cause de cette optimisation que vous vantez, je reste sur la build 1159 car mes projets se compilent en 2 secondes avec elle et en 20 secondes avec les builds suivantes. Un léger gain de performance ne résout rien. La plupart de mon temps est consacré au développement et à l'édition de programmes.

 
Alexey Navoykov:

Personnellement, je suis toujours sur la build 1159 à cause de cette optimisation que vous vantez, parce que mes projets se compilent en 2 secondes sur cette build et en 20 secondes sur les builds suivantes. Un petit gain de performance ne résout rien pour moi. La plupart du temps est consacré au développement et à l'édition de programmes.

Un projet avec 100Kb de code source se compile en moins d'une seconde en 1325 constructions. Une solide POO, beaucoup de fonctions virtuelles et de surcharges, des templates, des pointeurs, des modificateurs const (partout où c'est possible). Pas de DLL et d'OpenCL.

J'aimerais connaître la raison de vos décalages. C'est peut-être une contrainte qui aide le compilateur à optimiser rapidement. Je n'ai jamais rencontré de décalage. Veuillez me fournir le code source de kodobase qui est en train de ralentir.

Sur votre propre vélo sous la forme d'un compilateur. Prendre le projet de quelqu'un d'autre pour le réviser a ses avantages et ses inconvénients. Je pense qu'après avoir pesé le pour et le contre, j'aurais penché pour ma propre moto au départ. Bien sûr, lorsqu'une telle décision a été prise, personne ne pensait qu'il y aurait une telle embuscade sur le calendrier et les capacités du langage/compilateur. Une surestimation de leurs pouvoirs, ou peut-être une sous-estimation de la complexité de la tâche. Bien sûr, beaucoup d'argent a été investi dans le développement de la moto.

 
Anton Zverev:

J'aimerais connaître la raison de vos décalages. C'est peut-être la constance qui aide le compilateur à optimiser rapidement. Je n'ai jamais rencontré de décalage. S'il vous plaît, s'il vous plaît, donnez-moi un code source de kodobase qui ralentit.

Il a très probablement des fonctions gigantesques sous forme de bobines de texte.

L'optimiseur doit effectuer de nombreux passages sur ces fragments de code et les améliorer encore et encore. Il suffit de réduire la taille des fonctions pour que l'optimiseur s'accélère considérablement.

Vous devez absolument passer aux dernières versions, car nous améliorons constamment leur qualité et leur vitesse.

 
Renat Fatkhullin:

Il est probable que les fonctions géantes se présentent sous la forme de bobines de texte.

Un optimiseur doit effectuer de nombreux passages sur de tels morceaux, améliorant le code au fur et à mesure. Il suffit de réduire la taille des fonctions pour que l'optimiseur s'accélère considérablement.

Vous devez absolument passer aux dernières versions, car nous améliorons constamment leur qualité et leur vitesse.

C'est probablement aussi une question de bouts de texte. Moi, en tout cas, je n'en ai pas.

Les gagnants des olympiades internationales de programmation m'ont dit un jour que les fonctions ne devaient pas dépasser 20 lignes (conditionnelles). Si c'est le cas, l'architecture et l'algorithme ne sont pas optimaux.

En examinant les sources de Roman Yelizarov, on trouve une grande quantité de fonctions simples avec une imbrication sauvage. Et la plupart d'entre eux ont jusqu'à cinq lignes de long. Je suis moi-même une chenille comparée à cet amas intellectuel..... C'est pour ça que ce n'est pas si cool, même si j'ai essayé à mon époque.

Роман Елизаров
Роман Елизаров
  • www.lektorium.tv
Занимается профессиональной разработкой ПО для биржевой и брокерской деятельности более 12 лет. Координатор группы проектов в компании Devexperts, участвует в разработке торговой платформы thinkorswim. Эксперт по...
 

Lorsque vous passez le curseur sur des objets qui se chevauchent, la description de l'objet d'arrière-plan s'affiche au lieu de celle de l'objet supérieur. Ceci est prononcé sur les objets OBJ_EVENT. Je vois du rouge, mais la description est du bleu.

 
Anton Zverev:

Un projet source de 100Kb se compile en moins d'une seconde sur 1325 build. Une solide POO, beaucoup de fonctions virtuelles et de surcharges, de modèles, de pointeurs, de modificateurs const (partout où c'est possible). Pas de DLL et d'OpenCL.

J'aimerais connaître la raison de vos décalages. C'est peut-être une contrainte qui aide le compilateur à optimiser rapidement. Je n'ai jamais rencontré de décalage. Veuillez me fournir le code source de kodobase qui est en train de ralentir.

Eh bien, 100 Ko, c'est trop, non ? J'ai presque 1 Moctet. Toutes les mêmes choses que toi sont présentes ici, plus beaucoup de macros. Mais ce n'est pas une raison pour des délais aussi longs, d'autant plus que tout a été compilé presque instantanément dans la build 1159.

Je ne peux pas tester dans la build 1325 parce que le projet ne compile pas du tout et qu'un tas de bugs apparaissent, le tout le soir. Le camarade A100 a également signalé un tas de bugs dans la nouvelle build. Je n'ai aucune envie de perdre mon temps à chercher ces bugs, je vais attendre qu'ils publient la build fonctionnelle.

C'est pourquoi je vous ai parlé des décalages en me référant à la build 1241. Si vous avez l'occasion de la tester, essayez de la comparer avec la dernière build. Mais je doute que la nouvelle build puisse accélérer de manière significative. Bien au contraire, les développeurs de MT ne se soucient pas vraiment de la vitesse de compilation, ils veulent seulement extraire des nanosecondes supplémentaires du temps d'exécution afin de pouvoir ensuite faire des déclarations marketing sur la vitesse des programmes MQL comparable à celle du C++ (bien que seulement sur certains exemples abstraits).D'après ce que j'ai compris, ils ne se soucient pas de l'efficacité de l'optimisation, c'est-à-dire de savoir si le jeu en vaut le coût.

Je vais essayer de chercher le code source dans la base de code, mais je ne suis pas sûr de trouver un code similaire. Il doit s'agir d'un grand projet, alors que la plupart des petits projets sont disponibles en libre accès.