Nie. Nie, Nie, tysiąc razy nie.

Złem jest odniesienie do dynamicznie przydzielanego obiektu i utrata oryginalnego wskaźnika. Kiedy new obiekt bierzesz na siebie obowiązek posiadania gwarantowanego delete.

Ale spójrz na, np, operator<<: że musi zwrócić referencję, lub

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

Powinieneś zwrócić odniesienie do istniejącego obiektu, który nie zniknie natychmiast i w którym nie zamierzasz przenieść własności.

Nigdy nie zwracaj referencji do zmiennej lokalnej lub czegoś takiego, ponieważ nie będzie tam odniesienia.

Możesz zwrócić odwołanie do czegoś niezależnego od funkcji, czego nie spodziewasz się, że funkcja wywołująca weźmie odpowiedzialność za usunięcie. Tak jest w przypadku typowej funkcji operator[].

Jeśli jesteś tworząc coś, powinieneś zwrócić wartość lub wskaźnik (zwykły lub inteligentny). Wartość można zwracać dowolnie, ponieważ przechodzi ona do zmiennej lub wyrażenia w funkcji wywołującej. Nigdy nie zwracaj wskaźnika do zmiennej lokalnej, ponieważ zniknie.

To nie jest zło. Podobnie jak wiele rzeczy w C++, jest to dobre, jeśli jest używane poprawnie, ale jest wiele pułapek, których powinieneś być świadomy podczas korzystania z niego (jak zwracanie odniesienia do zmiennej lokalnej).

Są dobre rzeczy, które można z nim osiągnąć (jak map[name] = "hello world")

Uważam, że odpowiedzi nie są zadowalające, więc dodam moje dwa grosze.

Przeanalizujmy następujące przypadki:

Błędne użycie

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

To jest oczywiście błąd

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

Użycie ze zmiennymi statycznymi

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

To prawda, ponieważ zmienne statyczne istnieją przez cały okres istnienia programu.

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

Jest to również dość powszechne przy implementacji Singleton wzór

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

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

}

Użycie:

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

Operatory

Kontenery bibliotek standardowych w dużym stopniu zależą od użycia operatorów zwracających referencję, na przykład

T & operator*();

Może być stosowany w następujących]}

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

Szybki dostęp do danych wewnętrznych

Są chwile, kiedy & mogą być używane do szybkiego dostępu do danych wewnętrznych

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

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

Z użyciem:

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

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!

"Zwracanie referencji jest złe, ponieważ, po prostu [jak rozumiem] sprawia, że łatwiej przegapić usunięcie "

Value& v = thing->getTheValue();

...nie oznacza, że posiadasz pamięć, o której mowa przez v;

Jednak jest to straszny kod:

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

Jeśli robisz coś takiego, ponieważ "nie wymagasz wskaźnika na tej instancji" to: 1) po prostu dereference wskaźnik, jeśli potrzebujesz odniesienia, i 2) w końcu trzeba wskaźnik, ponieważ trzeba dopasować nowy z delete, i trzeba wskaźnik do wywołania delete.

Są dwa przypadki:

• Const reference --dobry pomysł, czasami, szczególnie dla ciężkich obiektów lub klas proxy, optymalizacja kompilatora

• Non-const reference --bad idea, sometimes, breaks encapsulations

Oba mają ten sam problem -- mogą potencjalnie wskazywać na zniszczony obiekt...

Zalecałbym używanie inteligentnych wskaźników w wielu sytuacjach, w których wymagane jest zwrócenie referencji / wskaźnika.

Zwróć również uwagę na po:

istnieje formalna zasada-Standard C++ (sekcja 13.3.3.1.4 jeśli jesteś zainteresowany) stwierdza, że tymczasowe może być związane tylko z odniesieniem const - jeśli próbujesz użyć odniesienia non-const, kompilator musi oznaczyć to jako błąd.

Nie tylko nie jest złe, ale czasami jest niezbędne. Na przykład implementacja operatora [] std::vector nie byłaby możliwa bez użycia zwracanej wartości odniesienia.

Return reference jest zwykle używany w przeciążaniu operatorów w C++ dla dużych obiektów, ponieważ zwracanie wartości wymaga operacji kopiowania.(w przeciążeniu peratora zwykle nie używamy wskaźnika jako wartości zwracanej)

Ale return reference może powodować problem z alokacją pamięci. Ponieważ odniesienie do wyniku zostanie przekazane z funkcji jako odniesienie do zwracanej wartości, wartość zwracana nie może być zmienną automatyczną.

Jeśli chcesz użyć referencji zwracającej, możesz użyć bufora obiektu statycznego. na przykład

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;
 }

W ten sposób można bezpiecznie zwrócić referencję.

Ale zawsze możesz użyć wskaźnika zamiast referencji do zwracania wartości w functiong.

Dodanie do zaakceptowanej odpowiedzi:

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

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

Argumentowałbym, że ten przykład jest nie w porządku i powinien być unikany, jeśli to możliwe. Dlaczego? Bardzo łatwo jest skończyć zzwisającym odniesieniem .

Aby zilustrować punkt na przykładzie:

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

Wejście do strefy zagrożenia:

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

Myślę, że używanie referencji jako wartości zwracanej funkcji jest znacznie prostsze niż używanie wskaźnika jako wartości zwracanej funkcji. Po drugie, zawsze bezpiecznie byłoby używać zmiennej statycznej, do której odnosi się zwracana wartość.

Najlepiej jest utworzyć obiekt i przekazać go jako parametr odniesienia/wskaźnika do funkcji, która przydziela tę zmienną.

Przydzielanie obiektu w funkcji i zwracanie go jako referencji lub wskaźnika (Wskaźnik jest jednak bezpieczniejszy) jest złym pomysłem ze względu na zwolnienie pamięci na końcu bloku funkcji.

Funkcja jako lvalue (aka, zwracanie referencji non-const) powinna zostać usunięta z C++. To strasznie nieintuicyjne. Scott Meyers chciał min () z takim zachowaniem.

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

Co nie jest tak naprawdę poprawą na

setmin (a, b, 0);

Zdaję sobie sprawę, że funkcja jako lvalue jest ważna dla strumieni w stylu C++, ale warto zwrócić uwagę, że strumienie w stylu C++ są straszne. Nie tylko ja tak myślę... z tego co pamiętam Alexandrescu miał duży artykuł o tym, jak zrobić lepiej, i wierzę, że boost próbował również stworzyć lepszą metodę bezpiecznego typu I/O.

    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 
     }
  };

Funkcja GetPtr może uzyskać dostęp do pamięci dynamicznej po usunięciu lub nawet obiektu null. Co może powodować złe wyjątki dostępu. Zamiast tego getter i setter powinny być zaimplementowane i zweryfikowane rozmiar przed powrotem.

Natknąłem się na prawdziwy problem, gdzie to było naprawdę złe. Zasadniczo programista zwrócił odniesienie do obiektu w wektorze. To było złe!!!

O pełnych szczegółach pisałem w styczniu: http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html

O strasznym kodzie:

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

Tak więc, rzeczywiście, Wskaźnik pamięci stracił po powrocie. Ale jeśli używasz shared_ptr w ten sposób:

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

Pamięć nie zostanie utracona po powrocie i zostanie uwolniona po przypisaniu.