Nuovo (std :: nothrow) vs. Nuovo all'interno di un blocco try/catch

Question

Ho fatto qualche ricerca dopo l'apprendimento new, a differenza di malloc() a cui sono abituato, non restituisce NULL per allocazioni non riuscite e ho trovato che ci sono due modi distinti di verificare se il nuovo fosse o meno riuscito. Queste due vie sono:

try 
{ 
    ptr = new int[1024]; 
} 
catch(std::bad_alloc& exc) 
{ 
    assert(); 
}; 

e

ptr = new (std::nothrow) int[1024]; 
if(ptr == NULL) 
    assert(); 

Credo che i due modi raggiungere lo stesso obiettivo, (! Correggetemi se sbaglio ovviamente), quindi la mia domanda è questa:

che è l'opzione migliore per controllare se new riuscito, basata interamente sulla leggibilità, manutenibilità, e la performance, trascurando c de facto ++ convenzione di programmazione.

Answer 1

Considera quello che stai facendo. Stai allocando memoria. E se per qualche motivo l'allocazione della memoria non funziona, è assert. Che è più o meno esattamente ciò che accadrà se lasci che lo std::bad_alloc si propaga nuovamente a main. In una build di rilascio, dove assert è un no-op, il programma si arresta in modo anomalo quando tenta di accedere alla memoria. Quindi è come far scoppiare l'eccezione: fermare l'app.

Quindi, ponetevi una domanda: avete davvero il a preoccuparsi di cosa succede se esaurite la memoria? Se tutto quello che stai facendo è affermare, allora il metodo di eccezione è migliore, perché non ingombra il tuo codice con numeri casuali assert s. Hai appena lasciato che l'eccezione ricada su main.

Se in effetti si dispone di un codepath speciale nel caso in cui non è possibile allocare memoria (ovvero, è effettivamente possibile continuare a funzionare), le eccezioni possono o non possono essere un modo per andare, a seconda di ciò che il codepath è . Se il codepath è solo un interruttore impostato con un puntatore nullo, la versione nothrow sarà più semplice.Se invece, è necessario fare qualcosa di diverso (tirare da un buffer statico, o eliminare alcune cose, o qualsiasi altra cosa), quindi catturare std::bad_alloc è abbastanza buono.

Answer 2

Dipende dal contesto in cui l'assegnazione avviene. Se il tuo programma può continuare anche se l'allocazione fallisce (magari restituire un codice di errore al chiamante), usa il metodo std::nothrow e verifica NULL. Altrimenti stareste usando le eccezioni per il controllo del flusso, che non è una buona pratica.

D'altra parte, se il programma assolutamente bisogno di avere che la memoria allocata con successo al fine di essere in grado di funzionare, utilizzare try-catch per la cattura (non necessariamente nelle immediate vicinanze del new) un'eccezione e uscire con grazia dal programma.

Answer 3

Da un punto di vista delle prestazioni puro, poco importa. Esiste un sovraccarico inerente con la gestione delle eccezioni, anche se questo overhead è generalmente utile per la leggibilità e la manutenzione delle applicazioni. Errori di allocazione della memoria di questo tipo non dovrebbero essere nel caso del 99% della tua applicazione, quindi questo dovrebbe accadere di rado.

Dal punto di vista delle prestazioni in genere si vuole evitare l'allocatore di serie a causa della sua relativamente scarso rendimento in ogni caso.

Tutto ciò detto, in genere accetto la versione di lancio delle eccezioni perché generalmente le nostre applicazioni si trovano in uno stato in cui, se l'allocazione della memoria fallisce, non possiamo fare altro che uscire con garbo con un messaggio di errore appropriato e salviamo le prestazioni non richiede il controllo di NULL sulle risorse appena allocate perché, per definizione, un errore di allocazione sposterà l'ambito da dove ciò è importante.

Answer 4

new viene utilizzato per creare oggetti, non allocare memoria, pertanto l'esempio è in qualche modo artificiale.

Generatori di oggetti in genere lanciano se falliscono. Avendo superato l'implementazione new in Visual Studio più volte, non credo che il codice rilevi eccezioni. Pertanto, in genere è opportuno cercare eccezioni durante la creazione di oggetti.

I thinkstd::bad_alloc viene generato solo se la parte di allocazione di memoria non riesce. Non sono sicuro di cosa succederà se passi std::nothrow a new ma il costruttore dell'oggetto getta - c'è un'ambiguità nei documenti che ho letto.

La differenza di prestazioni tra i 2 approcci è probabilmente irrilevante poiché la maggior parte del tempo del processore può essere facilmente spesa nel costruttore di oggetti o nella ricerca nell'heap.

Una regola empirica non è sempre appropriata. Ad esempio, i sistemi in tempo reale limitano in genere le allocazioni di memoria dinamica, quindi new, se presente, verrebbe probabilmente sovraccaricato. In tal caso, potrebbe fare uso di un puntatore nullo restituito e gestire l'errore localmente.