Preferuję pojedyncze wyjście, chyba że naprawdę to komplikuje. Odkryłem, że w niektórych przypadkach wiele istniejących punktów może maskować inne, bardziej znaczące problemy projektowe:
public void DoStuff(Foo foo)
{
if (foo == null) return;
}
Po zobaczeniu tego kodu od razu zapytam:
- Czy „foo” jest kiedykolwiek zerowe?
- Jeśli tak, to ilu klientów „DoStuff” wywołuje tę funkcję z zerowym „foo”?
W zależności od odpowiedzi na te pytania może to być to
- kontrola jest bezcelowa, ponieważ nigdy nie jest prawdziwa (tzn. powinna być stwierdzeniem)
- sprawdzenie jest bardzo rzadko prawdziwe, dlatego może być lepsza zmiana tych konkretnych funkcji dzwoniącego, ponieważ prawdopodobnie i tak powinny podjąć jakieś inne działania.
W obu powyższych przypadkach kod można prawdopodobnie przerobić za pomocą asercji, aby upewnić się, że „foo” nigdy nie ma wartości zerowej, a odpowiednie elementy wywołujące uległy zmianie.
Istnieją dwa inne powody (specyficzne, jak sądzę, kod C ++), w których istnieje wiele, które mogą mieć negatywny wpływ. Są to rozmiar kodu i optymalizacje kompilatora.
Obiekt non-POD C ++ w zasięgu na wyjściu funkcji będzie miał wywołany destruktor. Jeśli istnieje kilka instrukcji return, może się zdarzyć, że w zasięgu znajdują się różne obiekty, więc lista wywoływanych destruktorów będzie inna. Dlatego kompilator musi wygenerować kod dla każdej instrukcji return:
void foo (int i, int j) {
A a;
if (i > 0) {
B b;
return ; // Call dtor for 'b' followed by 'a'
}
if (i == j) {
C c;
B b;
return ; // Call dtor for 'b', 'c' and then 'a'
}
return 'a' // Call dtor for 'a'
}
Jeśli problemem jest rozmiar kodu - warto go unikać.
Drugi problem dotyczy „Nazwanej optymalizacji wartości zwracanej” (inaczej Copy Elision, ISO C ++ '03 12.8 / 15). C ++ pozwala implementacji pominąć wywoływanie konstruktora kopiowania, jeśli może:
A foo () {
A a1;
// do something
return a1;
}
void bar () {
A a2 ( foo() );
}
Przyjmując kod w niezmienionej postaci, obiekt „a1” jest konstruowany w „foo”, a następnie jego konstrukcja kopiująca zostanie wywołana w celu utworzenia „a2”. Jednak eliminacja kopii pozwala kompilatorowi zbudować „a1” w tym samym miejscu na stosie co „a2”. Nie ma zatem potrzeby „kopiowania” obiektu po powrocie funkcji.
Wiele punktów wyjścia komplikuje pracę kompilatora w próbach wykrycia tego, a przynajmniej dla stosunkowo nowej wersji VC ++ optymalizacja nie miała miejsca, gdy ciało funkcji miało wiele zwrotów. Aby uzyskać więcej informacji, zobacz Optymalizacja nazwanych wartości zwrotnych w programie Visual C ++ 2005 .