Compilerfehler mit Template-Parameter = void* - Seite 18

Neuer Kommentar
 
Igor Makanu:

Derzeit möchte ich VS-Formular zu .dll zu MT5 auf eine einfache Weise )))) anhängen. - Ich möchte die Schaltflächenklick-Handler in einer Klasse verpacken und sie durch Traversieren eines Zeiger-Arrays von Handler-Funktionen aufrufen, und ich möchte im Haupt-EA-Code die Möglichkeit haben, die gleichen Funktionsnamen wie in VS zu schreiben, d. h. button2_Click() ....button2_Click()

SZY: Dies ist einEOP-Problem))))

Nichts für ungut, aber es erinnert mich sehr daran:


1
 
Ilya Malev:

- Automatische Strukturen innerhalb einer dynamischen OOP zu schaffen ist Unsinn

Stapelobjekte: myclass obj; ist also Unsinn? Dann bin ich ein Handicapper :)

 
pavlick_:

Objekte stapeln: myclass obj; ist also Unsinn? Also, ich bin ein Handwerker :)

Es gibt alle Arten von Aufgaben. Man kann sich lange in Rhetorik üben, wenn man keine konkreten Aufgaben beschreibt, kann man sich alles Mögliche einfallen lassen...

Ja, "stapelbare" (automatische?) Objekte sind grundsätzlich unsinnig. Meiner bescheidenen Meinung nach, die keineswegs die Wahrheit ist und schon gar nicht in letzter Instanz...
 
Ein Joker braucht ein Objekt, das die Hauptfunktion von OOP - die Eigenschaft der Polymorphie- nicht erfüllt? Sie werden einer solchen Variablen kein Objekt mit unterschiedlichen Eigenschaften je nach Inhalt zuweisen. Sie können dieser "Variablen" in der Liste überhaupt kein anderes Objekt zuordnen. Wozu braucht man überhaupt Objekte? Ist es nicht besser, stattdessen Strukturen zu verwenden? Vielleicht, weil µl-Strukturen keine Referenzen auf sich selbst zurückgeben können... Und mit ihnen beginnt eine dunkle Geschichte mit ständiger Schöpfung, Zerstörung, Selbstkopie usw.
 
Ilya Malev:
Sie wollen ein Objekt, das die Hauptfunktion von OOP - die Eigenschaft der Polymorphie- nicht erfüllt? Sie werden einer solchen Variablen kein Objekt mit unterschiedlichen Eigenschaften je nach Inhalt zuweisen. Sie können dieser "Variablen" in der Liste überhaupt kein anderes Objekt zuordnen. Wozu braucht man überhaupt Objekte? Ist es nicht besser, stattdessen Strukturen zu verwenden? Vielleicht, weil µl-Strukturen keine Referenzen auf sich selbst zurückgeben können... Und mit ihnen beginnt eine dunkle Geschichte mit ständiger Schöpfung, Zerstörung, Selbstkopie usw.

Wie man ohne Polymorphismus leben kann ... Und wenn ich sage, dass wir in >90% der Fälle ohne Polymorphismus auskommen können? Nehmen wir das "SOLID-Abhängigkeitsinversionsprinzip": Wenn wir anständige Progger sind, sollten wir überall Abstraktionen und virtuelle Methoden schaffen (was natürlich einen hohen Overhead mit sich bringt). C#-Kenner würden etwas wie dieses https://pro-prof.com/forums/topic/dependency-inversion-principle schreiben . Oder wir könnten Vorlagen nehmen und etwas schreiben wie:

class Lamp {
public:
    void activate();
    void deactivate();
};
template <typename T>
class Button {
    Button(T& switchable)
        : _switchable(&switchable) {
    }
    void toggle() {
        if (_buttonIsInOnPosition) {
            _switchable->deactivate();
            _buttonIsInOnPosition = false;
        } else {
            _switchable->activate();
            _buttonIsInOnPosition = true;
        }     
    }
private:
   bool _buttonIsInOnPosition{false};
   T* _switchable; 
}
int main() {
   Lamp l;
   Button<Lamp> b(l)

   b.toggle();
}


