2012-01-20 17 views
61

Lo standard fornisce un modello di specializzazione di std::unique_ptr che chiama correttamente il delete[] dal suo distruttore:Perché non esiste una specializzazione std :: shared_ptr <T[]>?

void func() 
{ 
    std::unique_ptr<int[]> arr(new int[10]); 

    ....... 
} 

Con std::shared_ptr questa specializzazione non è disponibile, quindi è necessario fornire una delezione che chiama correttamente delete[]:

void func() 
{ 
    // Usage 
    shared_ptr array (new double [256], [](double* arr) { delete [] arr; }); 

    .............. 
} 

Si tratta semplicemente di una svista? (nello stesso modo in cui esiste un std::copy_if) o c'è un motivo?

+3

N.B. c'è una nuova proposta per aggiungere questo per C++ 17, basato sul lavoro in Boost, vedi http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3640.html –

+0

Notate che molto del meccanismo 'shared_ptr' dovrebbe essere disabilitato quando si lavora con gli array, come ad esempio la possibilità di fare riferimento a un suboggetti. –

risposta

65

Il LWG (gruppo di lavoro della biblioteca del comitato C++) ha considerato brevemente la possibilità, ma l'idea non è stata senza polemiche. Sebbene la polemica riguardasse principalmente una funzionalità aggiunta alla proposta shared_ptr<T[]> che avrebbe potuto essere eliminata (aritmetica su shared_ptr<T[]>).

Ma alla fine la vera ragione reale è che sebbene sia stato discusso, non c'è mai stata una proposta scritta reale di fronte al LWG per farlo. Non ha mai fatto esplodere la lista di priorità di nessuno (incluso il mio) in modo sufficiente da dedicare tempo alla stesura di una proposta.

Le conversazioni informali sono recentemente ricominciate su questo argomento tra alcuni membri del LWG e l'ho personalmente prototipato. Ma non c'è ancora una proposta scritta per questo. Penso che sarebbe uno strumento aggiuntivo decente nella cassetta degli attrezzi. Se mai accadrà o no, nessuno lo sa.

Aggiorna

supporto Array per shared_ptr ad oggi un progetto di TS:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4077.html

Update (2017)

Questo è ora supportata in C++ 17. Vedi caso 3 di shared_ptr::shared_ptr()

+2

Prima domanda "perché non c'è ..." con una risposta reale che ho visto anche un array allocato dinamicamente? Con vector e std :: array, in realtà non vediamo il bisogno (?) – Nim

+12

@Nim: 'std :: unique_ptr ' (che esiste) è utile quando il sovraccarico è tremendamente importante per te. A differenza di 'vector ', 'unique_ptr ' non include l'overhead per capacità, o anche dimensione. Il client probabilmente dovrà aggiungere un overhead esterno per le dimensioni, ma se l'array non viene mai ridimensionato, non per la capacità. Ora ciò non rende 'unique_ptr ' un migliore 'vector '. Anzi, penso che i casi d'uso del primo saranno rari rispetto a quest'ultimo. Ma il tasso di utilizzo non è zero per il primo. –

+3

Analogamente, 'shared_ptr ' a volte può sostituire 'shared_ptr >' con overhead inferiore. La semplice esistenza e il continuo supporto di 'boost :: shared_array ' è un argomento che alcuni programmatori trovano utile per un tale strumento. –

Problemi correlati