Ein Unter-Workshop zum Ausfüllen der FAQ (häufig gestellte Fragen). Helfen wir den Kameraden! - Seite 14

 
TheXpert:
Und es ist imho immer richtig, am Terminal nach den aktuellsten Informationen zu fragen.

Der Zustand der Aufträge (Array) wird genau dann abgefragt, wenn sie bearbeitet werden müssen.

Ich behaupte nicht, dass wir darauf verzichten können und dass wir uns nicht vorher eine Maske besorgen müssen. Und analysieren Sie bei Bedarf sofort den Status der Aufträge nach OrderSelect und filtern Sie unerwünschte Aufträge nach Magier, Symbol etc. heraus.

Sie argumentieren jedoch, dass es sich bei der Ticketreihe um eine UG handelt. Begründen Sie, warum.

-------------

Taras schlug die Option "ultra" vor, wenn alle Informationen über die Bestellung in ein Array geschrieben werden. Ich kann dem nur zustimmen, wenn ich der Meinung bin, dass diese Informationen nicht notwendig sind. Und in der vereinfachten Version werden zumeist nur Fahrkarten benötigt.

 
TheXpert:
Ich würde das nicht empfehlen. In den meisten Fällen ist eine Reihe von Fahrkarten gar nicht erforderlich. Und es ist imho richtig, immer die aktuellsten Informationen beim Terminal zu erfragen.
In einem Array erhalten Sie Informationen, die bedingt 1 Häkchen leben. Welche "frischen" Informationen brauchen Sie noch? Ich benutze meine eigene Praxis, wenn ich 2-4 Konten mit mehreren Währungen habe (ich meine die Demo), die es nicht erlauben, den Server für unnötige Dinge zu stören".

Und im Allgemeinen ist dies Ihr und mein persönlicher Standpunkt. Und der Nutzer muss immer die Wahl haben, welche Argumente sinnvoller sind. ;)

P.S. Und ich habe nur MEINE Antwort auf die in den FAQ gestellte Frage gegeben. :)

 

OK, IMHO UG, weil es IMHO richtig ist, die aktuellsten Bestellinformationen zu haben. Und IMHO kann man zu 95 % der Zeit auf eine Reihe von Aufträgen verzichten.

Wenn Sie etwas hinzufügen möchten, habe ich nur meine Meinung geäußert.

 

Sagen wir es mal so:

- Im Hinblick auf die Bequemlichkeit und die Modellabstraktion ist es besser, Arrays zu verwenden.
- Zur Beschleunigung der Arbeit - ohne Arrays.

Die Relevanz von Informationen hat damit nichts zu tun. In beiden Varianten - mit oder ohne Arrays - ist die Relevanz 100% frisch

 
sergeev:

-------------

Taras schlug die Option "ultra" vor, bei der alle Informationen über die Bestellung in das Array geschrieben werden. Ich kann dem nur zustimmen, wenn ich der Meinung bin, dass all diese Informationen nicht erforderlich sind. Und bei der vereinfachten Variante werden zumeist nur Fahrkarten benötigt.

Alexey, ich bin weit davon entfernt zu glauben, dass Sie mit der Einführung dieser Frage in den FAQ (Erhalt einer Reihe von Tickets für "eigene" Bestellungen) den Standpunkt vertraten, dass all diese Informationen nicht benötigt werden" - wie zum Herumspielen!
Oder habe ich etwas missverstanden?
 
TarasBY:
Alexey, ich bin weit davon entfernt, zu glauben, dass du mit der Einführung dieser Frage in die FAQ (eine Reihe von Tickets für "eigene" Bestellungen erhalten) die Position vertrittst, dass all diese Informationen nicht benötigt werden" - wie zum Spiel mit?!
Oder habe ich etwas missverstanden?

Aus irgendeinem Grund haben Sie zusätzlich zum Ticket alle Eigenschaften in den Begriff "Ihr Ticket" aufgenommen.

