Erreurs, bugs, questions - page 2725

 
Alexey Navoykov:

Parce que c'est la chose la plus triviale et la plus primitive, qui peut difficilement être appelée optimisation. Je pense que tous les compilateurs le font par défaut, même en mode débogage. Qu'est-ce qui pourrait être plus facile ? Tout en analysant le code, surveiller l'accès aux variables. S'il y a une opération d'écriture répétée et qu'il n'y a pas eu d'opération de lecture, il faut couper l'entrée précédente.

Si le programme était totalement prévisible au moment de la compilation, il ne devrait pas du tout être exécuté au moment de l'exécution. Par définition, il devrait prendre un élément du monde extérieur et produire un résultat en fonction de cet élément, et c'est l'incertitude qui gêne l'optimiseur. Autre secret : les bibliothèques partagées sont liées à l'application en cours d'exécution, l'optimiseur ne peut rien y tracer. Il y a un million d'autres cas à rejeter. (Un million, Karl !)

Quelque part, j'ai oublié d'initialiser une variable ou j'ai ajouté un nouveau champ à une structure qui est devenue non initialisée dans tout le programme, et le programme continue. Le programme fonctionne de cette façon et de cette façon...

J'ai parfois multiplié par 2 au lieu de 3, appelé fn() au lieu de fn_(), ... . Si vos mains sont mauvaises, vous avez des problèmes.

Le langage C a été créé il y a longtemps, lorsque les capacités du matériel étaient très faibles, c'est pourquoi une grande partie du travail d'optimisation était laissée au programmeur. Si cela vous démange, pourquoi vous référez-vous au C et non à l'Assembler ? Encodez les systèmes de trading en Assembler. Je suis sûr qu'ils seront les plus rapides, peut-être même en avance sur le marché.

pour votre référence : les normes C (les plus récentes, ce ne sont pas les normes C++) : C11, C18, C2x est en cours de préparation. Au contraire, vous avez écrit ceci à cause de votre incompétence.
 
Vict:

Si le programme était complètement prévisible au moment de la compilation, il n'aurait pas du tout besoin d'être exécuté au moment de l'exécution. Par définition, il doit prendre quelque chose du monde extérieur et produire un résultat sur cette base, et c'est une incertitude qui gêne l'optimiseur. Autre secret : les bibliothèques partagées sont liées à l'application en cours d'exécution, l'optimiseur ne peut rien y tracer. Il y a un million d'autres cas à rejeter. Un million, Karl !)

Leséchanges de données avec le monde extérieur sont des cas particuliers et nécessitent des solutions particulières. Nous parlons de la programmation en tant que telle et des cas où le compilateur a la garantie de savoir que la variable n'est pas contrôlée de l'extérieur. Et cela doit être la grande majorité des cas. Sinon, vous avez une programmation purement système, qu'il est vraiment préférable de faire en C, ou encore mieux - en assembleur.

Quelque part multiplié par 2 au lieu de 3, appelé fn() au lieu de fn_(), . . Si vos mains sont tordues, vous avez des problèmes.

Si vous multipliez par 2 au lieu de 3, vous obtenez une erreur stable dans le programme qui est facile à diagnostiquer et à trouver. Et si la variable n'est pas initialisée, vous obtenez quelque chose qui fonctionne de temps en temps et qui ne fonctionne pas, avec des conséquences imprévisibles. En général, il est plutôt étrange que je vous explique de telles bases, en me présentant comme un programmeur expérimenté.

 
Alexey Navoykov:

L'échange de données avec le monde extérieur - ce sont des cas particuliers, et ils nécessitent des solutions particulières. Mais nous parlons de la programmation en tant que telle, et des cas où le compilateur est assuré de savoir que la variable n'est pas contrôlée de l'extérieur. Et cela devrait être la grande majorité des cas. Sinon, vous obtenez une programmation purement système, qui est vraiment mieux à faire en C, ou encore mieux - en assembleur.

La communication avec le monde extérieur est un élément essentiel de tout programme. Permettez-moi de répéter - sinon, cela peut être déterminé au moment de la compilation. Par exemple, le compilateur coupera-t-il l'initialisation ici ?

int i = 54;
if (read_socket() == SIGNAL) {
   fn(i);
}
i = 100;
...

// естественно, что никто не пишет такой бред:
int q = 3;
q = 7;
q = 9;
fq(q);

Évidemment, il n'a aucune idée de ce que read_socket() va retourner. L'ensemble du programme est "imprégné" par l'interaction avec le monde extérieur. + ajouter un appel aux modules externes ici... .

Si vous le multipliez par 2 au lieu de 3, vous obtenez une erreur stable dans le programme, facile à diagnostiquer et à trouver. Et avec une variable non initialisée, vous obtenez quelque chose qui fonctionne ou non de temps en temps, avec des conséquences imprévisibles. En fait, il est plutôt étrange que j'explique de telles notions de base à vous qui vous présentez comme un programmeur expérimenté.

Ecoutez, si vous voulez obtenir une erreur stable, il est très simple d'initialiser la pile :

int main() {
    if (true)
        int init_stack[10000] {0};
}

L'initialisation de la mémoire à partir de HIP est également un jeu d'enfant. Si nous tombons dans un piège de représentation, nous obtiendrons une décharge de noyau du tout.

