MQL5 Il compilatore non distingue tra una classe e un puntatore ad essa - pagina 11

Nuovo commento
 
Ilya Malev:

Questo: (* ) non è necessario qui.

* è necessario nel µl solo quando le operazioni =, ==, !=, !& o || sono applicate direttamente al * puntatore

Questo è esattamente ciò di cui avete bisogno, IMHO, per non dimenticare con cosa avete a che fare (un oggetto o un puntatore ad esso).

Ilya Malev:

(Se vuoi rimuoverlo di nuovo e far finta che non sia mai esistito))

Quindi, sì. Un ulteriore sviluppo con i puntatori porterà a un clone completo del C++.

Forse andranno nella direzione di C# dove il "codice gestito" non ha puntatori ma tutto ha un oggetto, anche i tipi comuni bool int double, ecc.

 
Ilya Malev:

E inoltre, a proposito, può anche essere che visto che tutti i canali ufficiali (forum, aiuto, documentazione) tacciono sull'operatore *, forse gli amministratori stanno pensando di rimuoverlo di nuovo, e far finta che non sia mai esistito))) Quindi è pericoloso fare affidamento sul suo uso in generale al momento imho.

Il silenzio è probabilmente perché al 99,9% degli utenti non interessa tutto questo. Perché disturbare i loro cervelli con informazioni inutili? E quelli che ne avevano bisogno, le hanno chieste e le hanno ottenute.

Anche tu non ti interessavi di questa caratteristica fino ad ora, vero? E ora stai disperatamente iniziando a trovare scuse per non saperlo ;) Che differenza fa quando è stata introdotta: immediatamente o dopo mesi? Non l'avresti comunque saputo se non te l'avessi detto )

 

Hmmm... Forse ci sono anche dei puntatori all'array? Dovrò controllare... Mi mancano così tanto...

 
Georgiy Merts:

Hmmm... Forse ci sono anche dei puntatori all'array? Dovrò controllare... Mi mancano così tanto...

No. Dovete mettere gli array nelle classi, hanno dei puntatori.

 
Ilya Baranov:

No. Devi mettere gli array nelle classi, hanno dei puntatori a loro.

Sì, ahimè.

In realtà, le classi derivate da CArray sono abbastanza utili per me. L'unica cosa per cui voglio i puntatori agli array sono gli indicatori, passano riferimenti agli array, e devo "trascinare" questi riferimenti attraverso tutta la gerarchia di oggetti, il che è molto scomodo...

Una volta ho suggerito di rendere i puntatori agli array, o di fare una funzione indicatore che usasse i puntatori agli array della Standard Library, piuttosto che i collegamenti agli array, ma ahimè, sono stato respinto sulla base del fatto che "se permettiamo i puntatori agli array, sarà possibile usare array non inizializzati", anche se gli sviluppatori non hanno tali timori con gli oggetti... Sì, beh, lo lascio alla loro coscienza.

 
Georgiy Merts:

2. MQL non deve cancellare ciò che non ha selezionato. Dmitriy aveva ragione sopra - crea un oggetto - cancellalo. Non mi piace la pratica del "raccoglitore di spazzatura" in C#, quando gli oggetti vengono cancellati non quando voglio io, ma quando lo vuole il raccoglitore.

Il C# picker non rimuoverà mai un oggetto vivo o un puntatore. Il suo scopo è quello di rimuovere la spazzatura dall'heap e talvolta deframmentarlo.

 
Alexey Volchanskiy:

L'assemblatore C# non cancellerà mai un oggetto o un puntatore vivo. Il suo scopo è quello di rimuovere la spazzatura del cadavere dall'heap e talvolta deframmentarlo.

Non sto dicendo che il raccoglitore di rifiuti cancellerà un oggetto vivo o un puntatore. Quello che sto dicendo è che lo cancellerà quando vuole. E questo, secondo me, non è buono.

Posso lavorare con o senza cancellazione. E posso anche fare degli smartpoints... Tuttavia, penso che la cancellazione degli oggetti deve essere possibile e la persona che l'ha creato deve cancellare l'oggetto.

Questo è il tipo di vecchia scuola che sono.

 
SemenTalonov:

Probabilmente, andranno nella direzione di C# dove il "codice gestito" non ha puntatori e tutto ha un oggetto, anche i semplici tipi bool int double, ecc.

Sì, ma lasciano ancora la possibilità di lavorare con i puntatori nel codice non gestito. È vero, tale codice ha restrizioni di distribuzione.

 
Georgiy Merts:

Non sto dicendo che il raccoglitore di rifiuti cancellerà un oggetto vivo o un puntatore. Quello che sto dicendo è che lo cancellerà quando vuole. E questo, secondo me, non è buono.

Posso lavorare con o senza cancellazione. E posso anche fare degli smartpoint... Ma, tuttavia, penso che gli oggetti dovrebbero essere cancellati, e chi li ha creati dovrebbe cancellarli.

Questo è il tipo di vecchia scuola che sono.

Georges, vuoi fare un esempio, non ti capisco. È questo che intende? Immagino che tu possa fare dei punti intelligenti da solo.

bool first = false;

int Foo()
{
  int i;
  if(!first)
  {
     first = true; 
     i = 123;
  }
  return i;   
}

// И ты будешь надеятся, что i сохранит свое значение между сотней вызовов Foo? Может да (очень редко, если Foo вызывается 100 раз подряд), а может и нет.
 
Alexey Volchanskiy:

Georges, mi faresti un esempio, non ti capisco. È questo che intende? Probabilmente è possibile fare gli smartpoint da soli.

No. È chiaro che in questo caso la variabile deve essere cancellata all'uscita dal blocco.

Sto parlando di oggetti creati da nuovi:

CMyObj* pmoObject  = new CMyObject;

Lo standard C# specifica:"Sia gli oggetti di tipo valore, come le strutture, che gli oggetti di tipo riferimento, come le classi, vengono distrutti automaticamente, ma gli oggetti di tipo valore vengono distrutti quando il contesto che li contiene viene distrutto, mentre gli oggetti di tipo riferimento vengono distrutti dal raccoglitore di rifiuti indefinitamente dopo che l'ultimo riferimento ad essi viene rimosso".

Ecco, non mi piace questo "tempo indefinito". Anche se ammetto che il raccoglitore di rifiuti può cancellare un oggetto in modo molto più efficiente di me, cancellando l'oggetto nel distruttore della classe che lo ha creato.

1...45678910111213
Nuovo commento
Motivazione: