Frage zum Tippen - Seite 3

Neuer Kommentar
 
Ilya Malev:

Der Fehler "Template Mismatch" sollte wahrscheinlich zur Kompilierzeit auftreten.


Aber wenn ein Array-Objekt vorhanden ist

Dieser Fehler sollte nicht auftreten, da im ersten Fall der Aufruf von Array[int] als linker Parameter der Operation = verwendet wird und keine Variable vom Typ double ist, während es im zweiten Fall der rechte ist und der linke Parameter eine Variable vom Typ double ist.

Sie hören nicht, es sollte nichts tun - Typüberladung ist verboten und es ist ausdrücklich in C++ Standard (und µl als C++ ähnlich - wahrscheinlich auch) geschrieben:

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

Der wahrscheinliche Grund ist oben erläutert. Ihr Operator[] ist also ungültig.

 
pavlick_:

Sie hören nicht, es sollte nichts tun - Überladen durch Typ ist verboten und es ist ausdrücklich in C++ Standard geschrieben:

Den wahrscheinlichen Grund habe ich oben genannt. Ihre Operatoren[] sind also ungültig.

Ich habe Ihnen nicht auf die Norm geantwortet, sondern auf die Logik, die auf dem gesunden Menschenverstand beruht. Ihre Definition von "wahrscheinlicher" Ursache entkräftet meine Argumente nicht. Die Möglichkeit, eine Typisierungsoperation (auch implizit) zu überladen, steht nicht im Widerspruch zu der von Ihnen zitierten Norm, denn es ist die Operation des Castings auf einen bestimmten explizit definierten Typ aus dem Kontext, die überladen wird.

Vielleicht habe ich mich nicht klar genug ausgedrückt, aber diese Klarstellung macht es hoffentlich deutlicher.


P.S. Natürlich widerspricht mein fiktiver Code der Norm. Aber wenn Sie es entschlüsseln müssen (weil ich für mich selbst herausgefunden habe, wie man die Frage genauer formuliert), sollte es so aussehen:

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
Wenn Sie den Operator type() befürworten, gut. Wenn Sie das Einrücken von Pluszeichen befürworten, dann bin ich dagegen (Überladen nach Rückgabetyp erlauben), um ein bestimmtes Problem zu lösen (das wahrscheinlich anders und schöner gelöst werden könnte - irgendwie bin ich nie dazu gekommen, wie im ersten Beitrag).
 
pavlick_:
Wenn Sie den Operator type() befürworten, gut. Wenn Sie das Einrücken von Pluszeichen befürworten, dann bin ich dagegen (Überladen nach Rückgabetyp zuzulassen), um ein bestimmtes Problem zu lösen (das sicher auch anders und schöner gelöst werden kann - irgendwie habe ich mich nie so verrannt wie im ersten Beitrag).

Ja. Letztendlich bin ich für die Einführung des Tippoperators. Denn es löst genau das Problem, das ich im ersten Beitrag genannt habe, nur auf eine "konventionellere" (in die Normen passende und wahrscheinlich generell korrektere) Weise.

 
Ilya Malev:

P.S. Natürlich verstößt mein erfundener Code gegen die Norm.

Warum widerspricht sie der Norm, sie ist in den Pluspunkten vollkommen gültig. Und es gibt überhaupt keine Docks in MCL.
 
pavlick_:
Warum ist das widersprüchlich, bei Pluszeichen ist es durchaus gültig. Und in mql gibt es überhaupt keine Docks.

Denn ursprünglich gab es zwei identische operator[]-Funktionen mit unterschiedlichem Rückgabetyp (das habe ich in der zweiten Version behoben). Dies ist nach der Norm verboten. Aber das Zitieren von Typen (auch implizit) ist nicht verboten, sie hatten nur noch keine Zeit, es zu implementieren. In Anbetracht des beeindruckenden Entwicklungstempos von mql5 bin ich sicher, dass es früher oder später implementiert wird. Vor allem, wenn außer mir noch jemand im Forum darauf aufmerksam wird...

 
Ilya Malev:

Weil es zwei identische operator[]-Funktionen mit unterschiedlichem Rückgabetyp gab. Dies ist nach der Norm verboten. Es ist nicht verboten, etwas einzugeben (auch nicht implizit), sie hatten nur noch keine Zeit, es zu implementieren. In Anbetracht der großen Geschwindigkeit der mql5-Entwicklung bin ich sicher, dass es früher oder später implementiert werden wird. Vor allem, wenn außer mir noch jemand im Forum darauf aufmerksam wird...

Ich meine den letzten Code - er ist in Ordnung.

 
pavlick_:

Ich meine den letzten Code - er ist in Ordnung.

Das ist OK, aber es funktioniert noch nicht in mql5. Bleiben wir dran und hoffen wir auf Innovationen in mql5. Diese Unfähigkeit, ein Array-Objekt adäquat zu implementieren, weil es nicht möglich ist, einen Benutzertyp auf die gleiche Weise zu behandeln wie ein gewöhnliches Array, hat mich persönlich lange Zeit gestört. Wenn Sie Ihr eigenes Array erstellen, erweist es sich von Anfang an als mangelhaft und besitzt nicht die gleichen Gebrauchseigenschaften wie die eingebauten.

 
Ilya Malev:

Das ist OK, aber es funktioniert noch nicht in mql5. Bleiben wir dran und hoffen wir auf Innovationen in mql5. Diese Unfähigkeit, ein Array-Objekt adäquat zu implementieren, weil es nicht möglich ist, einen Benutzertyp auf die gleiche Weise zu behandeln wie ein gewöhnliches Array, hat mich persönlich lange Zeit gestört. Wenn Sie Ihr eigenes Array erstellen, erweist es sich zunächst als mangelhaft, da es nicht die gleiche Benutzerfreundlichkeit wie ein eingebautes Array aufweist.

Nun, ich erwarte keine großen Wunder, die Sprache wird nicht mehr wirklich weiterentwickelt, ich bezweifle, dass sie einen Ghost-Operator hinzufügen werden. Hier bin ich besonders durch die Unfähigkeit, es auf diese Weise zu tun, belastet:

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

aber es ist müßig, das zu sagen, denke ich.

 
pavlick_:

Nun, ich erwarte keine großen Wunder, die Sprache ist nicht mehr wirklich entwickelt, ich bezweifle, dass sie einen Ghost-Operator hinzufügen werden. Was mich vor allem stört, ist die Unfähigkeit, dies zu tun:

Aber es ist müßig, darüber zu reden, denke ich.

Es ist nicht ganz klar, was das Problem ist. Könnte die Initialisierung des Objekts nicht in einer separaten Methode wie Init() implementiert werden, vielleicht sogar in einer virtuellen Methode?

12345678910
Neuer Kommentar