Bug del compilatore con il parametro template = void* - pagina 18

Nuovo commento
 
Igor Makanu:

Vorrei collegare il modulo VS a .dll a MT5 in modo semplice )))) - Voglio avvolgere i gestori del clic del pulsante in una classe e chiamarli attraversando un array di puntatori di funzioni di gestione, e voglio avere nel codice principale di EA la possibilità di scrivere gli stessi nomi di funzioni come in VS, cioè button2_Click() ....button2_Click()

SZY: Questo è un problemaEOP))))

Senza offesa, ma mi ricorda molto:


1
 
Ilya Malev:

- Creare strutture automatiche all'interno di una OOP dinamica non ha senso

Quindi impilare oggetti: myclass obj; non ha senso? Allora sono un handicapper :)

 
pavlick_:

Quindi, impilare oggetti: myclass obj; non ha senso? Quindi, sono un artigiano :)

Ci sono tutti i tipi di compiti. Si può praticare la retorica per molto tempo, se non si descrivono compiti specifici, si può inventare qualsiasi cosa...

Sì, gli oggetti "impilabili" (automatico che intendi?) sono fondamentalmente senza senso. A mio modesto parere, che non è assolutamente la verità e certamente non nell'ultima istanza...
 
Un jolly ha bisogno di un oggetto che non svolge la funzione principale dell'OOP - la proprietà del polimorfismo? Non assegnerete a tale variabile nessun oggetto con proprietà diverse a seconda del contenuto. Non sarete affatto in grado di mappare un altro oggetto su questa "variabile" nella lista. Perché avete bisogno di oggetti, non è meglio usare le strutture? Forse perché le strutture µl non possono restituire riferimenti a se stesse... E con loro inizia una roba oscura con costante creazione-distruzione-auto-copiatura ecc.
 
Ilya Malev:
Volete un oggetto che non soddisfa la funzione principale dell'OOP - la proprietà del polimorfismo? Non assegnerete a tale variabile nessun oggetto con proprietà diverse a seconda del contenuto. Non sarete affatto in grado di mappare un altro oggetto su questa "variabile" nella lista. Perché avete bisogno di oggetti, non è meglio usare le strutture? Forse perché le strutture µl non possono restituire riferimenti a se stesse... E con loro inizia una roba oscura con costante creazione-distruzione-auto-copiatura ecc.

Come vivere senza polimorfismo ... E se dico che possiamo fare a meno del polimorfismo nel >90% dei casi? Prendete il "principio di inversione di dipendenza SOLID", se siamo proger decenti, dovremmo creare astrazioni, metodi virtuali ovunque (il che comporta alti costi generali, ovviamente). Gli esperti di C# scriverebbero qualcosa come questo https://pro-prof.com/forums/topic/dependency-inversion-principle. Oppure potremmo prendere dei modelli e scrivere qualcosa come:

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 è anche indipendente dai dettagli, senza tutto il polimorfismo e le interfacce. Il polimorfismo ha la sua nicchia, ma è molto più ristretta di quanto si dica.

ZS: beh, nessuno lo vieta:

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
Certo, possiamo fare a meno del polimorfismo, ma per questo caso è molto più onesto e logico usare strutture semplici piuttosto che oggetti, altrimenti stiamo inchiodando con un microscopio. Per essere più precisi, nel caso di µl5 si aggirano piuttosto le "caratteristiche di implementazione" che non permettono di utilizzare pienamente le strutture non-oggetto (impossibilità di passare puntatori a loro, a differenza degli oggetti). Questo è un problema completamente diverso, non è più OOP, ma solo OO
 
pavlick_:

ZS: beh, nessuno lo vieta:

Nessuno vieta ogni sorta di stampelle e schematismi, ma perché? Per esempio: sarà divertente quando il vostro auto-oggetto si autodistruggerà improvvisamente quando meno ve lo aspettate, vero?

 
Il punto dell'OOP non è usare il metodo scelto per premere il pulsante, che si può altrettanto bene implementare attraverso template o puntatori di funzione, ma solo applicare a qualsiasi oggetto del sistema metodi come list, che permettono di auto-organizzarsi in strutture di lista e creare selezioni arbitrarie al momento giusto senza stampelle come CArrayObj, ecc. e il fastidio associato, overloading di metodi come Select, Query, Compare, Sort, ecc. (e anche Clone/Copy, quando ogni oggetto può decidere senza la vostra partecipazione se deve essere copiato in una lista/array o no, e se copiato, come deve essere copiato).
 
Ilya Malev:

Nessuno vieta di inventare stampelle e schematismi, ma perché? Per esempio: sarà divertente quando il vostro auto-oggetto si distruggerà improvvisamente quando meno ve lo aspettate, vero?

Perché un oggetto stack è molto più veloce di un oggetto in un heap(allocazione di memoria). Autodistruzione? - Questo è qualcosa di nuovo :). Ma a volte è necessario, naturalmente - il numero di oggetti è noto solo a tempo di esecuzione, per esempio.

ZS: si può stare più comodi altrimenti, è una questione personale.

 
Ilya Malev:
Il punto dell'OOP non è usare il metodo scelto per premere il pulsante, che si può altrettanto bene implementare attraverso template o puntatori di funzione, ma solo applicare a qualsiasi oggetto del sistema metodi come list, che permettono di auto-organizzarsi in strutture di lista e creare selezioni arbitrarie al momento giusto senza stampelle come CArrayObj, ecc. e il fastidio associato, overloading di metodi come Select, Query, Compare, Sort, ecc. (e anche Clone/Copy, quando ogni oggetto può decidere senza la vostra partecipazione se copiarlo o meno in una lista/array, e se copiarlo, come).

Ho scritto - il polimorfismo ha la sua nicchia, non lo discuto. Ma la pratica dimostra (la mia personalmente, almeno) che non è così significativa. Sono molto più propenso a risolvere i problemi con i modelli.

1...11121314151617181920
Nuovo commento