Myślę, że to trochę subiektywne; Nie jestem pewien, czy opinia będzie jednomyślna (widziałem wiele fragmentów kodu, w których zwracane są odwołania).

Zgodnie z komentarzem do tego pytania, które właśnie zadałem, dotyczące inicjowania referencji , zwracanie referencji może być złe, ponieważ [jak rozumiem] ułatwia to pominięcie usunięcia, co może prowadzić do wycieków pamięci.

Martwi mnie to, bo podążałem za przykładami (chyba, że ​​coś sobie wyobrażam) i robiłem to w kilku uczciwych miejscach ... Czy źle zrozumiałem? Czy to jest złe? Jeśli tak, to jak złe?

Wydaje mi się, że z powodu mojego mieszanego zestawu wskaźników i odniesień, w połączeniu z faktem, że jestem nowy w C ++, oraz całkowitym zamieszaniem co do tego, kiedy użyć, gdy moje aplikacje muszą być piekłem pamięci ...

Rozumiem również, że używanie inteligentnych / współdzielonych wskaźników jest ogólnie akceptowane jako najlepszy sposób uniknięcia wycieków pamięci.

Zasadniczo zwracanie referencji jest całkowicie normalne i odbywa się przez cały czas.

Jeśli masz na myśli:

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

To wszelkiego rodzaju zło. Przydział stosu izniknie, a ty nie odnosisz się do niczego. To też jest złe:

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

Ponieważ teraz klient musi w końcu zrobić coś dziwnego:

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

Zauważ, że odniesienia do wartości są nadal tylko odniesieniami, więc wszystkie złe aplikacje pozostają takie same.

Jeśli chcesz przydzielić coś, co wykracza poza zakres funkcji, użyj inteligentnego wskaźnika (lub ogólnie kontenera):

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

A teraz klient przechowuje inteligentny wskaźnik:

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

Referencje są również w porządku, aby uzyskać dostęp do rzeczy, o których wiesz, że całe życie jest otwarte na wyższym poziomie, np .:

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

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

Wiemy tutaj, że można odwoływać się do odwołania, i_ponieważ to, co nas wzywa, zarządza czasem życia instancji klasy, więc i_będzie żyła przynajmniej tak długo.

I oczywiście nie ma nic złego w samym tylko:

int getInt() {
   return 0;
}

Jeśli czas życia należy do dzwoniącego, a ty po prostu obliczasz wartość.

Podsumowanie: można zwrócić referencję, jeśli czas życia obiektu nie skończy się po wywołaniu.

Nie, nie, tysiąc razy nie.

To, co jest złem, odnosi się do dynamicznie przydzielanego obiektu i traci oryginalny wskaźnik. Kiedy jesteś newprzedmiotem, zobowiązujesz się mieć gwarancję delete.

Ale spójrz np. Na operator<<: to musi zwrócić referencję, lub

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

nie zadziała.

Powinieneś zwrócić odniesienie do istniejącego obiektu, który nie odchodzi natychmiast i gdzie nie zamierzasz przenosić prawa własności.

Nigdy nie zwracaj odwołania do zmiennej lokalnej lub innej takiej, ponieważ nie będzie tam odniesienia.

Możesz zwrócić odwołanie do czegoś niezależnego od funkcji, którego nie oczekujesz, że funkcja wywołująca przejmie odpowiedzialność za usunięcie. Dotyczy to typowej operator[]funkcji.

Jeśli coś tworzysz, powinieneś zwrócić wartość lub wskaźnik (zwykły lub inteligentny). Możesz swobodnie zwrócić wartość, ponieważ przechodzi ona do zmiennej lub wyrażenia w funkcji wywołującej. Nigdy nie zwracaj wskaźnika do zmiennej lokalnej, ponieważ ona zniknie.

Uważam, że odpowiedzi nie są satysfakcjonujące, więc dodam dwa centy.

Przeanalizujmy następujące przypadki:

Błędne użycie

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

To oczywiście błąd

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

Zastosowanie ze zmiennymi statycznymi

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

Ma to rację, ponieważ zmienne statyczne istnieją przez cały okres istnienia programu.

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

Jest to również dość powszechne przy wdrażaniu wzorca Singleton

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

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

}

Stosowanie:

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

Operatorzy

Standardowe kontenery biblioteczne w dużym stopniu zależą na przykład od operatorów, które zwracają referencje

