Czy są zalety przejścia przez wskaźnik nad przejściem przez referencję w C ++?

Jakie są zalety przejścia przez wskaźnik nad przejściem przez referencję w C ++?

Ostatnio widziałem wiele przykładów, które wybrały przekazywanie argumentów funkcji przez wskaźniki zamiast przekazywania przez odwołanie. Czy są z tego korzyści?

Przykład:

func(SPRITE *x);

z wezwaniem

func(&mySprite);

vs.

func(SPRITE &x);

z wezwaniem

func(mySprite);

Wskaźnik może otrzymać parametr NULL, parametr referencyjny nie. Jeśli kiedykolwiek istnieje szansa, że ​​możesz przekazać „brak obiektu”, użyj wskaźnika zamiast odwołania.

Przekazywanie przez wskaźnik pozwala również wyraźnie zobaczyć w witrynie wywołującej, czy obiekt jest przekazywany przez wartość, czy przez odniesienie:

// Is mySprite passed by value or by reference?  You can't tell 
// without looking at the definition of func()
func(mySprite);

// func2 passes "by pointer" - no need to look up function definition
func2(&mySprite);

Przechodząc obok wskaźnika

• Dzwoniący musi wziąć adres -> nieprzejrzysty
• Podać można wartość 0 nothing. Można to wykorzystać do podania opcjonalnych argumentów.

Przekaż przez odniesienie

• Dzwoniący mija obiekt -> przezroczysty. Musi być użyty do przeciążenia operatora, ponieważ przeciążenie dla typów wskaźników nie jest możliwe (wskaźniki są wbudowanymi typami). Nie możesz więc string s = &str1 + &str2;używać wskaźników.
• Możliwe wartości 0 -> Wywołana funkcja nie musi ich sprawdzać
• Odwołanie do const akceptuje również tymczasowe: void f(const T& t); ... f(T(a, b, c));wskaźniki nie mogą być używane w ten sposób, ponieważ nie można wziąć adresu tymczasowego.
• Last but not least, referencje są łatwiejsze w użyciu -> mniejsza szansa na błędy.

Podoba mi się rozumowanie w artykule z „cplusplus.com:”

1. Przekaż wartość, gdy funkcja nie chce modyfikować parametru, a wartość można łatwo skopiować (ints, double, char, bool itp.) Typy proste. Std :: string, std :: vector i wszystkie inne STL pojemniki NIE są typami prostymi.)

2. Przekaż wskaźnik const, gdy kopiowanie wartości jest drogie ORAZ funkcja nie chce modyfikować wartości wskazywanej na ORAZ NULL jest prawidłową, oczekiwaną wartością obsługiwaną przez funkcję.

3. Przekazywanie wskaźnika non-const, gdy kopiowanie wartości jest drogie ORAZ funkcja chce zmodyfikować wartość wskazywaną na ORAZ NULL jest prawidłową, oczekiwaną wartością obsługiwaną przez funkcję.

4. Przekaż referencję const, gdy kopiowanie wartości jest drogie ORAZ funkcja nie chce modyfikować wartości, do której odwołuje się AND NULL nie byłby prawidłową wartością, gdyby zamiast niej użyto wskaźnika.

5. Przekazywanie przez odniesienie bez kontekstu, gdy kopiowanie wartości jest drogie ORAZ funkcja chce zmodyfikować wartość, do której odwołuje się ORAZ NULL nie byłaby prawidłową wartością, gdyby zamiast niej użyto wskaźnika.

6. Pisząc funkcje szablonów, nie ma jednoznacznej odpowiedzi, ponieważ istnieje kilka kompromisów, które należy wziąć pod uwagę, które są poza zakresem tej dyskusji, ale wystarczy powiedzieć, że większość funkcji szablonów przyjmuje swoje parametry według wartości lub (stałej) referencji , jednak ponieważ składnia iteratora jest podobna do składni wskaźników (gwiazdka do „dereferencji”), każda funkcja szablonu, która oczekuje iteratorów jako argumentów, również domyślnie akceptuje wskaźniki (i nie sprawdza NULL, ponieważ koncepcja iteratora NULL ma inną składnię ).

http://www.cplusplus.com/articles/z6vU7k9E/

Biorę z tego, że główna różnica między wyborem wskaźnika lub parametru referencyjnego polega na tym, czy NULL jest dopuszczalną wartością. Otóż ​​to.

To, czy wartość jest wejściowa, wyjściowa, modyfikowalna itp., Powinno jednak znajdować się w dokumentacji / komentarzach dotyczących funkcji.

Allen Holub w „Wystarczającej ilości liny, by strzelić sobie w stopę” wymienia następujące 2 zasady:

120. Reference arguments should always be `const`
121. Never use references as outputs, use pointers

Wymienia kilka powodów, dla których dodano odniesienia do C ++:

• są one niezbędne do zdefiniowania konstruktorów kopii
• są niezbędne w przypadku przeciążeń operatora
• const referencje pozwalają na semantykę przekazywania wartości przy jednoczesnym unikaniu kopiowania

Jego głównym punktem jest to, że odniesienia nie powinny być używane jako parametry „wyjściowe”, ponieważ w witrynie wywoławczej nie ma wskazania, czy parametr jest parametrem odniesienia, czy wartością. Zatem jego regułą jest używanie constreferencji wyłącznie jako argumentów.

Osobiście uważam, że jest to dobra zasada, ponieważ wyjaśnia, kiedy parametr jest parametrem wyjściowym, czy nie. Jednakże, chociaż osobiście się z tym ogólnie zgadzam, pozwalam się zachwiać opiniami innych członków mojego zespołu, jeśli argumentują za parametrami wyjściowymi jako odniesieniami (niektórzy programiści bardzo je lubią).

Wyjaśnienia do poprzednich postów:

Referencje NIE są gwarancją otrzymania wskaźnika o wartości innej niż zero. (Chociaż często traktujemy je jako takie.)

Chociaż jest to przerażająco zły kod, ponieważ zabiera cię za zaszyfrowany zły kod, następujące kompilują się i uruchamiają: (Przynajmniej pod moim kompilatorem).

bool test( int & a)
{
  return (&a) == (int *) NULL;
}

int
main()
{
  int * i = (int *)NULL;
  cout << ( test(*i) ) << endl;
};

Prawdziwy problem, jaki mam z referencjami, dotyczy innych programistów, odtąd określanych jako IDIOTS , którzy przydzielają w konstruktorze, zwalniają w destruktorze i nie dostarczają konstruktora kopii lub operatora = ().

Nagle istnieje różnica między foo (BAR BAR) a foo (BAR & bar) . (Automatyczna bitowa operacja kopiowania zostaje wywołana. Dezalokacja w destruktorze zostaje wywołana dwukrotnie.)

Na szczęście nowoczesne kompilatory wykryją podwójną dezalokację tego samego wskaźnika. 15 lat temu tego nie zrobili. (Pod gcc / g ++, użyj setenv MALLOC_CHECK_ 0, aby wrócić do starych sposobów.) W rezultacie , w systemie DEC UNIX, ta sama pamięć jest przydzielana do dwóch różnych obiektów. Dużo zabawy przy debugowaniu ...

Bardziej praktycznie:

• Referencje ukrywają, że zmieniasz dane przechowywane gdzie indziej.
• Łatwo pomylić odniesienie z skopiowanym obiektem.
• Wskaźniki to oczywiste!

Większość odpowiedzi tutaj nie rozwiązuje wewnętrznej dwuznaczności posiadania surowego wskaźnika w sygnaturze funkcji, jeśli chodzi o wyrażanie zamiaru. Problemy są następujące:

• Program wywołujący nie wie, czy wskaźnik wskazuje pojedynczy obiekt, czy początek „tablicy” obiektów.

• Dzwoniący nie wie, czy wskaźnik „posiada” pamięć, na którą wskazuje. IE, czy funkcja powinna zwolnić pamięć. ( foo(new int)- Czy to wyciek pamięci?).

• Dzwoniący nie wie, czy nullptrmożna bezpiecznie przejść do funkcji.

Wszystkie te problemy są rozwiązywane przez referencje:

• Odnośniki zawsze odnoszą się do jednego obiektu.

