Come si comporta esattamente il typedef 'reference'?

Question

contenitori STL hanno un reference e const_referencetypedef, che, in molti casi che ho visto (contenitori di bool essendo le uniche eccezioni mi viene in mente), potrebbe essere banalmente definito come

typedef value_type& reference; 
typedef const value_type& const_reference; 

cosa esattamente, tuttavia , la semantica di questi tipi?

Da quello che ho capito, si suppone che "si comportino come riferimenti al tipo di valore", ma cosa significa esattamente?

MSDN dice che è reference:

Un tipo che fornisce un riferimento a un elemento memorizzato in un vettore.

Ma cosa significa esattamente? Hanno bisogno di sovraccaricare operatori specifici o avere un comportamento specifico? Se sì, qual è il comportamento richiesto?

Answer 1

quello che stai chiedendo è "Posso sempre dereferenziare un riferimento? E sì, è possibile. Ciò significa Dereferenced reference può fare tutto dereferenziato value_type& può fare, che è tutto value_type può fare. Se questo ha un senso per voi.

---

non si può sovraccaricare gli operatori sul typedef. typedef hanno lo stesso comportamento come il tipo a cui sono assegnati. il motivo per cui sono typedef è quello di renderli meno ingombranti e di fornire una "interfaccia" comune

Il motivo reference esiste per evitare che cose come questa:

template<typename T> 
struct foo { 
    T& bar(); 

    typedef T& reference; 
    reference baz(); 
} 

foo<int> x; 
foo<int>::T& y = x.bar(); // error! returns a T& but I can't create one! 
foo<int>::reference z = x.baz(); // ok! 

E 'anche un'interfaccia più pulita e consente l'uso di SFINAE:

template<typename T> 
typename T::reference second(T::reference& t) { return t.at(1); }; 

template<typename T> 
T& second(T& t) { return t[1]; }; 

std::vector v(10); 
foo f(10); // type with [] overloaded but no reference typedef 
second(x) = 5; // calls first def 
second(f) = 3; // calls second def 

Answer 2

Credo che parte del problema deriva da un presupposto che ripartitori sono utili. Allocators (almeno pre-C++ 11) were something of a late addition to the STL:

La gente voleva contenitori indipendenti dal modello di memoria, che era un po 'eccessivo, perché la lingua non include modelli di memoria. Le persone volevano che la libreria fornisse un meccanismo per l'astrazione dei modelli di memoria. Le versioni precedenti di STL presupponevano che la dimensione del contenitore sia espressa come un numero intero di tipo size_t e che la distanza tra due iteratori sia di tipo ptrdiff_t. E ora ci è stato detto, perché non ti astraggo da questo? È un ordine alto perché la lingua non si distingue da quella; Gli array C e C++ non sono parametrizzati da questi tipi. Abbiamo inventato un meccanismo chiamato "allocatore", che incapsula informazioni sul modello di memoria. Ciò ha causato gravi conseguenze per ogni componente della biblioteca. Potresti chiederti quali modelli di memoria hanno a che fare con gli algoritmi o le interfacce del contenitore. Se non puoi usare cose come size_t, non puoi usare cose come T* a causa di diversi tipi di puntatori (T*, T huge *, ecc.). Quindi non è possibile utilizzare i riferimenti perché con diversi modelli di memoria si hanno diversi tipi di riferimento. C'erano enormi conseguenze sulla biblioteca.

Purtroppo, they turned out to be substandard:

ho inventato ripartitori a che fare con architettura di memoria di Intel. Non sono idee così cattive in teoria - avere uno strato che incapsula tutte le cose di memoria: puntatori, riferimenti, ptrdiff_t, size_t. Sfortunatamente non possono funzionare nella pratica. Ad esempio,

vector<int, alloc1> a(...); 
vector<int, alloc2> b(...); 

non si può dire ora:

find(a.begin(), a.end(), b[1]); 

b[1] restituisce un alloc2::reference e non int&. Potrebbe essere una mancata corrispondenza di tipo. È necessario cambiare il modo in cui il linguaggio principale gestisce i riferimenti per rendere davvero utili gli allocatori.

Il reference typedef è destinato a tornare qualunque sia l'equivalente di T& è per l'allocatore in questione. Sulle architetture moderne, questo è probabilmente T&. Tuttavia, l'ipotesi era che su alcune architetture potesse essere qualcosa di diverso (ad esempio, un compilatore che puntava su un'architettura con puntatori "vicini" e "lontani" potrebbe richiedere una sintassi speciale per i riferimenti "vicini" e "lontani"). Purtroppo, questa brillante idea si è rivelata meno brillante. C++ 11 apporta modifiche sostanziali agli allocatori - aggiungendo gli allocatori con scope - e il modello di memoria. Devo ammettere che non ne so abbastanza delle modifiche di C++ 11 w.r.t. allocatori per dire se le cose migliorano o peggiorano.

---

Guardando le osservazioni sulla domanda iniziale, dal momento che la standard in realtà non precisa in che modo i contenitori devono essere attuate (anche se la norma non ha messo così tanti requisiti sul comportamento dei contenitori che potrebbe pure. ..), qualunque sia il tipo che si digita come reference deve avere il comportamento di T& su cui qualcuno potrebbe potenzialmente fare affidamento quando si implementa il contenitore: un oggetto di tipo reference dovrebbe essere un alias trasparente dell'oggetto originale, assegnandogli dovrebbe cambiare il valore di l'oggetto originale senza affettare, non è necessario supportare "reinserire" lo reference, prendendo l'indirizzo dello reference dovrebbe restituire l'indirizzo della o oggetto originale, ecc. Se possibile, dovrebbe essere in realtà T&; e l'unico caso che posso immaginare dove non sarebbe possibile sarebbe se steste allocando memoria che non si possa manipolare tramite puntatori o riferimenti (ad esempio, se la "memoria" fosse effettivamente su disco, o se la memoria fosse effettivamente assegnato su un computer separato e raggiungibile tramite la rete tramite chiamate RPC, ecc.).

Answer 3

Preso fuori norma:

Definisce anche reference come un typedef di value_type& che è un typedef di T

(risposta New come quello precedente era diversa messa a fuoco)