Erreurs, bugs, questions - page 1405

[A100]

Une question a été soulevée concernant l'ordre dans lequel la dll est chargée. Si elle est déclarée

#import "Test1.dll" //1
#import "Test2.dll" //2
#import

ils seront chargés dans l'ordre inverse, c'est-à-dire "Test2.dll" en premier. Il semblerait que cela ne fasse aucune différence. Il s'est avéré que cela fait une différence et dans certains cas (.dll nécessite un certain ordre de chargement) cela échoue : Sappot charger 'Test1.dll'.
La question est de savoir s'il faut changer l'ordre de chargement en direct, ce qui, du point de vue du code, serait plus logique - ou s'il faut s'assurer que cet ordre ne sera pas modifié à l'avenir (afin que le code ajusté à l'ordre inverse ne cesse pas soudainement de fonctionner). Pour le moment, nous devons adapter le code à l'ordre inverse.

[A100]

Construire 1191. Erreur de compilation : erreur de génération de code

Je ne sais même pas où chercher la raison. Mais dans le build 1162 tout est ok.

[Alexander]

A100:

Construire 1191. Erreur de compilation : erreur de génération de code

Je ne sais même pas où chercher la raison. Mais dans le build 1162 tout est ok.

Veuillez envoyer le code à servicedesk.

[A100]

Alexander:
Veuillez envoyer le code à servicedesk.

Il est largement distribué - je vais essayer de tout mettre dans un seul fichier.

Autre code - remarquez le temps - c'est probablement 20 fois plus grand

[Alexey Navoykov]

Ilyas:

Deux cas sont connus à ce jour :
1) Dans l'opération bool &= (expression bool)
2) Une virgule supplémentaire dans les séquences d'initialisation : val={ {...},{...}, }

Voici le premier cas - j'ai beaucoup d'opérations de ce type dans mon code. Je n'avais pas de problèmes auparavant lorsque j'avais la version 1159. Quand pouvons-nous espérer des corrections ?

[Ruslan Khasanov]

Erreur de génération de code

J'ai envoyé le code source à servicedesk : #1332553

[A100]

Alexander:
Veuillez envoyer le code à servicedesk.

erreur de génération de code

//build 1191
class A {};
class B : public A {};
void f( A& a ) {}
B *h() { return new B; }
void OnStart()
{
        f( h() );
}

Faites attention à ne pas vous retrouver comme je l'ai décrit dans la poche. Si vous pouvez le faire sans * comme cela fonctionne maintenant et a fonctionné avant dans l'exemple suivant

//build 1191
class A {};
void f( A& a ) {}
A *h() { return new A; }
void OnStart()
{
        f(  h() ); //нормально
        f( *h() ); //нормально
}

Si ce n'est pas le cas, il serait peut-être judicieux de tout annuler avant de commencer à utiliser l'innovation.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Bugs, bugs, questions

A100, 2015.08.26 10:35

En fait, vous proposez une entrée simple et directe

a = (b + c) - d*e + f;

remplacer par

*a = (*b + *c) - *d**e + *f;

Et c'est pour quoi ? Pour que vous puissiez écrire

bool c = *a == *b;

alors qu'une fonction spéciale peut être utilisée pour comparer des pointeurs à l'égalité, et que toutes les autres opérations arithmétiques (addition, soustraction, multiplication, etc.) avec des pointeurs n'ont aucune signification en soi, et ne sont intéressantes que dans la mesure où l'on peut les surcharger.

Ce n'est qu'en créant une base mathématique et une classe dérivée, en redéfinissant plusieurs (plutôt qu'une ou deux) opérations arithmétiques, en les rendant virtuelles puis en testant des expressions complexes (pas seulement a = b + c) sur leur base - ce n'est qu'ainsi que vous vous rapprocherez de la compréhension que tout est maintenant fait de manière OPTIMALE. En attendant, vous raisonnez à un niveau d'entrée.

Si la comparaison des pointeurs d'égalité fait l'objet d'une fonction distincte, il ne reste qu'un seul goulot d'étranglement ( !).

class A {};

A *a = b; //однозначно присвоение указателю значения
a = b;    //неоднозначно

qui doit néanmoins être traité comme une affectation et non comme un appel operator=(), car il n'existe actuellement aucune autre syntaxe pour affecter une valeur à un pointeur, tandis que a.operator=( b ) peut également être appelé explicitement

[Renat Fatkhullin]

A100:

Autre code - faites attention au temps - il doit avoir été multiplié par 20

Il s'agit d'un nouveau compilateur optimisant pour MQL5 (MQL4 ne l'a pas).

Vous devez payer pour un meilleur code cible avec un temps de compilation plus long. Certaines fonctions longues, composées de centaines de lignes, sont très difficiles à optimiser.

[Alexey Navoykov]

Renat Fatkhullin:

C'est ainsi que fonctionne le nouveau compilateur optimisant de MQL5 (il est absent de MQL4).

Pour obtenir un meilleur code cible, vous devez payer pour un temps de compilation plus long. Pour certaines longues fonctions comportant des centaines de lignes, il s'entête à optimiser.

Est-ce vraiment nécessaire ? Le prix de ce "code de haute qualité" n'est-il pas trop élevé ? Ralentir la vitesse de compilation des dizaines de fois pour un gain de performance relativement faible... D'autant plus que dans de nombreux cas, ce gain n'est pas très important, et allonger le temps de compilation est une torture pour le programmeur.

Ne serait-il pas préférable de créer des options de compilation "Debug" et "Release" ?

[Ilya Malev]

Alexey Navoykov:

Serait-il préférable de rendre les options de compilation "Debug" et "Release" ?

Oui, et ensuite obtenir des erreurs "Recompilez votre code de débogage" du testeur :)