Erreurs, bugs, questions - page 1335

 

J'ai un signal, la surveillance montre une décharge de 100 %, le compte est bon, je frappe au téléphone depuis trois jours, tant au Service Desk qu'au personnel de l'entreprise. Pas de réponse...

Comment résoudre le problème.... ?

 
Stanislav Olhovsky:

J'ai un signal, la surveillance montre une décharge de 100 %, le compte est bon, je frappe au téléphone depuis trois jours, tant au Service Desk qu'au personnel de l'entreprise. Pas de réponse...

Comment résoudre le problème.... ?

Vous ne devez pas retirer plus que ce que vous avez gagné, car la courbe du solde ne tombera pas à zéro.
 

J'ai écrit à "Innovations dans les favoris" et c'est le silence. Je vais écrire ici :

Windows 10 x64, Mozilla Firefox 39.0. Je ne peux pas envoyer d' images ou de fichiers joints sur mon compte personnel...

 
Karputov Vladimir:
Vous ne devez pas retirer plus que ce que vous avez gagné, car la courbe du solde ne tombera pas à zéro.

Le signal fonctionne depuis près de 4 mois, seulement des ajouts ribates, personne n'a retiré quoi que ce soit à cet endroit, tout était normal, croissance stable... Dans le terminal, les données sont normales et dans une autre surveillance en ligne .....

Capture d'écran de mybook jointe, tout y est normal.

Réponse du courtier, l'historique est stocké pendant 1 mois, mais alors il y a deux ou trois mois sur les signaux auraient été les mêmes ...

Dossiers :
Error.png  36 kb
 
C'est encore une fois une question de "privé". Les articulations continuent...
 

Chers développeurs !

L'indicateur Bands et l'indicateur iBands ont des lectures différentes. Dans l'indicateur Bands, l'écart-type est calculé à l'aide de la fonction StdDev_Func, tandis que dans l'indicateur iBands, il est calculé à l'aide de la méthode GetData. En comparant la façon dont le graphique est dessiné, nous pouvons voir une grande différence dans l'état des tampons responsables des niveaux de déviation. J'ai rencontré ce problème dans MQL4, peut-être est-ce le même dans MQL5.

 

Je n'y avais pas prêté attention auparavant, mais maintenant, en travaillant avec de grands tableaux d'objets de classe, j'ai remarqué une consommation de mémoire trop importante. Je l'ai vérifié par sizeof() et une classe absolument vide prend 16 octets. Et considérant que les classes ici sont gérées, nous ajoutons 8 octets supplémentaires par pointeur. Le total est de 24 octets. C'est trop cher.

J'ai regardé la documentation et j'ai vu ce que j'y ai trouvé :

объекты классов всегда имеют таблицу виртуальных функций, даже если в классе не объявлено ни одной виртуальной функции.

La question est de savoir pourquoi les classes simples (celles qui ne participent pas à l'héritage) ont besoin de la table des fonctions virtuelles, puisque tout est connu sur ces classes au stade de la compilation.

Il s'avère que les méthodes qu'ils contiennent sont appelées de la même manière que les méthodes virtuelles, c'est-à-dire qu'il y a une redirection supplémentaire de l'accès à travers la table. Et où est la louable optimisation du compilateur ? Comment pouvons-nous affirmer après cela une comparaison des performances avec C++ ?

 

Vous avez tort.

Si une méthode n'est pas décrite comme virtuelle, elle est appelée directement. En outre, il existe des optimisations pour supprimer la virtualité. Le destructeur est toujours virtuel, ce qui conduit à une table virtuelle.

L'expression "24 octets" est étrange : la référence à un objet ne fait pas référence à sa taille.

Les classes dans les langages gérés/sécurisés contiennent toujours des méta-informations, donc tout est raisonnable ici. Si vous voulez de la taille pure, utilisez des structures.

 
Renat Fatkhullin:

Le destructeur est toujours virtuel, ce qui donne lieu à une table virtuelle.

Alors pourquoi le destructeur ne devrait-il pas être optimisé ? C'est seulement à cause du destructeur que nous devons stocker 8 octets supplémentaires...

Le chiffre de 24 octets est une déclaration étrange - la référence à l'objet n'a rien à voir avec la taille.

Eh bien, je ne sais pas comment tout est mis en œuvre là-bas. Supposons que vous ayez un tableau d'objets :

CObj array[];

Le système stocke-t-il des références (pointeurs) pour chaque élément ?

Si vous voulez de la taille pure, utilisez des structures.

Mais vous ne pouvez pas prendre un pointeur sur une structure et cela réduit la commodité de son utilisation. C'est pourquoi vous devez parfois faire un choix douloureux... Si vous parvenez à réduire la taille de la classe, ce serait merveilleux. Et si vous avez aussi un pointeur sur la structure, tout ira bien).
 

Est-ce que tout le problème est dû aux 24 octets ? Désolé, essayez-vous d'écrire un logiciel de MT sur une calculatrice :) ?

Bien sûr, je m'excuse, mais en aspirant le problème du bout des doigts, vous bloquez les questions des autres, qui sont rarement remarquées par les représentants des développeurs.