T & operator*();

może być użyty w następujący sposób

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 & może być wykorzystany 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

JEDNAK może to prowadzić do takich pułapek:

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!

To nie jest złe. Podobnie jak wiele rzeczy w C ++, jest dobrze, jeśli jest używany poprawnie, ale istnieje wiele pułapek, o których powinieneś pamiętać podczas korzystania z niego (np. Zwracanie odwołania do zmiennej lokalnej).

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

„zwrócenie referencji jest złe, ponieważ po prostu [jak rozumiem] ułatwia to pominięcie jej usunięcia”

Nie prawda. Zwrócenie referencji nie oznacza semantyki własności. To dlatego, że robisz to:

Value& v = thing->getTheValue();

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

Jest to jednak okropny kod:

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

Jeśli robisz coś takiego, ponieważ „nie potrzebujesz wskaźnika w tej instancji”, to: 1) po prostu odłóż wskaźnik, jeśli potrzebujesz odniesienia, i 2) w końcu będziesz potrzebować wskaźnika, ponieważ musisz dopasować nowy z usunięciem, a do wywołania usunięcia potrzebny jest wskaźnik.

Istnieją dwa przypadki:

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

• non-const reference - zły pomysł, czasami psuje enkapsulacje

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

Polecam używanie inteligentnych wskaźników w wielu sytuacjach, w których musisz zwrócić referencję / wskaźnik.

Zwróć również uwagę na następujące kwestie:

Istnieje formalna reguła - Standard C ++ (sekcja 13.3.3.1.4, jeśli jesteś zainteresowany) stwierdza, że ​​tymczasowe może być powiązane tylko z odwołaniem do stałej - jeśli spróbujesz użyć odwołania do stałej, kompilator musi oznaczyć to jako błąd.

Nie tylko nie jest zły, ale czasami jest niezbędny. Na przykład niemożliwe byłoby zaimplementowanie operatora [] std :: vector bez użycia zwracanej wartości referencyjnej.

Dodatek do zaakceptowanej odpowiedzi:

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

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

Twierdziłbym, że ten przykład jest nie w porządku i należy go w miarę możliwości unikać. Dlaczego? Bardzo łatwo jest uzyskać zwisające odniesienie .

Aby zilustrować tę kwestię przykładem:

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!

referencja powrotu jest zwykle używana w przypadku przeciążenia operatora 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 odwołanie zwrotne może powodować problem z alokacją pamięci. Ponieważ odwołanie do wyniku zostanie przekazane z funkcji jako odniesienie do wartości zwracanej, wartość zwracana nie może być zmienną automatyczną.

jeśli chcesz użyć zwracanej wartości, 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żesz bezpiecznie korzystać ze zwracanego odwołania.

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

myślę, że używanie referencji jako wartości zwracanej przez funkcję jest znacznie prostsze niż używanie wskaźnika jako wartości zwracanej przez funkcję. Po drugie, zawsze byłoby bezpiecznie używać zmiennej statycznej, do której odnoszą się wartości zwracane.

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

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

    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, a nawet zerowego obiektu. Co może powodować wyjątki złego dostępu. Zamiast tego należy wprowadzić getter i setter, a przed zwrotem sprawdzić rozmiar.

Funkcja jako lvalue (czyli zwracanie odwołań nie stałych) powinna zostać usunięta z C ++. To jest wyjątkowo nieintuicyjne. Scott Meyers chciał min () z tym zachowaniem.

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

co nie jest tak naprawdę poprawą

setmin (a, b, 0);

To drugie ma nawet większy sens.

Zdaję sobie sprawę, że funkcja jako wartość jest ważna dla strumieni w stylu C ++, ale warto zauważyć, że strumienie w stylu C ++ są okropne. Nie jestem jedynym, który tak myśli ... jak pamiętam Alexandrescu miał duży artykuł na temat tego, jak robić lepiej, i uważam, że boost próbował również stworzyć lepszą metodę bezpiecznych I / O.

Natknąłem się na prawdziwy problem, w którym to rzeczywiście było złe. Zasadniczo programista zwrócił odwołanie do obiektu w wektorze. To było złe!!!

Pełne szczegóły, o których pisałem w Janurary: http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html

O okropnym kodzie:

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

Rzeczywiście wskaźnik pamięci utracony po powrocie. Ale jeśli używasz share_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 zwolniona po przypisaniu.