Fehler, Irrtümer, Fragen - Seite 1963

Neuer Kommentar
 
A100:
Wenn der Unterschied so groß ist, warum lassen sich dann beide Varianten normal in C++ kompilieren?

In diesem Fall gibt es überhaupt keine Autorität für C++, da ich meine Schlussfolgerungen auf Logik aufgebaut habe. Oben habe ich das Beispiel mit einer Dereferenz überarbeitet.

Alles, was Sie tun müssen, ist, eine solche Ersetzung vorzunehmen

// typedef void (*fn)();
typedef void (*fn123)();

Wie die Dereferenzierung wird völlig anders sein. Sie können den Compiler bitten, "schlauer als ein Narr" zu sein und so zu handeln, wie er es in C++ tut. Aber diese Lösung ist wirklich fragwürdig.

D.h. eine solche "Hilfe" kann im Compiler implementiert werden, aber der Unterschied in den Ansätzen wird aufgezeigt.

 
A100:
ist in Ordnung. Welchen Unterschied macht das?

Offensichtlich wird f bei einer einfachen Übergabe an den Compiler nicht als Zeiger auf eine Funktion angesehen.

 
Комбинатор:

Bei der Übergabe an den Compiler wird f offenbar nicht als Zeiger auf eine Funktion verstanden.

Ich stimme zu (es ist einfach und es gibt im Grunde keinen Unterschied)
 
Комбинатор:

Bei der Übergabe an den Compiler wird f offenbar nicht als Zeiger auf eine Funktion verstanden.

Und das sollte es auch nicht, zumindest nicht aus Gründen der Zweideutigkeit.

typedef void (*fn)();

template<typename T>
void g( T Value ) { Print(typename(Value)); }
void f() {}

void g( fn Value ) { Print(typename(Value)); }
void OnStart()
{
  g( f ); // void(*fn)()

  int f = 0;  
  g( f ); // int
}
 
fxsaber:

Und das sollte es auch nicht, schon allein wegen der Zweideutigkeit

Im ursprünglichen Beispiel gab es keine solche Zweideutigkeit... du hast es geschaffen... und Sie haben es benutzt, um alles zu erklären.
 
fxsaber:

Und das sollte es auch nicht, schon allein wegen der Zweideutigkeit

Im Original ist typedef ein Alias für einen Typ, nicht für einen anderen Typ. Daher ist es für die Entwickler eine große Frage, warum der Typname einen Alias anstelle eines Typs anzeigt.
 

Fehler bei der Kompilierung

struct A {
                void f() {}
        static  void f( int ) {}
};
template<typename T>
void g( T ) {}
void f( int ) {}
typedef void (*fn)( int );
void OnStart()
{
        g(  (fn)   f ); //(1) нормально
        g(  (fn)A::f ); //(2) error: '(void(*fn)(int))' - cannot resolve function address
        fn ff = A::f;
        g( ff        ); //(3) нормально
}
Wenn (1) OK ist, warum ein Fehler in (2), wenn (3) OK ist???
 
Комбинатор:
Im Original ist typedef ein Alias für einen Typ, nicht für einen anderen Typ. Daher ist es für die Entwickler eine große Frage, warum der Typname einen Alias anstelle eines Typs anzeigt.

Ich stimme zu.

 

A100:

template<typename T>
string typeof( T ) { return typename T; }

Bitte erläutern Sie den typeof. Ich konnte keine gute Erklärung für unerfahrene Programmierer finden.

 
Während eines einzigen Laufs und der Visualisierung werden die Protokolle mit Tausenden von Einträgen dieser Art gefüllt
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order modified [#253  buy limit 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order modified [#253  buy limit 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order modified [#253  buy limit 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order modified [#253  buy limit 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order modified [#253  buy limit 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   take profit triggered #251  sell 1.00 EURUSD 1.18166 tp: 1.18159 [#254  buy 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   deal #251  buy 1.00 EURUSD at 1.18159 done (based on order #254)
2017.08.16 20:26:06.477 2017.08.01 10:04:06   deal performed [#251  buy 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order performed buy 1.00 at 1.18159 [#254  buy 1.00 EURUSD at 1.18159]
2017.08.16 20:26:06.477 2017.08.01 10:04:06   order [#253  buy limit 1.00 EURUSD at 1.18159] triggered

Und man muss lange Sekunden warten, bis sie auftauchen. Und ich bin nur am Protokoll interessiert, das ich selbst in OnDeinit erstelle. Warum muss ich jedes Mal diese Protokolle erzwingen, die in SEHR seltenen Fällen gelesen werden? Es gibt einen speziellen Menüpunkt im Agent Log Viewer. Und das Fehlen dieser Protokolle während der Optimierung führt nicht dazu, dass sich jemand unvollständig fühlt. Warum also all diese Aufdringlichkeit in Hunderten von Megabytes (vor allem, wenn ein böser EA versucht, bei jedem Tick ein Geschäft zu öffnen und dabei den Modus "Unsupported filled" erhält)?

Ist es möglich, die Fliegen von den Koteletts im Testgerät zu trennen? Dasselbe wie im Terminal: ein Protokoll für die Ausdrucke aus dem EA selbst und ein Protokoll des Terminals. Sie sind es leid, lange Sekunden zu warten, während diese Zehntausende von unnötigen Meldungen im Log für jeden Order-Punkt durchlaufen und Sie die letzten Zeilen des Backtest-Abschlusses sehen können.

Es hat lange auf sich warten lassen. Ich bin vielleicht nicht der einzige, der sich darüber ärgert.

1...195619571958195919601961196219631964196519661967196819691970...3184
Neuer Kommentar