Aiuto con OOP - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ufficialmente, sì. Non ufficialmente, molte cose indicano che esiste:
C'è un'indicazione sufficiente e completa che non c'è un raccoglitore di rifiuti in emcool - la cancellazione è obbligatoria dopo il nuovo.
C'è un'indicazione sufficiente e sufficiente che non c'è un raccoglitore di rifiuti in emcool - la cancellazione è obbligatoria dopo il nuovo.
Per quanto mi ricordo, uno degli sviluppatori ha riconosciuto che c'è un raccoglitore di rifiuti. Ma per l'utente "più o meno non esiste".
Beh, riguardo alla coppia nuovo-cancellato - sono d'accordo. In generale, gli oggetti che hanno richiesto le risorse devono esserne responsabili. Ci sono eccezioni, come la "fabbrica di oggetti" - ma lì si assume specificamente che la responsabilità per gli oggetti creati è di colui che ha richiesto questi oggetti dalla fabbrica.
Non mi piace la situazione nelle lingue in cui c'è il nuovo e la cancellazione non è richiesta, perché il "sistema farà pulizia". Questo non solo riduce potenzialmente le prestazioni (quando gli oggetti non necessari non vengono ancora rimossi), ma rilassa anche il codificatore, permettendogli di non preoccuparsi delle conseguenze delle sue azioni.
Non mi piace molto la situazione nelle lingue dove c'è il nuovo, ma la cancellazione non è richiesta, dicendo "il sistema rimuoverà il superfluo". Questo non solo riduce potenzialmente le prestazioni (quando gli oggetti non necessari non vengono ancora rimossi), ma rilassa anche il codificatore, permettendogli di non preoccuparsi delle conseguenze delle sue azioni.
La produttività, d'altra parte, è generalmente migliorata. La rimozione manuale richiede molto tempo nel thread principale. + la cancellazione avviene elemento per elemento. Confrontate le due versioni dello script in questo thread, per esempio. La differenza di velocità è di diverse volte. Anche l'efficienza della memoria sale. Perché il raccoglitore di rifiuti sposta gli oggetti compattati tra loro. Se lo si gestisce manualmente, si creano dei buchi di memoria liberi che non sono così facili da riutilizzare. Inoltre, il garbage collector lavora in un altro thread. Il tempo di base non è sprecato. Tutto sommato, un vantaggio.
La produttività al contrario è generalmente aumentata. La rimozione manuale richiede una notevole quantità di tempo nel flusso principale. + la cancellazione avviene elemento per elemento. Confronta due versioni dello script in questo thread, per esempio. La differenza di velocità è di diverse volte. Anche l'efficienza della memoria sale. Perché il raccoglitore di rifiuti sposta gli oggetti compattati tra loro. Se lo si gestisce manualmente, si creano dei buchi di memoria liberi che non sono così facili da riutilizzare. Inoltre, il garbage collector lavora in un altro thread. Il tempo di base non è sprecato. Tutto sommato, è solo un vantaggio.
Vasily, mi dispiace, ma non capisci affatto di cosa stai cercando di parlare. Per niente e in nessun modo.
Almeno leggi su Wikipedia cos'è un raccoglitore di rifiuti. La sua principale peculiarità è che rimuove gli oggetti con i quali si è persa la comunicazione.
Solo che in questo caso si chiamerebbe un raccoglitore di rifiuti. Questi due copioni sono di una storia diversa. Il dono di Dio non deve essere confuso con un uovo.
E perché un garbage collector dovrebbe improvvisamente aumentare la produttività? È un'imbottitura in più tra il codice utile e l'hardware, e non una debole.
Se ricordo bene, uno degli sviluppatori ha riconosciuto che il raccoglitore di rifiuti esiste. Ma per l'utente è "un po' sparito".
///
Questo deve essere il "garbage collector" che dà un messaggio di perdita di memoria alla fine del lavoro.
Forse cancella anche gli oggetti abbandonati. Ma anche se li rimuove, c'è un grande
differenza - li cancella solo alla fine del lavoro. E se in un ciclo plurimo vengono creati nuovi oggetti?
nuovi oggetti? Il programma sarà inutilizzabile, non c'è abbastanza memoria.
Un vero assemblatore cancella gli oggetti persi durante l'operazione del programma, non
solo alla fine del programma. Ecco perché è permesso uno stile di programmazione speciale.
possiamo moltiplicare gli oggetti in qualsiasi condizione e in qualsiasi quantità.
La produttività al contrario è generalmente aumentata. La rimozione manuale richiede una notevole quantità di tempo nel flusso principale. + la cancellazione avviene elemento per elemento. Confronta due versioni dello script in questo thread, per esempio. La differenza di velocità è di diverse volte. Anche l'efficienza della memoria sale. Perché il raccoglitore di rifiuti sposta gli oggetti compattati tra loro. Se lo si gestisce manualmente, si creano dei buchi di memoria liberi che non sono così facili da riutilizzare. Inoltre, il garbage collector lavora in un altro thread. Il tempo di base non è sprecato. Tutto sommato, un vantaggio.
Hmm... E in un raccoglitore di rifiuti, la cancellazione non è elementare? Senza contare che l'altro thread, quando non ci sono core liberi, viene eseguito dallo stesso core, e rallenta il thread principale.
Secondo me, in generale, con un'attenta considerazione, la rimozione dei rifiuti da parte dell'utente è sempre più efficiente della rimozione da parte del garbage collector. Tuttavia, se non ti interessa, lo spazzino vince sicuramente.
Ecco perché non mi piace il garbage collector, perché incoraggia questo stesso trattamento indifferente delle risorse.
Questo deve essere l'"assemblatore" che dà il messaggio sulle perdite di memoria quando il lavoro è finito.
Probabilmente cancella anche gli oggetti rimasti. Ma anche se li cancella, c'è un grande
differenza - li cancella solo alla fine del lavoro. E se in un ciclo plurimo vengono creati nuovi oggetti?
nuovi oggetti? Il programma sarà inutilizzabile, non c'è abbastanza memoria.
Un vero assemblatore cancella gli oggetti persi durante l'operazione del programma, non
solo alla fine del programma. Ecco perché è permesso uno stile di programmazione speciale.
possiamo moltiplicare gli oggetti in qualsiasi condizione e in qualsiasi quantità.
Proprio così. Ecco perché non mi piace lavorare con l'assemblatore - l'utente non fa attenzione a quanti oggetti ha creato e dove.
Fondamentalmente, semplifica anche lo sviluppo in qualche modo - non devi ricordarti di cancellare quello occupato. Builder trova il momento in cui l'oggetto non è più referenziato, e lo rimuove. Ma questa posizione mi disgusta. È a causa di questa posizione che abbiamo programmi che girano sempre più lentamente, che hanno bisogno di risorse hardware sempre più potenti per compiti di complessità simile.
Vasily, mi dispiace, ma tu non capisci assolutamente nulla di quello che stai cercando di argomentare. Niente di niente e in nessun modo.
Hmmm... E nel raccoglitore di rifiuti la cancellazione non è elementare? Per non parlare del fatto che un altro thread, quando non ci sono core liberi - è fatto dallo stesso core, e rallenta il thread principale.
Secondo me, in generale, con un'attenta considerazione, la rimozione dei rifiuti da parte dell'utente è sempre più efficiente della rimozione da parte del garbage collector. Tuttavia, se non ti interessa, lo spazzino vince sicuramente.
Ecco perché non mi piace il garbage collector, incoraggia questo stesso trattamento indifferente delle risorse.
Piuttosto che fare supposizioni su come funziona un garbage collector, basta confrontare la velocità della rimozione automatica degli oggetti con la rimozione manuale. Tutte le fantasie svaniranno all'istante.
confrontare le velocità della rimozione automatica degli oggetti e della rimozione manuale degli oggetti.
La risposta è preferibilmente subito. Non c'è sempre tempo per gli esperimenti.