Une fois encore, si les optimiseurs étaient très intelligents, ils assimileraient l'init par défaut à l'init par valeur avec l'insertion d'instructions d'initialisation par le compilateur comme cela est encore nécessaire dans certains C11, mais hélas. Personne ne force, si vous ne voulez pas, faites T val{} ; Fatigué d'expliquer des choses élémentaires.

 
Vict:

Une fois encore, si les optimiseurs étaient très intelligents, ils assimileraient l'init par défaut à l'init par valeur, le compilateur insérant des instructions d'initialisation selon les besoins dans certains C11, mais hélas. Personne ne force, si vous ne voulez pas, faites T val{} ; Fatigué d'expliquer des choses élémentaires.

Parce que, d'après ce que j'ai compris, la norme C++ décrit les règles de manière très formelle, sans contextualisation. C'est-à-dire que l'initialisation est soit toujours, soit jamais. Pour comparaison, en C#, vous pouvez déclarer une variable sans l'initialiser, mais plus loin dans le code, elle doit nécessairement être initialisée. C'est-à-dire que le compilateur analyse le code qui suit et pas seulement la commande en cours. Ceci est prévu dans les règles du langage. Mais la norme ne prévoit aucune analyse en C++. Ainsi, s'ils forcent l'initialisation, vous vous plaindrez que je veux tout contrôler et initialiser moi-même ! )

 
Alexey Navoykov:

Parce que la norme C++, telle que je la comprends, décrit les règles de manière très formelle, sans contextualisation. C'est-à-dire que soit vous initialisez toujours, soit vous n'initialisez jamais. En comparaison, en C#, vous pouvez déclarer une variable sans l'initialiser, mais plus loin dans le code, elle doit nécessairement être initialisée. C'est-à-dire que le compilateur analyse le code qui suit et pas seulement la commande en cours. Ceci est prévu dans les règles du langage. Mais la norme ne prévoit aucune analyse en C++. Ainsi, s'ils forcent l'initialisation, vous vous plaindrez que je veux tout contrôler et initialiser moi-même ! )

C'est juste que des solutions éprouvées sont mises en place et que si elles sont prêtes à fonctionner, ce qui entraîne souvent des frais généraux inutiles, personne ne les inclura. Par exemple, ils ont écrit dans la norme un MUST pour le compilateur pour faire l'élision de copie dans c++17.

 

Le sujet s'appelle "Bugs, bugs, questions".

S'il vous plaît, créez un sujet où vous discuterez de MQL vs C#, C++, et d'autres choses liées à la syntaxe, aux compilateurs et aux entraînements mentaux.

Vous encombrez le fil de discussion et les autres questions et messages des utilisateurs sont noyés dans votre discussion.

Ils me demandent où poser une question - on m'oriente ici et la réponse est : " Les oncles se disputent pendant une centaine de pages là, alors je ne vais pas m'en mêler, le reste n'a pas de sens... ".

 
const int DEFAULT_INT_VALUE   = 147;
input int thisIsAnInput       = DEFAULT_INT_VALUE;
'NoConstForInput.mq5' NoConstForInput.mq5 1 1
'DEFAULT_INT_VALUE' - constante attendue NoConstForInput.mq5 13 33
1 erreur, 0 avertissement 2 1

Bâtiments 2361 et 2390

 
Alain Verleyen:
'NoConstForInput.mq5' NoConstForInput.mq5 1 1
'DEFAULT_INT_VALUE' - constante attendue NoConstForInput.mq5 13 33
1 erreur, 0 avertissement 2 1

Bâtiments 2361 et 2390

#define  DEFAULT_INT_VALUE 147
 
Vict:

Vous voyez, si vous voulez obtenir une erreur stable, initialiser la pile est très facile :

L'initialisation de la mémoire à partir d'un HIP est également un jeu d'enfant. Si nous nous heurtons à un piège de représentation, nous obtenons un vidage complet du noyau.

Un dernier commentaire, s'il vous plaît ne soyez pas en colère contre les modérateurs ;)).

J'ai besoin de clarifier pourquoi la pile a des valeurs différentes d'un appel à l'autre. Il s'agit de protéger https://ru.wikipedia.org/wiki/ASLR, et vous n'avez même pas besoin d'analyser quoi que ce soit, comme je l'ai dit plus tôt. Dans mon cas - j'exécute le logiciel sous gdb (débogueur), ce qui le placera à la même adresse à chaque exécution, c'est-à-dire que la pile ne sera pas contaminée par des adresses de retour "aléatoires".

 
Artyom Trishkin:

Le sujet s'appelle "Bugs, bugs, questions".

S'il vous plaît, créez un sujet où vous discuterez de MQL vs C#, C++, et d'autres choses liées à la syntaxe, aux compilateurs et aux entraînements mentaux.

Vous encombrez le fil de discussion et les autres questions et messages des utilisateurs sont noyés dans votre discussion.

Ils me demandent où poser une question - je l'envoie ici et la réponse est : il y a des gars qui se disputent sur une centaine de pages - je ne vais pas m'en mêler, le reste n'a aucun sens ...

J'aimerais avoir un sujet consacré exclusivement aux bugs, alors que tout le monde jette tout ici.

Raison: