Errori, bug, domande - pagina 2532

[Georgiy Merts]

Igor Makanu:

tutto funziona, ma gli array che saranno buffer indicatori dovrebbero essere descritti con il modificatore public

Sì, certo.

Certo, l'accesso pubblico ai membri della classe non è buono, ma il problema principale - l'accesso ai dati dell'array senza copiare è risolto.

Grazie, la questione è chiarita.

[Влад]

Se la domanda è stata capita, potete aiutarmi? Per voi mammut della programmazione, è come una canna...

[Igor Makanu]

Georgiy Merts:

Naturalmente, l'accesso pubblico ai membri della classe non è buono, ma il problema principale - l'accesso ai dati dell'array senza copiare è risolto.

Guardo molti video su YouTube, mi sono imbattuto in un canale di un programmatore intelligente, e mi ricordo la frase: "il codice deve, prima di tutto, eseguire il suo compito!

Lei non lavora a un grande progetto, vero? - Sapete perché questo membro di classe è definito e potete controllarne l'accesso senza l'aiuto del compilatore, vero? ;)

[Aleksei Beliakov]

@Ilyas, build aggiornata di mt4

codice che ha funzionato bene dopo la compilazione e l'esecuzione degli errori

[Vladimir Simakov]

Igor Makanu:

Guardo molti video su YouTube, mi sono imbattuto in un canale di un bravo programmatore, e mi ricordo la frase: "il codice deve, prima di tutto, svolgere il suo compito! ....

Lei non lavora a un grande progetto, vero? - Sapete perché questo membro di classe è definito e potete controllarne l'accesso senza l'aiuto del compilatore, vero? ;)

In realtà l'accesso ai membri della classe è meglio essere implementato attraverso metodi e per avere meno dereferenziazione in run-time, usate inline con i metodi get.

[Georgiy Merts]

Igor Makanu:

Guardo molti video su YouTube, mi sono imbattuto in un canale di un bravo programmatore, e mi ricordo la frase: "il codice deve, prima di tutto, svolgere il suo compito!

Lei non lavora a un grande progetto, vero? - Sapete perché questo membro di classe è definito e potete controllarne l'accesso senza l'aiuto del compilatore, vero? ;)

NO.

Prima di tutto, il codice deve essere trasparente e comprensibile, facile da mantenere. E poi, se non riesce a svolgere il suo compito, sarà immediatamente visibile.

Ma quando il codice è pieno di molti frammenti con costrutti potenzialmente non sicuri che causano errori molto sottili e non evidenti, non si può mai essere sicuri che "il codice compia il suo compito".

E quando si lavora su un grande progetto non se ne può fare assolutamente a meno, in molte aziende ci sono linee guida ufficiali per quanto riguarda la notazione, le dichiarazioni, ciò che può e non può essere dichiarato come azioni e così via. Naturalmente, quando si lavora da soli, si dichiara un membro della classe, si sa a cosa serve e si sa come lo si userà. Tranne che qualsiasi codice, per quanto complesso, anche se fatto da un solo programmatore tende a cambiare l'architettura. E personalmente non ricordo cosa, dove, come e per cosa. Allo stesso tempo sovraccarico generosamente il codice con commenti dettagliati. E ancora, tornando ad altri frammenti dopo mezzo anno passo un bel po' di tempo a capire perché è stato fatto così e non in modo diverso. Senza commenti non sarei in grado di capire il mio codice.

Naturalmente, se avete la memoria di Peter Konov non dovete preoccuparvi di condividere l'accesso, rendete tutte le variabili globali - e usate tutto quello che vi serve, quando volete. Tuttavia, la mia memoria è molto peggio, e posso già dimenticare le sottigliezze di una procedura in una settimana. Perciò ho sviluppato da tempo un principio secondo il quale in qualsiasi luogo del codice deve essere disponibile esattamente quanto mi serve qui e non una sola variabile in più. Il modo migliore è convertire tutto in interfacce virtuali e dividere il più possibile le aree di responsabilità di ogni classe (ma naturalmente ci deve essere una misura, per non avere a che fare con questi wrapper più che con il codice utile).

Ricordiamo che la mancanza di puntatori agli array è giustificata dagli sviluppatori per "prendersi cura dei programmatori", in modo che non si usi accidentalmente un puntatore a un array che non è più rilevante. Nessun problema per le classi però. Bene, hanno spiegato che "se scrivete con le classi, siete già abbastanza esperti per usare i puntatori, mentre gli array sono disponibili per i principianti, e non vogliamo che abbiano problemi quando vogliono usare i puntatori agli array... niente puntatori, tutto qui"...

[Georgiy Merts]

Vladimir Simakov:
In generale, è meglio implementare l'accesso ai membri della classe tramite metodi, e per evitare la dereferenziazione in fase di esecuzione, usare metodi inline con get.

Esatto, e di solito sono incline a farlo. In generale, uso raramente i membri pubblici della classe, tutti gli accessi sono tramite i metodi in linea. Solo in casi speciali, come con questi array di indicatori, devo usare i membri pubblici...

[Georgiy Merts]

Влад:
Se il problema è risolto, potete aiutarmi? Per voi mammut della programmazione, è come una falena...

Nel tuo caso, organizza un ciclo while() piuttosto che un ciclo for().

Controllare se c'è qualche segno di fine del lampeggiamento.

Ma riguardo al "lampeggiare con frequenza variabile" - qualcosa di strano... Non vedo nessun errore al volo, dovrebbe lampeggiare abbastanza spesso.

Anche se dubito che abbia senso creare e cancellare oggetti grafici, invece di renderli invisibili, ma sembra che non si possa rendere invisibile un oggetto... Quindi non resta che cancellare.

[Igor Makanu]

Georgiy Merts:

Naturalmente, se avete una memoria come quella di Peter Konov, non dovete preoccuparvi della separazione degli accessi, rendete tutte le variabili globali - e usate tutto quello che vi serve, quando volete.

Non alleno mai la memoria, uso le variabili globali solo come ultima risorsa, il codice a volte mi sembra persino ridondante, ma i frammenti di codice sono portabili a un altro progetto,

Di solito uso nomi di funzioni e variabili lunghi, in modo da poter leggere ciò che ho scritto prima:

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }

Un altro problema è che non aderisco allo stile OOP - non avvolgo tutto in classi, uso entrambi gli stili procedurale e OOP in un programma allo stesso tempo, è più conveniente e più veloce formare un programma da blocchi già pronti, quello che manca lo aggiungo o lo modifico già pronto per il compito

[Alexey Navoykov]

Vladimir Simakov:
e per avere meno dereferenziazioni in run-time, usate inline con i metodi get.

L'inline è una reliquia, secondo me. Il compilatore inlinea tutto perfettamente, quindi non c'è bisogno di sovraccaricare il codice. E in MQL questo specificatore non è niente, aggiunto solo per scopi di compatibilità (non so per cosa, se si potesse dichiarare una tale macro da soli).