Button ist auch detailunabhängig, ohne all den Polymorphismus und die Schnittstellen. Polymorphismus hat seine eigene Nische, aber die ist viel enger, als man sagt.

ZS: Nun, niemand verbietet es:

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
Natürlich können wir auf Polymorphismus verzichten, aber in diesem Fall ist es viel ehrlicher und logischer, einfache Strukturen statt Objekte zu verwenden, da wir sonst mit einem Mikroskop nageln würden. Genauer gesagt, umgehen wir im Fall von µl5 "Implementierungsmerkmale", die es nicht erlauben, Nicht-Objekt-Strukturen in vollem Umfang zu nutzen (im Gegensatz zu Objekten ist es nicht möglich, Zeiger an sie zu übergeben). Das ist ein ganz anderes Problem, es ist nicht mehr OOP, sondern nur noch OO
 
pavlick_:

ZS: Nun, niemand verbietet es:

Niemand verbietet alle Arten von Krücken und Schematismus, aber warum? Zum Beispiel: Es wird lustig sein, wenn sich dein Auto-Objekt plötzlich selbst zerstört, wenn du es am wenigsten erwartest, nicht wahr?

 
Der Sinn von OOP ist nicht, die von Ihnen gewählte Methode des Tastendrucks zu verwenden, die Sie genauso gut durch Templates oder Funktionszeiger implementieren können, sondern einfach auf jedes Objekt des Systems Methoden anzuwenden, wie z.B. eine Liste, die es erlauben, sich selbst in Listenstrukturen zu organisieren und beliebige Selektionen zum richtigen Zeitpunkt zu erstellen, ohne Krücken wie CArrayObj, etc. und die damit verbundene Mühe, Methoden wie Select, Query, Compare, Sort, etc. zu überladen. (und sogar Klonen/Kopieren, wenn jedes Objekt ohne Ihre Beteiligung entscheiden kann, ob es in eine Liste/Array kopiert werden soll oder nicht, und wenn es kopiert wird, wie es kopiert werden soll).
 
Ilya Malev:

Niemand verbietet das Erfinden von Krücken und Schematismus, aber warum? Zum Beispiel: Es wird lustig sein, wenn sich Ihr Auto-Objekt plötzlich selbst zerstört, wenn Sie es am wenigsten erwarten, nicht wahr?

Denn ein Stack-Objekt ist viel schneller als ein Objekt in einem Heap(Speicherzuweisung). Selbstzerstörung? - Das ist etwas Neues :). Aber manchmal ist das natürlich notwendig - die Anzahl der Objekte ist z.B. erst zur Laufzeit bekannt.

ZS: Sie mögen sich anders wohler fühlen, das ist eine persönliche Angelegenheit.

 
Ilya Malev:
Der Sinn von OOP ist nicht, die von Ihnen gewählte Methode des Tastendrucks zu verwenden, die Sie genauso gut durch Templates oder Funktionszeiger implementieren können, sondern einfach auf jedes Objekt des Systems Methoden anzuwenden, wie z.B. eine Liste, die es erlauben, sich selbst in Listenstrukturen zu organisieren und beliebige Selektionen zum richtigen Zeitpunkt zu erstellen, ohne Krücken wie CArrayObj, etc. und die damit verbundene Mühe, Methoden wie Select, Query, Compare, Sort, etc. zu überladen. (und sogar Klonen/Kopieren, wenn jedes Objekt ohne Ihre Mitwirkung entscheiden kann, ob es in eine Liste/Array kopiert werden soll oder nicht, und wenn es kopiert werden soll, wie).

Ich schrieb - Polymorphismus hat seine eigene Nische, ich bin nicht streiten. Aber die Praxis zeigt (zumindest bei mir persönlich), dass das nicht so wichtig ist. Es ist viel wahrscheinlicher, dass ich Probleme mit Vorlagen löse.

1...11121314151617181920
Neuer Kommentar
Grund der Beschwerde: