Non penso che abbia davvero nulla a che fare con gli adattatori di container piuttosto che con i contenitori (anche se ammetto che non sono sicuro esattamente perché viene omesso il costruttore corretto).
Quando si utilizza una lista di inizializzazione rinforzato con std::vector, si sta utilizzando questo (nuovo in C++ 11) costruttore:
vector(initializer_list<T>, const Allocator& = Allocator());
Guardando la definizione di std::queue, i costruttori disponibili sono:
explicit queue(const Container&);
explicit queue(Container&& = Container());
template <class Alloc> explicit queue(const Alloc&);
template <class Alloc> queue(const Container&, const Alloc&);
template <class Alloc> queue(Container&&, const Alloc&);
template <class Alloc> queue(const queue&, const Alloc&);
template <class Alloc> queue(queue&&, const Alloc&);
Un costruttore che prende una lista di inizializzazione è assente.
Sono abbastanza sicuro che nonostante sia un adattatore per container, tale costruttore sarebbe banale se lo si desiderava. Basta per esempio:
#include <deque>
#include <initializer_list>
#include <iostream>
template <class T, class container=std::deque<T> >
class myqueue {
container data;
public:
explicit myqueue(std::initializer_list<T> t) : data(t) {}
void pop() { data.pop_front(); }
T front() const { return data.front(); }
bool empty() const { return data.empty(); }
};
int main(){
myqueue<int> data {1, 2, 3, 4};
while (!data.empty()) {
std::cout << data.front() << "\n";
data.pop();
}
return 0;
}
g ++ 4.7 accetta questo senza alcun problema, e produce esattamente l'output che ci si aspetterebbe:
1
2
3
4
Anche se non ho ancora testato con altri compilatori, posso' Non vedo alcun motivo per cui altri compilatori non funzionerebbero bene con questo (a condizione che implementino le funzionalità necessarie, ovviamente).
Edit: Ho appena fatto un po 'di ricerca nei documenti del comitato proponendo l'aggiunta di initalizer_lists a C++ (ad esempio, N1890, N1919, N2100, N2215, N2220) e mi sembra una semplice svista. Molti dei primi articoli sono più concettuali, ma l'N2220 ha una buona dose di linguaggio proposto per il documento di lavoro. Per std::array (per un esempio) specifica in modo specifico che non è necessaria alcuna modifica. Passa quindi a deque, vector, [unordered_][multi_](set|map) e mostra le modifiche necessarie per ciascuna, ma non viene fatto alcun accenno allo stack o alla coda, in nessuna direzione. Nessuna proposta di aggiungere il supporto per std::initializer_list, né il ragionamento (come std::array) per la loro omissione.
Direi che si trattava di una semplice svista, che probabilmente è sfuggita per due motivi: 1) gli adattatori sono quasi, ma non abbastanza contenitori, e 2) le classi di adattatori non sembrano essere usate per intero molto, quindi dimenticarsi di loro era probabilmente abbastanza facile (e, naturalmente, la pervasiva terza ragione: la maggior parte dei membri attivi del comitato sono orribilmente oberati di lavoro).
Edit2: Probabilmente dovrei aggiungere più un dettaglio: dal stack e queue possono entrambi accettare un altro contenitore per l'inizializzazione, si può abbastanza facilmente fare qualcosa di simile:
std::stack<int> data(std::vector<int>{1,2,3,4});
è abbastanza prolisso, ma improbabile causa una perdita di efficienza (il contenitore verrà passato come riferimento di valore, quindi la sua rappresentazione sarà "rubata" anziché copiata). Tuttavia, vi è un avvertimento: se il tipo di contenitore che si utilizza non corrisponde al contenitore sottostante l'adattatore del contenitore, si otterrà una copia anziché uno spostamento (e, di conseguenza, si potrebbe perdere un po 'di efficienza).
È possibile controllare il riferimento sui contenitori [qui] (http://www.cplusplus.com/reference/stl/). Puoi anche dare un'occhiata a boost :: assign library [here] (http://www.boost.org/doc/libs/1_42_0/libs/assign/doc/index.html). –