Deklarieren von Variablen hinter der Schleife oder innerhalb der Schleife? - Seite 8

Neuer Kommentar
 
Alexey Viktorov:
Nicht möglich, definitiv nicht richtig. Nur ein Beispiel: In der Schleife sehen Sie sich die offenen Positionen an. Sie erhalten ein Positionsticket und verwenden es, um andere Eigenschaften der Position zu erhalten. Es gibt zwei Varianten, entweder fügen Sie in jeder Funktion zum Abrufen der Positionseigenschaft PositionGetTicket(i) ein oder Sie schreiben sie einmal in eine Variable und verwenden sie. Aber wenn die Schleife verlassen wird, wird dieses Ticket nicht benötigt... Warum sollte diese Variable im Hauptteil der Funktion OnTick() oder, was noch interessanter ist, auf globaler Ebene deklariert werden?

Vielleicht habe ich mich nicht ganz richtig ausgedrückt....

Natürlich werden sie in OnTick() nicht benötigt. Ich weiß nicht, ob es richtig ist, Schleifen (und die dort benötigten Variablen) in Funktionen einzubinden?

P.S. Im Allgemeinen sollte jeder Proger wissen, wo eine Variable benötigt wird, und ihren Sichtbarkeitsbereich selbständig bestimmen......
 

Im Allgemeinen sind String Plus und MCL unterschiedlich. Bei µl handelt es sich um den Grundtyp, und es besteht eindeutig mehr Spielraum für Optimierungen. Daher kann es falsch sein, einen solchen achsenweisen Vergleich anzustellen. Obwohl ich für die Einheitlichkeit bei Pluszeichen bin - es sollte nicht da sein, also sollte es nicht in µl sein.

 
Vict:

Im Allgemeinen sind String Plus und MCL unterschiedlich. Bei µl handelt es sich um den Grundtyp, und es gibt eindeutig mehr Raum für Optimierungen. Daher ist ein solch plumper Vergleich möglicherweise nicht korrekt. Obwohl ich für die Einheitlichkeit bei Pluszeichen bin - es sollte nicht da sein, also sollte es nicht in µl sein.

Sprechen Sie Weißrussisch? Nein? Warum? Die weißrussische Sprache ist dem Altslawischen deutlich näher. Werden wir Russisch im Gegensatz zu Altslawisch sprechen? Offenbar ist es notwendig, die belarussische Sprache zu verwenden...

Ich werde wieder sauer sein... Aber noch einmal: SI und MQL sind unterschiedliche Sprachen! Trotz der Tatsache, dass das eine auf dem anderen basiert....

 
Сергей Таболин:

Vielleicht habe ich mich nicht ganz richtig ausgedrückt....

Natürlich werden sie in OnTick() nicht benötigt. Ich weiß nicht, vielleicht ist es richtig, Schleifen (und die dort benötigten Variablen) in Funktionen zu packen?

P.S. Und im Allgemeinen sollte jeder Proger wissen, wo er eine Variable benötigt und ihren Sichtbarkeitsbereich selbst bestimmen......

Hier sind die goldenen Worte.

Und ob eine Schleife in eine externe Funktion eingefügt wird, wenn sie nur einmal im Code verwendet wird, hängt davon ab, was die Religion erlaubt. Viele Leute halten sich jetzt an OOP und packen jede Kleinigkeit in Klassen oder Makros. Eine solche Mode ist populär geworden.

 
Alexey Viktorov:

Und die Schleife in eine externe Funktion zu packen, wenn sie nur einmal im Code verwendet wird, ist eine Frage der Religion.

Um ein Wort in Ihren Wortschatz aufzunehmen - diese Religion heißt SOLID

 

Für diejenigen, die an einen cleveren Compiler glauben. Ein Teil des Skriptcodes ist unten dargestellt.

Der Quellcode befindet sich in der angehängten Datei.

string predictor_names[]={"Time_RSI_ZZ_00","rPeresek_Down","Time_ZZ_02","Speed_1_ZZ_Proc_04"...}

struct sRule
  {
   int               predictor_id;
   bool              more_eq; 
   double            value; 
  };
//Лист дерева(набор правил)
struct sLeaf_r
  {
   int               rules_count;              //Сколько правил
   sRule             rules[32];  //Все правила листа
   double            result_leaf;//Результат листа
  };
//Количество всех листьев 164912
sLeaf_r           leaf_rs[]=
  {
     {3,{{0,0,21.5},{1,1,0.5},{2,0,15.5}},0.0},
     {5,{{0,0,21.5},{1,1,0.5},{2,1,15.5},{3,1,6.5},{4,0,-4.5}},-1.0},
......
......
//Очень много данных
  }

void OnStart()
  {

  }

Die Strukturen sind vollständig statisch, das Arrayleaf_rs kann vollständig verworfen werden.OnStart() ist leer. Infolgedessen beträgt die Größe der kompilierten Datei fast 2 Mbyte.

Dateien:
test_3.zip  418 kb
 
Igor Makanu:

Um Ihren Wortschatz zu erweitern - diese Religion heißt SOLID

Igor, wie viel älter ist dein Vater als ich? Ich denke, nicht mehr als 5 Jahre. Ist er noch in der Lage, seinen Wortschatz zu erweitern? Oder sind Sie zu jung? Suchen Sie nicht nach versteckten Bedeutungen in meinen Worten.
 
Alexey Viktorov:

........

Und die Schleife in eine externe Funktion zu packen, wenn sie nur einmal im Code verwendet wird, ist eine Frage der Religion. Viele Leute sind heutzutage OOP-affin und packen jede Kleinigkeit in Klassen oder Makros. Das ist jetzt en vogue.

Ich habe diese Frage schon einmal gestellt, aber nie eine Antwort erhalten. Gibt es für solche Fälle eine Standardmethode, um "ihre" Religion nicht zu verwenden, um eine Variable zu zerstören?

Ich persönlich mag es jedoch nicht, Variablen in einer Schleife zu deklarieren. Ich ziehe es vor, sie vorher anzumelden, aber wie kann ich sie danach vernichten? ...... Deshalb die Funktion. Nach dem Beenden des Programms werden die internen Variablen zerstört. (???)

Zu OOP kann ich nichts sagen. Ich verstehe nur nicht, warum das nötig ist ))))))) Veraltet, wahrscheinlich ))))))))))

 
Сергей Таболин:

Ich habe schon einmal gefragt, aber nie eine Antwort erhalten. Gibt es für solche Fälle eine Standardmethode, um eine Variable zu zerstören, damit nicht "ihre" Religion verwendet wird?

Ich persönlich mag es allerdings nicht, Variablen in einer Schleife zu deklarieren. Ich ziehe es vor, sie vorher anzumelden, aber wie kann ich sie danach vernichten? ...... Deshalb die Funktion. Nach dem Beenden des Programms werden die internen Variablen zerstört. (???)

Zu OOP kann ich nichts sagen. Ich verstehe nur nicht, warum das nötig ist ))))))) Veraltet, wahrscheinlich ))))))))))

Ich verstehe das nicht, oder doch?

if (true) {
        Type var;
        for (...) {
                var.use();
        }
}

Ich bezweifle, dass sie das nicht wussten.

 
Alexey Viktorov:
Igor, ist dein Vater nicht viel älter als ich?

1953-2008 Vater

1953-2019 Schwiegervater

1234567891011
Neuer Kommentar