Aber ich habe Ihren Vorschlag definitiv als Erweiterung der Funktion "Nur ein Ticket" gemacht.

Sie wird auch häufig benötigt, insbesondere bei der Analyse und dem Vergleich historischer Auftragsdaten.

 
sergeev:


Sagen wir es mal so:

- Im Hinblick auf die Bequemlichkeit und die Modellabstraktion ist es besser, Arrays zu verwenden.
- Zur Beschleunigung der Arbeit - ohne Arrays.

Die Relevanz der Informationen hat damit nichts zu tun. In beiden Varianten - mit oder ohne Arrays - ist die Relevanz 100% frisch

Mit der zweiten Aussage ("um die Arbeit zu beschleunigen - ohne Arrays") würde ich nicht zu voreilig sein.
Die einfache Logik legt nahe, dass ein zusätzlicher Zugriff auf den Server für "frische Informationen" zusätzliche Zeit bedeutet. Außerdem kann es zeitlich nicht mit dem Abrufen der gleichen Informationen aus dem Array konkurrieren.
Es gibt einen Experten für Codegeschwindigkeit - Victor (Vinin), seine Meinung wäre interessant!
 
TarasBY:
Was den zweiten Punkt betrifft ("keine Arrays zur Beschleunigung der Arbeit"), so würde ich nicht zu voreilig sein, um kategorisch zu sein.
Die einfache Logik legt nahe, dass ein zusätzlicher Zugriff auf den Server für "frische Informationen" zusätzliche Zeit bedeutet. Außerdem kann es zeitlich nicht mit dem Abrufen der gleichen Informationen aus dem Array konkurrieren.
Es gibt einen Code-Performance-Experten Victor (Vinin), seine Meinung wäre interessant!

Noch einmal: Bei der Arbeit mit Auftragseigenschaften gibt es keinen Server zu kontaktieren!

Beim Handel ist die wichtigste Regel die Relevanz (um nicht zu der UG zu werden, über die TheXpert schrieb).
Wenn Sie also bei jeder Funktion auf die Auftragsliste verweisen und ein Array neu erstellen, wird dies definitiv zu einer Verlangsamung führen. Dadurch wird das Feld gefüllt.

So können wir Geld für die Array-Aktualisierung und wiederholte OrdeSelect (bereits auf dem Ticket) sparen.

Bei 1-2 Arbeitsaufträgen ist die Anordnung nicht kritisch, aber bei 50-100 Aufträgen ist sie schon bedeutend.

 
Ich will noch mehr sagen: Auf der Grundlage meines früher geäußerten Konzepts der "Verringerung der Serverlast" (ich würde es genauer "Optimierung der Codegeschwindigkeit" nennen) hole ich mir alle Preise in einem separaten Array (wenn ich sie für mehrere Tools benötige) am Anfang von Start(). Und wenn ich eine Handelsoperation durchführen muss, führe ich RefreshRates() aus.

Ich will diesen Ansatz niemandem aufzwingen, ich sehe nur die Logik dahinter und verwende dieses Prinzip in meinen Entwürfen.

P.S. Dies soll keinen Streit über dieses Thema auslösen, sondern ist lediglich ein Argument zu dem oben Gesagten.

 
sergeev:

Wenn Sie also bei jeder Funktion auf die Auftragsliste zurückgreifen und das Array neu erstellen, wird dies definitiv zu einer Verlangsamung führen. Wegen der Füllung des Arrays.

Habe ich das gesagt? Das Array der Ticks wird einmal pro Tick gefüllt, wenn der EA mit jedem Tick arbeitet. Und dann statt der üblichen Stichprobe:
    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }
Ich wähle aus
for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

oder:
    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }
je nachdem, wie ich mich mit dieser oder jener Funktion am wohlsten fühle.
Ich stimme zu, dass sich die Rationalität dieses Ansatzes eher in Systemen mit mehreren Währungen bemerkbar macht, die eine Minderheit darstellen.
Grund der Beschwerde: