Questo è un po 'soggettivo, penso; Non sono sicuro che l'opinione sarà unanime (ho visto molti frammenti di codice in cui vengono restituiti riferimenti).

Secondo un commento a questa domanda che ho appena fatto, riguardo all'inizializzazione dei riferimenti , restituire un riferimento può essere malvagio perché, [come ho capito], rende più facile perdere la sua eliminazione, il che può portare a perdite di memoria.

Questo mi preoccupa, dato che ho seguito degli esempi (a meno che non stia immaginando cose) e l'ho fatto in pochi posti ... Ho capito male? È male? Se è così, quanto male?

Sento che a causa del mio mix di puntatori e riferimenti, combinato con il fatto che sono nuovo in C ++ e la totale confusione su cosa usare quando, le mie applicazioni devono essere un inferno di perdita di memoria ...

Inoltre, capisco che l'utilizzo di puntatori intelligenti / condivisi è generalmente accettato come il modo migliore per evitare perdite di memoria.

In generale, la restituzione di un riferimento è perfettamente normale e avviene sempre.

Se intendi:

int& getInt() {
    int i;
    return i;  // DON'T DO THIS.
}

Questo è ogni sorta di male. Lo stack allocato iscomparirà e non ti riferirai a nulla. Anche questo è male:

int& getInt() {
    int* i = new int;
    return *i;  // DON'T DO THIS.
}

Perché ora il cliente deve eventualmente fare lo strano:

int& myInt = getInt(); // note the &, we cannot lose this reference!
delete &myInt;         // must delete...totally weird and  evil

int oops = getInt(); 
delete &oops; // undefined behavior, we're wrongly deleting a copy, not the original

Nota che i riferimenti rvalue sono ancora solo riferimenti, quindi tutte le applicazioni malvagie rimangono le stesse.

Se si desidera allocare qualcosa che non rientra nell'ambito della funzione, utilizzare un puntatore intelligente (o in generale un contenitore):

std::unique_ptr<int> getInt() {
    return std::make_unique<int>(0);
}

E ora il client memorizza un puntatore intelligente:

std::unique_ptr<int> x = getInt();

I riferimenti vanno anche bene per l'accesso a cose in cui sai che la vita viene mantenuta aperta a un livello superiore, ad esempio:

struct immutableint {
    immutableint(int i) : i_(i) {}

    const int& get() const { return i_; }
private:
    int i_;
};

Qui sappiamo che va bene restituire un riferimento i_perché qualunque cosa ci chiami gestisce la durata dell'istanza della classe, quindi i_vivrà almeno così a lungo.

E, naturalmente, non c'è niente di sbagliato nel solo:

int getInt() {
   return 0;
}

Se la durata deve essere lasciata al chiamante e stai solo calcolando il valore.

Riepilogo: è possibile restituire un riferimento se la durata dell'oggetto non termina dopo la chiamata.

No. No, no, mille volte no.

Ciò che è male è fare riferimento a un oggetto allocato dinamicamente e perdere il puntatore originale. Quando sei newun oggetto, ti impegni ad avere una garanzia delete.

Ma dai un'occhiata, ad esempio, operator<<che deve restituire un riferimento, oppure

cout << "foo" << "bar" << "bletch" << endl ;

non funzionerà.

È necessario restituire un riferimento a un oggetto esistente che non scompare immediatamente e in cui non si intende alcun trasferimento di proprietà.

Non restituire mai un riferimento a una variabile locale o ad una simile, perché non sarà lì per essere referenziato.

Puoi restituire un riferimento a qualcosa di indipendente dalla funzione, che non ti aspetti che la funzione chiamante si assuma la responsabilità dell'eliminazione. Questo è il caso della operator[]funzione tipica .

Se stai creando qualcosa, dovresti restituire un valore o un puntatore (normale o intelligente). È possibile restituire un valore liberamente, poiché sta entrando in una variabile o espressione nella funzione chiamante. Non restituire mai un puntatore a una variabile locale, poiché andrà via.

Trovo le risposte non soddisfacenti, quindi aggiungerò i miei due centesimi.

Analizziamo i seguenti casi:

Uso errato

int& getInt()
{
    int x = 4;
    return x;
}

Questo è ovviamente un errore

int& x = getInt(); // will refer to garbage

Utilizzo con variabili statiche

int& getInt()
{
   static int x = 4;
   return x;
}

Questo è giusto, perché le variabili statiche sono presenti per tutta la durata di un programma.

int& x = getInt(); // valid reference, x = 4

Questo è anche abbastanza comune quando si implementa il modello Singleton

Class Singleton
{
    public:
        static Singleton& instance()
        {
            static Singleton instance;
            return instance;
        };

        void printHello()
        {
             printf("Hello");
        };

}

Uso:

 Singleton& my_sing = Singleton::instance(); // Valid Singleton instance
 my_sing.printHello();  // "Hello"

operatori

I contenitori di librerie standard dipendono fortemente dall'utilizzo di operatori che restituiscono riferimenti, ad esempio

T & operator*();

può essere utilizzato di seguito

std::vector<int> x = {1, 2, 3}; // create vector with 3 elements
std::vector<int>::iterator iter = x.begin(); // iterator points to first element (1)
*iter = 2; // modify first element, x = {2, 2, 3} now

Accesso rapido ai dati interni

Ci sono momenti in cui e possono essere utilizzati per un rapido accesso ai dati interni

Class Container
{
    private:
        std::vector<int> m_data;

    public:
        std::vector<int>& data()
        {
             return m_data;
        }
}

con l'utilizzo:

Container cont;
cont.data().push_back(1); // appends element to std::vector<int>
cont.data()[0] // 1

TUTTAVIA, ciò può causare insidie ​​come questa:

Container* cont = new Container;
std::vector<int>& cont_data = cont->data();
cont_data.push_back(1);
delete cont; // This is bad, because we still have a dangling reference to its internal data!
cont_data[0]; // dangling reference!

Non è male. Come molte cose in C ++, è buono se usato correttamente, ma ci sono molte insidie ​​di cui dovresti essere consapevole quando lo usi (come restituire un riferimento a una variabile locale).

Ci sono buone cose che possono essere raggiunte con esso (come map [name] = "hello world")

"restituire un riferimento è male perché, semplicemente [come ho capito], rende più facile perdere la sua eliminazione"

Non vero. La restituzione di un riferimento non implica la semantica della proprietà. Cioè, solo perché lo fai:

Value& v = thing->getTheValue();

... non significa che ora possiedi la memoria a cui fa riferimento v;

Tuttavia, questo è un codice orribile:

int& getTheValue()
{
   return *new int;
}

Se stai facendo qualcosa del genere perché "non hai bisogno di un puntatore su quell'istanza" allora: 1) dereferenzia il puntatore solo se hai bisogno di un riferimento, e 2) alla fine avrai bisogno del puntatore, perché devi abbinare un nuovo con un'eliminazione e per chiamare l'eliminazione è necessario un puntatore.

Esistono due casi:

• const const - buona idea, a volte, soprattutto per oggetti pesanti o classi proxy, ottimizzazione del compilatore

• riferimento non const - l'idea di idea, a volte, rompe gli incapsulamenti

Entrambi condividono lo stesso problema: possono potenzialmente puntare a oggetti distrutti ...

Consiglio di utilizzare i puntatori intelligenti per molte situazioni in cui è necessario restituire un riferimento / puntatore.

Inoltre, tenere presente quanto segue:

Esiste una regola formale - lo standard C ++ (sezione 13.3.3.1.4 se sei interessato) afferma che un temporaneo può essere associato solo a un riferimento const - se si tenta di utilizzare un riferimento non const il compilatore deve contrassegnarlo come un errore.

Non solo non è cattivo, a volte è essenziale. Ad esempio, sarebbe impossibile implementare l'operatore [] di std :: vector senza usare un valore di ritorno di riferimento.

Aggiunta alla risposta accettata:

struct immutableint {
    immutableint(int i) : i_(i) {}

    const int& get() const { return i_; }
private:
    int i_;
};

Direi che questo esempio non va bene e, se possibile, dovrebbe essere evitato. Perché? È molto facile finire con un riferimento penzolante .

Per illustrare il punto con un esempio:

struct Foo
{
    Foo(int i = 42) : boo_(i) {}
    immutableint boo()
    {
        return boo_;
    }  
private:
    immutableint boo_;
};

entrare nella zona di pericolo:

Foo foo;
const int& dangling = foo.boo().get(); // dangling reference!

il riferimento di ritorno viene generalmente utilizzato nel sovraccarico dell'operatore in C ++ per oggetti di grandi dimensioni, poiché la restituzione di un valore richiede un'operazione di copia (nel sovraccarico del peratore, di solito non si utilizza il puntatore come valore di ritorno)

Ma il riferimento di ritorno può causare problemi di allocazione della memoria. Poiché un riferimento al risultato verrà passato dalla funzione come riferimento al valore restituito, il valore restituito non può essere una variabile automatica.

se si desidera utilizzare il riferimento di ritorno, è possibile utilizzare un buffer di oggetto statico. per esempio

const max_tmp=5; 
Obj& get_tmp()
{
 static int buf=0;
 static Obj Buf[max_tmp];
  if(buf==max_tmp) buf=0;
  return Buf[buf++];
}
Obj& operator+(const Obj& o1, const Obj& o1)
{
 Obj& res=get_tmp();
 // +operation
  return res;
 }

in questo modo, è possibile utilizzare il riferimento di ritorno in modo sicuro.

Ma puoi sempre usare il puntatore invece del riferimento per restituire valore in functiong.

penso che usare il riferimento come valore di ritorno della funzione sia molto più semplice che usare il puntatore come valore di ritorno della funzione. In secondo luogo, sarebbe sempre sicuro utilizzare una variabile statica a cui si riferisce il valore restituito.

La cosa migliore è creare un oggetto e passarlo come parametro di riferimento / puntatore a una funzione che alloca questa variabile.

Allocare l'oggetto in funzione e restituirlo come riferimento o puntatore (il puntatore è più sicuro) è una cattiva idea a causa della liberazione di memoria alla fine del blocco funzione.

    Class Set {
    int *ptr;
    int size;

    public: 
    Set(){
     size =0;
         }

     Set(int size) {
      this->size = size;
      ptr = new int [size];
     }

    int& getPtr(int i) {
     return ptr[i];  // bad practice 
     }
  };

La funzione getPtr può accedere alla memoria dinamica dopo l'eliminazione o anche un oggetto null. Che può causare eccezioni di accesso errato. Invece getter e setter dovrebbero essere implementati e le dimensioni verificate prima di tornare.

La funzione come lvalue (ovvero il ritorno di riferimenti non costanti) deve essere rimossa dal C ++. È terribilmente non intuitivo. Scott Meyers voleva un min () con questo comportamento.

min(a,b) = 0;  // What???

che non è davvero un miglioramento

setmin (a, b, 0);

Quest'ultimo ha persino più senso.

Mi rendo conto che la funzione come lvalue è importante per i flussi in stile C ++, ma vale la pena sottolineare che i flussi in stile C ++ sono terribili. Non sono l'unico a pensarlo ... mentre ricordo che Alexandrescu aveva un ampio articolo su come fare di meglio, e credo che boost abbia anche provato a creare un metodo I / O sicuro di tipo migliore.

Mi sono imbattuto in un vero problema in cui era davvero malvagio. In sostanza uno sviluppatore ha restituito un riferimento a un oggetto in un vettore. È stato male !!!

I dettagli completi di cui ho scritto a gennaio: http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html

Informazioni sul codice orribile:

int& getTheValue()
{
   return *new int;
}

Quindi, in effetti, il puntatore della memoria ha perso dopo il ritorno. Ma se usi shared_ptr in questo modo:

int& getTheValue()
{
   std::shared_ptr<int> p(new int);
   return *p->get();
}

La memoria non viene persa dopo la restituzione e verrà liberata dopo l'assegnazione.