Parlare dell'OLP nel salone - pagina 16

Nuovo commento
 
Vasiliy Sokolov:

Nei normali linguaggi di programmazione(non C++), ilsovraccarico dell'operatore '=' è vietato.

Un linguaggio normale è il tuo Sharp? E l'unico che conosci? Fa anche schifo, altrimenti non diresti cose come "le interfacce non sono eredità".

Sapete, l'operatore = è lì, non come uno zucchero, ma come un operatore. E in MQL è -- auto-generato, sapete!

E il fatto che in MQL il costruttore di copie è molto più comodo di quello che hai scritto tu, non c'è nemmeno bisogno che te lo dica. Eri un idiota qualche anno fa e lo sei ancora. Hai solo aumentato il tuo ego con ragazzi come Denisa.

 
Комбинатор:

...Ti sei appena fatto gonfiare l'ego da gente come Denis.

Non riuscite a prendermi sulle specifiche, quindi ora vi rivolgete al resto del forum. Meschino e spregevole.

(Nota: ha messo gli altri in terza persona e con la lettera minuscola, cioè senza rispetto e "siete tutti delle nullità qui")

 
Vasiliy Sokolov:

Nei normali linguaggi di programmazione(non C++), ilsovraccarico dell'operatore '=' è vietato.

È molto comodo per me, specialmente quando uso ampiamente i template, che sia possibile sovraccaricare questo operatore. Lo sovraccarico anche in molte altre situazioni.

E l'overloading di alcuni operatori è quasi completamente proibito in alcuni linguaggi, perché è completamente meritato lì come un anti-pattern. Suggerisco che prima di usare qualsiasi overloading, specialmente l'operatore di assegnazione, si dovrebbe pensare bene al perché quegli stupidi architetti di quegli stupidi linguaggi lo fanno.

Un classico esempio di sovraccarico di operatori è rappresentato dai numeri complessi e dalle matrici. Non ci vedo niente di male. Scrivo sempre operatori perché il codice non è più ingombrante e si può vedere subito la logica.


Il più semplice

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 e Combinator, per favore smettete di dire parolacce.

Altrimenti dovremo bandire Volchanski come provocatore :)

 
Vasiliy Sokolov:

Non mi puoi prendere sui dettagli

non hai bisogno di più dettagli? )) Scrivere codice charp con assegnazione? O mostrarmi come scrivere un copy-constructor? O elencare linguaggi con operatori di assegnazione? Parlare di mancanza di specifiche e fare false accuse contro di me è molto più facile che ammettere che sei pieno di merda
 
Rashid Umarov:

Altrimenti dovremo bandire Wolchansky come provocatore :)

No, chi racconterà le storie? Preferisco essere l'istigatore.

 
Vasiliy Sokolov:

Non mi lascerò provocare da odiatori analfabeti, e farei meglio a spiegare il mio punto di vista:

Nei normali linguaggi di programmazione(non C++) l'overloading dell'operatore '=' è vietato. E in alcuni il sovraccarico degli operatori è proibito quasi completamente, perché è completamente meritato lì come anti-pattern. Suggerisco che prima di usare qualsiasi sovraccarico di questo tipo, specialmente l'operatore di assegnazione, quelli che lo desiderano, pensino bene al perché quegli stupidi architetti di quelle stupide lingue lo fanno.

E perché questi sono "linguaggi di programmazione normali"?

Sovraccaricare l'operatore di assegnazione è molto utile in molti casi. L'esempio classico è quello dei "puntatori intelligenti". L'operatore di assegnazione non deve solo copiare un puntatore, ma anche fare AddRef() - con l'overloading, tutto questo viene fatto in modo trasparente.

Perché è conveniente? Perché ha molto più senso copiare i puntatori piuttosto che interi oggetti. (E con la copia intensiva in diversi punti del programma è difficile vedere se l'oggetto è necessario o no. In questo caso gli smartpoint sono molto utili.

Naturalmente, ci sono cose come il "rubbish collector" - ma questa variante mi piace meno, proprio perché i puntatori hanno pieno accesso ai riferimenti e al conteggio delle copie, mentre il rubbish collector no. Senza contare che i puntatori distruggono l'oggetto non appena non è più necessario, mentre il raccoglitore di rifiuti lavora con un certo ritardo.

 
George Merts:

Certo, ci sono cose come il "rubbish collector" - ma questa opzione mi piace meno, proprio perché i puntatori hanno pieno accesso al conteggio dei riferimenti e delle copie, mentre il rubbish collector no. Senza contare che i puntatori distruggono l'oggetto non appena non è più necessario, mentre il raccoglitore di rifiuti lavora con un certo ritardo.

Uh-huh, GC, anche se eseguito forzatamente, non sempre cancella tutto. A volte questo diventa un problema.
 
Vasiliy Sokolov:

Non mi lascerò provocare da odiatori analfabeti, e farei meglio a spiegare il mio punto di vista:

Nei normali linguaggi di programmazione(non C++) l'overloading dell'operatore '=' è vietato. E in alcuni, il sovraccarico dell'operatore è proibito quasi completamente, dato che lì è meritatamente considerato un anti-pattern. Suggerisco che prima di usare un tale sovraccarico, specialmente l'operatore di assegnazione, quelli che lo desiderano, pensino bene al perché quegli stupidi architetti di quelle stupide lingue lo fanno.

Non ho potuto resistere, personalmente ad andrei: cavolo, non metterti in imbarazzo così. State dicendo cose così sciocche: prima su FP, ora sugli operatori. Vuoi hayterite - benvenuto: dare riferimenti a fonti autorevoli, giustificare, ecc. Quello che state facendo ora è un odio rabbioso e soprattutto totalmente analfabeta. Lei sembra essere un programmatore, come anche uno vero - è vergognoso scrivere queste cose.


Vasily, è auspicabile specificare i nomi delle lingue. Le frasi "nella norma", "in alcuni", "questi" non aggiungono credibilità a ciò che viene detto. Siamo programmatori, non whitelist, quindi cerchiamo di essere specifici nelle nostre dichiarazioni.

 
Yuriy Asaulenko:
Uh-huh, GC, anche se forzato, non sempre cancella tutto. A volte questo diventa un problema.

Se pensa che l'oggetto sarà probabilmente creato di nuovo presto, non lo rimuoverà.

1...91011121314151617181920212223
Nuovo commento