• Referencje nigdy nie posiadają pamięci, do której się odnoszą, są jedynie widokiem na pamięć.

• Referencje nie mogą mieć wartości zerowej.

To sprawia, że ​​referencje są znacznie lepszym kandydatem do ogólnego użytku. Jednak referencje nie są idealne - należy rozważyć kilka głównych problemów.

• Brak wyraźnej pośrednictwa. Nie jest to problem z surowym wskaźnikiem, ponieważ musimy użyć &operatora, aby pokazać, że rzeczywiście mijamy wskaźnik. Na przykład int a = 5; foo(a);tutaj wcale nie jest jasne, że a jest przekazywane przez odniesienie i może zostać zmodyfikowane.
• Nullability. Ta słabość wskaźników może być również siłą, gdy faktycznie chcemy, aby nasze referencje były zerowalne. Uznanie za std::optional<T&>nieważne (z dobrych powodów), wskaźniki dają nam taką pożądalność.

Wydaje się więc, że kiedy chcemy nullownego odniesienia z wyraźną pośrednią interwencją, powinniśmy sięgnąć po T*prawo? Źle!

Abstrakcje

W naszej desperacji na punkcie zerowania możemy sięgnąć T*i po prostu zignorować wszystkie niedociągnięcia i semantyczne dwuznaczności wymienione wcześniej. Zamiast tego powinniśmy sięgnąć po to, co C ++ robi najlepiej: abstrakcję. Jeśli po prostu napiszemy klasę, która owija się wokół wskaźnika, zyskujemy wyrazistość, a także nullability i wyraźną pośredniość.

template <typename T>
struct optional_ref {
  optional_ref() : ptr(nullptr) {}
  optional_ref(T* t) : ptr(t) {}
  optional_ref(std::nullptr_t) : ptr(nullptr) {}

  T& get() const {
    return *ptr;
  }

  explicit operator bool() const {
    return bool(ptr);
  }

private:
  T* ptr;
};

Jest to najprostszy interfejs, jaki mogłem wymyślić, ale działa on skutecznie. Pozwala na zainicjowanie odwołania, sprawdzenie, czy wartość istnieje i dostęp do wartości. Możemy go używać w następujący sposób:

void foo(optional_ref<int> x) {
  if (x) {
    auto y = x.get();
    // use y here
  }
}

int x = 5;
foo(&x); // explicit indirection here
foo(nullptr); // nullability

Osiągnęliśmy nasze cele! Zobaczmy teraz zalety w porównaniu do surowego wskaźnika.

• Interfejs pokazuje wyraźnie, że odwołanie powinno odnosić się tylko do jednego obiektu.
• Najwyraźniej nie jest właścicielem pamięci, do której się odnosi, ponieważ nie ma niszczyciela zdefiniowanego przez użytkownika ani metody usuwania pamięci.
• Program wywołujący wie, że nullptrmożna go przekazać, ponieważ autor funkcji wyraźnie prosi o polecenieoptional_ref

Możemy sprawić, że interfejs stanie się bardziej złożony, na przykład dodając operatory równości, interfejs monadyczny get_ori mapinterfejs, metodę, która pobiera wartość lub zgłasza wyjątek, constexprobsługę. Możesz to zrobić przez ciebie.

Podsumowując, zamiast używać surowych wskaźników, uzasadnij, co te wskaźniki faktycznie oznaczają w kodzie, albo wykorzystaj standardową abstrakcję biblioteki lub napisz własną. Znacząco poprawi to Twój kod.

Nie całkiem. Wewnętrznie przekazywanie przez odniesienie odbywa się poprzez zasadniczo przekazanie adresu odnośnego obiektu. Tak więc, naprawdę nie ma żadnego przyrostu wydajności po przejściu wskaźnika.

Przekazywanie przez odniesienie ma jednak jedną zaletę. Na pewno masz instancję dowolnego obiektu / typu, który jest przekazywany. Jeśli podasz wskaźnik, ryzykujesz otrzymaniem wskaźnika NULL. Korzystając z funkcji przekazywania według referencji, wypychasz niejawne sprawdzenie NULL o jeden poziom w górę do programu wywołującego twoją funkcję.