Gespräche über die PLO in der Lounge - Seite 16

Neuer Kommentar
 
Vasiliy Sokolov:

In normalen Programmiersprachen(nicht in C++)ist das Überladen des '='-Operators verboten.

Eine normale Sprache ist Ihr Sharp? Und der Einzige, den Sie kennen? Das ist auch scheiße, sonst würdest du nicht so etwas sagen wie "Schnittstellen sind keine Vererbung".

Wissen Sie, der =-Operator ist da, nicht als Zucker, sondern als Operator. Und in MQL ist er da - automatisch generiert, stellen Sie sich vor!

Und die Tatsache, dass der Kopierkonstruktor in MQL viel praktischer ist als der, den Sie geschrieben haben, brauche ich Ihnen gar nicht erst zu erzählen. Sie waren vor ein paar Jahren ein Dummkopf und sind es immer noch. Mit Typen wie Denis haben Sie nur Ihr Ego gestärkt.

 
Комбинатор:

...Du hast dein Ego gerade von Leuten wie Denis aufpolieren lassen.

Sie können mich nicht mit Details überzeugen, also wenden Sie sich jetzt gegen den Rest des Forums. Niederträchtig und verachtenswert.

(Anm.: Er spricht die anderen in der dritten Person und mit Kleinbuchstaben an, d.h. ohne Respekt und "ihr seid alle Niemande hier")

 
Vasiliy Sokolov:

In normalen Programmiersprachen(nicht in C++)ist das Überladen des '='-Operators verboten.

Für mich ist es sehr praktisch, dass dieser Operator überlastet werden kann, vor allem, wenn ich ausgiebig mit Vorlagen arbeite. Auch in vielen anderen Situationen überlaste ich sie.

Ich schlage vor, dass man vor der Verwendung solcher Überladungen , insbesondere des Zuweisungsoperators, gründlich darüber nachdenken sollte, warum die dummen Architekten dieser dummen Sprachen das tun.

Ein klassisches Beispiel für das Überladen von Operatoren sind komplexe Zahlen und Matrizen. Daran ist nichts auszusetzen. Ich schreibe ständig Operatoren, weil der Code nicht mehr umständlich ist und man die Logik sofort erkennen kann.


Die einfachste

struct MQLTICK : public MqlTick
{
  bool operator >( const double Price ) const
  {
    return(this.bid > Price);
  }

  bool operator <( const double Price ) const
  {
    return(this.ask < Price);
  }
};
 

Vasiliy Sokolov und Combinator, bitte hören Sie auf zu fluchen.

Andernfalls werden wir Volchanski als Provokateur verbieten müssen :)

 
Vasiliy Sokolov:

Sie können mich nicht mit Details überraschen

Brauchen Sie nicht mehr Details? )) Charp-Code mit Zuweisung zu schreiben? Oder mir zu zeigen, wie man einen Copy-Constructor schreibt? Oder Sprachen mit Zuweisungsoperatoren aufzulisten? Es ist viel einfacher, über fehlende Spezifika zu reden und mir falsche Anschuldigungen zu machen, als zuzugeben, dass Sie voller Scheiße sind
 
Rashid Umarov:

Sonst müssen wir Wolchansky als Provokateur verbieten :)

Nee, wer soll dann Geschichten erzählen? Ich als Anstifterin wäre besser.

 
Vasiliy Sokolov:

Ich lasse mich nicht von ungebildeten Hassern provozieren und erkläre besser meinen Standpunkt:

In normalen Programmiersprachen(nicht in C++)ist das Überladen des Operators '=' verboten. Und in einigen ist das Überladen von Operatoren fast vollständig verboten, weil es dort als Anti-Pattern völlig verdient ist. Ich schlage vor, dass diejenigen, die solche Überladungen, insbesondere Zuweisungsoperatoren, verwenden wollen, gründlich darüber nachdenken, warum die dummen Architekten dieser dummen Sprachen das tun.

Und warum sind das "normale Programmiersprachen"?

Das Überladen des Zuweisungsoperators ist in vielen Fällen sehr nützlich. Das klassische Beispiel sind "intelligente Zeiger". Der Zuweisungsoperator muss nicht nur einen Zeiger kopieren, sondern auch AddRef() machen - mit Überladung geschieht dies alles transparent.

Warum ist es praktisch? Denn es ist viel sinnvoller, Zeiger zu kopieren, als ganze Objekte. (Und bei intensivem Kopieren an verschiedenen Stellen des Programms ist es schwierig zu erkennen, ob das Objekt benötigt wird oder nicht. In diesem Fall sind Smartpoints sehr nützlich.

Natürlich gibt es auch so etwas wie "Müllsammler" - aber diese Variante gefällt mir weniger, eben weil Zeiger vollen Zugriff auf die Referenzen und die Kopienanzahl haben, während Müllsammler dies nicht haben. Ganz zu schweigen davon, dass Zeiger das Objekt zerstören, sobald es nicht mehr benötigt wird, während der Müllsammler mit einer gewissen Verzögerung arbeitet.

 
George Merts:

Natürlich gibt es auch Dinge wie den "Müllsammler" - aber diese Option gefällt mir weniger, eben weil Zeiger vollen Zugriff auf die Referenz- und Kopienanzahl haben und der Müllsammler nicht. Ganz zu schweigen davon, dass Zeiger das Objekt zerstören, sobald es nicht mehr benötigt wird, während der Müllsammler mit einer gewissen Verzögerung arbeitet.

Aha, GC löscht nicht immer alles, selbst wenn es zwangsweise ausgeführt wird. Manchmal wird dies zu einem Problem.
 
Vasiliy Sokolov:

Ich lasse mich nicht von ungebildeten Hassern provozieren und erkläre besser meinen Standpunkt:

In normalen Programmiersprachen(nicht in C++)ist das Überladen des Operators '=' verboten. Ich schlage vor, dass vor der Verwendung solcher Überladungen, insbesondere von Zuweisungsoperatoren, diejenigen, die dies wünschen, gründlich darüber nachdenken, warum die dummen Architekten dieser dummen Sprachen dies tun.

Konnte nicht widerstehen, persönlich zu andrei: Mensch, blamier dich doch nicht so. Sie sagen so dummes Zeug: erst über FP, jetzt über die Betreiber. Möchte hayterite - willkommen: geben Hinweise auf maßgebliche Quellen, zu rechtfertigen, etc. Was Sie jetzt tun, ist ein tollwütiger und vor allem völlig ungebildeter Hass. Sie scheinen ein Programmierer zu sein, sogar ein richtiger - es ist beschämend, so etwas zu schreiben.


Vasily, es ist wünschenswert, die Namen der Sprachen anzugeben. Die Formulierungen "in der Regel", "in einigen", "diese" verleihen dem Gesagten keine Glaubwürdigkeit. Wir sind Programmierer, keine Whitelists, also sollten wir unsere Aussagen konkret formulieren.

 
Yuriy Asaulenko:
Aha, GC löscht nicht immer alles, selbst wenn es zwangsbefüllt wird. Manchmal wird dies zu einem Problem.

Wenn es davon ausgeht, dass das Objekt wahrscheinlich bald wieder erstellt wird, wird es nicht entfernt.

1...91011121314151617181920212223
Neuer Kommentar