Nell'ambito dello sviluppo di giochi in C ++, quali sono i tuoi schemi preferiti per quanto riguarda l'uso dei puntatori (sia esso nessuno, grezzo, mirato, condiviso o comunque tra intelligente e muto)?
Potresti considerare
Risposte:
Dopo aver provato vari approcci, oggi mi trovo in linea con la Guida allo stile di Google C ++ :
Se hai davvero bisogno della semantica del puntatore, scoped_ptr è fantastico. Dovresti usare std :: tr1 :: shared_ptr solo in condizioni molto specifiche, come quando gli oggetti devono essere tenuti dai contenitori STL. Non dovresti mai usare auto_ptr. [...]
In generale, preferiamo progettare codice con chiara proprietà dell'oggetto. La proprietà dell'oggetto più chiara si ottiene utilizzando direttamente un oggetto come campo o variabile locale, senza utilizzare affatto i puntatori. [..]
Sebbene non siano raccomandati, i puntatori conteggiati di riferimento sono talvolta il modo più semplice ed elegante per risolvere un problema.
Seguo anche il treno del pensiero "forte proprietà". Mi piace delineare chiaramente che "questa classe possiede questo membro" quando è appropriato.
Uso raramente shared_ptr. Se lo faccio, faccio un uso liberale di weak_ptrogni volta che posso, così posso trattarlo come un handle per l'oggetto invece di aumentare il conteggio dei riferimenti.
Uso scoped_ptrdappertutto. Mostra evidente proprietà. L'unico motivo per cui non faccio solo oggetti del genere è che un membro è perché puoi inoltrarli dichiarandoli se sono in scoped_ptr.
Se ho bisogno di un elenco di oggetti, utilizzo ptr_vector. È più efficiente e ha meno effetti collaterali rispetto all'utilizzo vector<shared_ptr>. Penso che potresti non essere in grado di inoltrare il tipo in ptr_vector (è passato un po '), ma la semantica ne vale la pena secondo me. Fondamentalmente se si rimuove un oggetto dall'elenco, questo viene eliminato automaticamente. Ciò dimostra anche la proprietà evidente.
Se ho bisogno di un riferimento a qualcosa, provo a renderlo un riferimento anziché un puntatore nudo. A volte questo non è pratico (cioè ogni volta che hai bisogno di un riferimento dopo che l'oggetto è stato costruito). In entrambi i casi, i riferimenti mostrano ovviamente che non sei il proprietario dell'oggetto e se segui la semantica dei puntatori condivisi ovunque, i puntatori nudi in genere non causano ulteriore confusione (specialmente se segui una regola "nessuna eliminazione manuale") .
Con questo metodo, un gioco per iPhone su cui ho lavorato è stato in grado di avere una sola deletechiamata, e quello era nel bridge da Obj-C a C ++ che ho scritto.
In generale, sono dell'opinione che la gestione della memoria sia troppo importante per essere lasciata agli umani. Se puoi automatizzare la cancellazione, dovresti. Se l'overhead di shared_ptr è troppo costoso in fase di esecuzione (supponendo che tu abbia disattivato il supporto per il threading, ecc.), Probabilmente dovresti utilizzare qualcos'altro (ad esempio un modello bucket) per ridurre le allocazioni dinamiche.
Usa lo strumento giusto per il lavoro.
Se il tuo programma può generare eccezioni, assicurati che il tuo codice sia a conoscenza delle eccezioni. L'uso di puntatori intelligenti, RAII ed evitare la costruzione in 2 fasi sono buoni punti di partenza.
Se hai riferimenti ciclici senza semantica chiara sulla proprietà, puoi prendere in considerazione l'uso di una libreria di raccolta rifiuti o il refactoring del tuo progetto.
Buone librerie ti permetteranno di codificare il concetto non sul tipo, quindi nella maggior parte dei casi non dovrebbe importare quale tipo di puntatore stai usando oltre ai problemi di gestione delle risorse.
Se lavori in un ambiente multi-thread, assicurati di capire se il tuo oggetto è potenzialmente condiviso tra thread. Uno dei motivi principali per considerare l'utilizzo di boost :: shared_ptr o std :: tr1 :: shared_ptr è perché utilizza un conteggio dei riferimenti thread-safe.
Se sei preoccupato per l'allocazione separata dei conteggi di riferimento, ci sono molti modi per aggirare questo. Utilizzando la libreria boost :: shared_ptr è possibile raggruppare i contatori di riferimento o utilizzare boost :: make_shared (la mia preferenza) che alloca l'oggetto e il conteggio dei riferimenti in una singola allocazione, alleviando così la maggior parte dei problemi di cache cache che le persone hanno. È possibile evitare l'hit di prestazioni dell'aggiornamento del conteggio dei riferimenti nel codice critico delle prestazioni tenendo un riferimento all'oggetto al livello più alto e passando i riferimenti diretti all'oggetto.
Se hai bisogno di una proprietà condivisa ma non vuoi pagare il costo del conteggio dei riferimenti o della raccolta dei rifiuti, considera l'utilizzo di oggetti immutabili o una copia su idioma in scrittura.
Tieni presente che di gran lunga le tue più grandi vittorie in termini di prestazioni saranno a livello di architettura, seguite da un livello di algoritmo e, sebbene queste preoccupazioni di basso livello siano molto importanti, dovrebbero essere affrontate solo dopo aver affrontato i problemi principali. Se hai a che fare con problemi di prestazioni a livello di errori nella cache, hai tutta una serie di problemi che devi anche conoscere come la falsa condivisione che non ha nulla a che fare con i puntatori per dire.
Se stai utilizzando i puntatori intelligenti solo per condividere risorse come trame o modelli, prendi in considerazione una libreria più specializzata come Boost.Flyweight.
Una volta adottato il nuovo standard, spostare la semantica, i riferimenti ai valori e l'inoltro perfetto renderanno il lavoro con oggetti e contenitori costosi molto più semplice ed efficiente. Fino ad allora non archiviare i puntatori con semantica di copia distruttiva, come auto_ptr o unique_ptr, in un contenitore (il concetto standard). Prendi in considerazione l'utilizzo della libreria Boost.Pointer Container o l'archiviazione dei puntatori intelligenti di proprietà condivisa in Container. Nel codice critico per le prestazioni puoi considerare di evitarli entrambi a favore di contenitori intrusivi come quelli di Boost.Intrusive.
La piattaforma target non dovrebbe davvero influenzare troppo la tua decisione. Dispositivi integrati, smartphone, telefoni stupidi, PC e console possono eseguire correttamente il codice. Requisiti di progetto come budget di memoria rigidi o nessuna allocazione dinamica mai / dopo il caricamento sono preoccupazioni più valide e dovrebbero influenzare le tue scelte.
Se stai usando C ++ 0x, usa std::unique_ptr<T>.
Non ha un sovraccarico prestazionale, a differenza del std::shared_ptr<T>quale ha un sovraccarico di conteggio dei riferimenti. Un unique_ptr possiede il suo puntatore e puoi trasferire la proprietà con la semantica di spostamento di C ++ 0x . Non puoi copiarli - spostali solo.
Può anche essere utilizzato in contenitori, ad esempio std::vector<std::unique_ptr<T>>, che è binario compatibile e identico nelle prestazioni std::vector<T*>, ma non perderà memoria se si cancellano elementi o si cancella il vettore. Ciò ha anche una migliore compatibilità con gli algoritmi STL rispetto a ptr_vector.
IMO per molti scopi questo è un contenitore ideale: accesso casuale, eccezioni sicure, previene perdite di memoria, sovraccarico basso per la riallocazione vettoriale (si trascina solo attorno ai puntatori dietro le quinte). Molto utile per molti scopi.
È buona norma documentare quali classi possiedono i puntatori. Preferibilmente, usi semplicemente oggetti normali e nessun puntatore ogni volta che puoi.
Tuttavia, quando è necessario tenere traccia delle risorse, passare i puntatori è l'unica opzione. Ci sono alcuni casi:
Penso che riguardi praticamente come gestisco le mie risorse in questo momento. Il costo di memoria di un puntatore come shared_ptr è generalmente il doppio del costo di memoria di un puntatore normale. Non penso che questo sovraccarico sia troppo grande, ma se hai poche risorse dovresti considerare di progettare il tuo gioco per ridurre il numero di puntatori intelligenti. In altri casi, ho appena progettato buoni principi come i proiettili sopra e il profiler mi dirà dove avrò bisogno di più velocità.
Per quanto riguarda in particolare i suggerimenti di boost, penso che dovrebbero essere evitati fintanto che la loro implementazione non è esattamente ciò di cui hai bisogno. Arrivano ad un costo che è più grande di quanto inizialmente qualcuno si aspetterebbe. Forniscono un'interfaccia che consente di saltare parti vitali e importanti della gestione della memoria e delle risorse.
Quando si tratta di qualsiasi sviluppo software, penso che sia importante pensare ai tuoi dati. È molto importante il modo in cui i tuoi dati sono rappresentati in memoria. La ragione di ciò è che la velocità della CPU è aumentata ad un ritmo molto maggiore rispetto al tempo di accesso alla memoria. Questo spesso rende la memoria cache il principale collo di bottiglia della maggior parte dei moderni giochi per computer. Avere i dati allineati linearmente nella memoria in base all'ordine di accesso è molto più intuitivo per la cache. Questo tipo di soluzioni spesso porta a progetti più puliti, codice più semplice e codice sicuramente più facile da eseguire il debug. I puntatori intelligenti portano facilmente a frequenti allocazioni dinamiche di memoria delle risorse, questo le fa sparpagliare in tutta la memoria.
Questa non è un'ottimizzazione prematura, è una decisione salutare che può e deve essere presa il prima possibile. È una questione di comprensione architettonica dell'hardware su cui verrà eseguito il software ed è importante.
Modifica: ci sono alcune cose da considerare riguardo alle prestazioni dei puntatori condivisi:
Tendo a utilizzare i puntatori intelligenti ovunque. Non sono sicuro che sia una buona idea, ma sono pigro e non riesco a vedere alcun vero svantaggio [tranne se volevo fare un po 'di aritmetica del puntatore in stile C]. Uso boost :: shared_ptr perché so che posso copiarlo in giro - se due entità condividono un'immagine, quindi se una muore l'altra non dovrebbe perdere anche l'immagine.
Il rovescio della medaglia di questo è se un oggetto cancella qualcosa che punta e possiede, ma anche qualcos'altro lo punta, quindi non viene eliminato.
I vantaggi della gestione della memoria e della documentazione forniti da buoni puntatori intelligenti significano che li uso regolarmente. Tuttavia, quando il profiler si dirige e mi dice che un utilizzo particolare mi sta costando, tornerò indietro a una gestione più puntuale del neolitico.
Sono vecchio, oldskool e un contatore di cicli. Nel mio lavoro uso puntatori non elaborati e nessuna allocazione dinamica in fase di esecuzione (tranne i pool stessi). Tutto è raggruppato e la proprietà è molto rigida e mai trasferibile, se davvero necessario scrivo un allocatore di piccoli blocchi personalizzato. Mi assicuro che ci sia uno stato durante il gioco per ogni pool per cancellare se stesso. Quando le cose diventano pelose, avvolgo gli oggetti nelle maniglie in modo da poterli spostare, ma preferirei di no. I contenitori sono ossa personalizzate ed estremamente nude. Inoltre non riutilizzo il codice.
Anche se non direi mai la virtù di tutti i puntatori intelligenti, i contenitori, gli iteratori e quant'altro, sono noto per essere in grado di programmare in modo estremamente veloce (e ragionevolmente affidabile, anche se non è consigliabile che gli altri saltino nel mio codice per ragioni piuttosto ovvie, come attacchi di cuore e incubi perpetui).
Al lavoro, ovviamente, tutto è diverso, a meno che non stia prototipando, cosa che per fortuna riesco a fare molto.
Quasi nessuno, anche se questa è certamente una risposta strana, e probabilmente non è vicino a nessuno adatto a tutti.
Ma ho trovato molto più utile nel mio caso personale memorizzare tutte le istanze di un particolare tipo in una sequenza centrale ad accesso casuale (thread-safe) e invece di lavorare con indici a 32 bit (indirizzi relativi, ad es.) , piuttosto che puntatori assoluti.
Per iniziare:
Tnon saranno mai troppo disperse nella memoria. Ciò tende a ridurre i mancati cache per tutti i tipi di schemi di accesso, anche attraversando strutture collegate come alberi se i nodi sono collegati insieme usando indici anziché puntatori.Detto questo, la convenienza è un aspetto negativo e la sicurezza del tipo. Non possiamo accedere a un'istanza di Tsenza avere accesso sia al contenitore che all'indice. E un vecchio int32_tnon ci dice nulla su quale tipo di dati si riferisca, quindi non c'è sicurezza del tipo. Potremmo accidentalmente provare ad accedere a Barusando un indice a Foo. Per mitigare il secondo problema, faccio spesso questo genere di cose:
struct FooIndex
{
int32_t index;
};Che sembra un po 'sciocco ma mi restituisce la sicurezza del tipo in modo che le persone non possano accidentalmente provare ad accedere a Barattraverso un indice Foosenza un errore del compilatore. Per comodità, accetto solo il leggero inconveniente.
Un'altra cosa che potrebbe essere un grosso inconveniente per le persone è che non posso usare il polimorfismo basato sull'ereditarietà in stile OOP, dal momento che ciò richiederebbe un puntatore di base che possa puntare a tutti i tipi di sottotipi diversi con dimensioni e requisiti di allineamento diversi. Ma in questi giorni non uso molto l'eredità: preferisco l'approccio ECS.
Per quanto riguarda shared_ptr, provo a non usarlo così tanto. Il più delle volte non trovo sensato condividere la proprietà e farlo in modo casuale può portare a perdite logiche. Spesso almeno ad alto livello, una cosa tende a appartenere a una cosa. Dove spesso trovavo allettante usare shared_ptrera prolungare la durata di un oggetto in luoghi che non si occupavano così tanto della proprietà, come solo una funzione locale in un thread per assicurarsi che l'oggetto non fosse distrutto prima che il thread fosse finito usandolo.
Per affrontare quel problema, invece di usare shared_ptro GC o qualcosa del genere, spesso preferisco attività di breve durata in esecuzione da un pool di thread e lo faccio in modo che se quel thread richiede di distruggere un oggetto, che la distruzione effettiva sia rinviata a una cassaforte momento in cui il sistema può garantire che nessun thread debba accedere a detto tipo di oggetto.
A volte finisco ancora con il conteggio dei ref, ma lo tratto come una strategia dell'ultima risorsa. E ci sono alcuni casi in cui ha davvero senso condividere la proprietà, come l'implementazione di una struttura di dati persistente, e lì trovo che abbia perfettamente senso cercare shared_ptrsubito.
Quindi, per lo più, uso principalmente gli indici e uso con parsimonia puntatori sia grezzi che intelligenti. Mi piacciono gli indici e il tipo di porte che si aprono quando sai che i tuoi oggetti sono archiviati in modo contiguo e non sparsi nello spazio della memoria.