Si può avere il prototipo della tua funzione?Il numero di questi valori è fisso o variabile? Lo decide l'utente o la funzione?
std::list<std::string>& myFunction(...) //non credo siano importanti i parametri passati...
myNode{ char *value; myNode* next;};myNode* myFunction(...);
Se hai delle postcondition sul valore massimo degli elementi potresti usare lo stack (che sarebbe una soluzione abbastanza prestante)
Tuttavia ti consiglio sempre di specificare un valore massimo di elementi della lista nella documentazione, tieni conto che se voglio contare gli elementi devo sapere che tipo di variabile index usare.
Ci sono varie scuole di pensiero a riguardo.Io sono della scuola che allocazione e deallocazione devono andare di pari passo.Chi alloca qualcosa deve anche deallocarla.
dovrai decidere se listDispose cancellerà automaticamente anche il contenuto dei nodi della lista, oppure se lasciarli allocati. Se la lista serve solamente come storage temporaneo, allora meglio deallocarli insieme alla lista stessa. Viceversa, i nodi della lista potrebbero prendere parte di altre strutture definite dall'utente.Entrambi i casi devono essere chiaramente documentati.
Io sono per i Garbage Collector
E poi l'utente client se ne può sbattere della deallocazione (e clros sarebbe molto contento!)
Io sono per i Garbage Collector Purtroppo la deallocazione manuale rompe l'encapsulation, ma lasciando stare l'encapsulation un memory model GC based è molto più sicuro nel gestire gli accessi alla memoria.E poi l'utente client se ne può sbattere della deallocazione (e clros sarebbe molto contento!)
Java attualmente implementa uno dei migliori algoritmi non-realtime per il garbage collector (il Generational garbage collector).Il runtime di Java si inchioda per altri motivi Oggi i GC nei linguaggi compilati nemmeno li senti, per esempio in Go il GC viene runnato in una coroutine che è un thread a parte.
Citazione da: "TheKaneB"Il problema è che questa cosa non è documentata adeguatamente e capita spessissimo che molte Bitmap rimanessero allocate a causa di un qualche meccanismo di Android che manteneva delle reference valide in oggetti non più utilizzati.Se c'è un reference counting non è un "memory leaks"
Il problema è che questa cosa non è documentata adeguatamente e capita spessissimo che molte Bitmap rimanessero allocate a causa di un qualche meccanismo di Android che manteneva delle reference valide in oggetti non più utilizzati.
Citazione da: "TheKaneB"Per risolvere il problema ho dovuto crearmi una funzione che esplora il grafo completo della View e cancella manualmente tutti i riferimenti alle Bitmap usate, e per farlo ho dovuto leggermi il sorgente di alcune parti di Android, perchè questo comportamento non è per nulla documentato.Infatti prima per rompere l'encapsulation intendevo proprio questo (oltre al fatto che lo deve fare il compilatore) non è molto safe quello che hai fatto.Uhm, come hai stabilito che nonostante ci fosse il reference counting quell'oggetto fosse inutilizzato?
Per risolvere il problema ho dovuto crearmi una funzione che esplora il grafo completo della View e cancella manualmente tutti i riferimenti alle Bitmap usate, e per farlo ho dovuto leggermi il sorgente di alcune parti di Android, perchè questo comportamento non è per nulla documentato.
Uhm dovrei studiarmi meglio le API Android, però tutto l'ambaradan non l'ho ben chiaro Leggo che le API native si usano in casi eccezionali perché non gestite dalla VM, però questo solo tramite l'interfaccia JNI (Java Native Interface?), oppure il C.L'oggetto bitmap dovrebbe essere gestito dalla VM e quindi dal GC.Io credo che fosse un buggone pauroso della vecchia VM