Czy deklarowanie zmiennych za pomocą auto w C ++ ma jakąś wadę?

Wygląda na to, że autobyła to dość istotna funkcja do dodania w C ++ 11, która wydaje się być zgodna z wieloma nowszymi językami. Podobnie jak w przypadku języka takiego jak Python, nie widziałem żadnej jawnej deklaracji zmiennej (nie jestem pewien, czy jest to możliwe przy użyciu standardów Pythona).

Czy istnieje wada używania autodo deklarowania zmiennych zamiast ich jawnego deklarowania?

Pytałeś tylko o wady, więc podkreślam niektóre z nich. Dobrze stosowany automa również kilka zalet. Wady wynikają z łatwości nadużyć i zwiększonego potencjału kodu do zachowywania się w niezamierzony sposób.

Główną wadą jest to, że używając auto, niekoniecznie znasz typ tworzonego obiektu. Istnieją również sytuacje, w których programista może oczekiwać, że kompilator wydedukuje jeden typ, ale kompilator stanowczo wywnioskuje inny.

Biorąc pod uwagę deklarację typu

auto result = CallSomeFunction(x,y,z);

niekoniecznie masz wiedzę o tym, jaki resultto jest typ . Może to być plik int. To może być wskaźnik. To może być coś innego. Wszystkie obsługują różne operacje. Możesz także radykalnie zmienić kod poprzez niewielką zmianę, taką jak

auto result = CallSomeFunction(a,y,z);

ponieważ w zależności od tego, jakie przeciążenia istnieją, dla CallSomeFunction()typu wynik może być zupełnie inny - a kolejny kod może zatem zachowywać się zupełnie inaczej niż zamierzano. Możesz nagle wywołać komunikaty o błędach w późniejszym kodzie (np. Później próba wyłuskiwania int, próba zmiany czegoś, co jest teraz const). Bardziej złowrogą zmianą jest to, że Twoja zmiana przepływa obok kompilatora, ale późniejszy kod zachowuje się w inny i nieznany - prawdopodobnie błędny - sposób.

Brak wyraźnej wiedzy o typie niektórych zmiennych utrudnia zatem rygorystyczne uzasadnienie twierdzenia, że ​​kod działa zgodnie z przeznaczeniem. Oznacza to więcej wysiłku, aby uzasadnić twierdzenia o „przydatności do celu” w dziedzinach o wysokim stopniu krytyczności (np. Krytycznych dla bezpieczeństwa lub krytycznych dla misji).

Inną, bardziej powszechną wadą, jest pokusa dla programisty, aby użyć go autojako tępego narzędzia do wymuszenia kompilacji kodu, zamiast myśleć o tym, co robi kod i pracować nad tym, aby to dobrze.

W zasadzie nie jest to wada auto, ale w praktyce wydaje się to być problemem dla niektórych. Zasadniczo niektórzy ludzie albo: a) traktują autojako zbawiciela dla typów i wyłączają mózg, gdy go używają, lub b) zapominają, że autozawsze dedukuje do typów wartości. To powoduje, że ludzie robią takie rzeczy:

auto x = my_obj.method_that_returns_reference();

Ups, właśnie głęboko skopiowaliśmy jakiś obiekt. Często jest to błąd lub awaria wydajności. Następnie możesz też wychylić się w drugą stronę:

const auto& stuff = *func_that_returns_unique_ptr();

Teraz masz wiszące odniesienie. Te problemy wcale nie są powodowane przez auto, więc nie uważam ich za uzasadnione argumenty przeciwko temu. Ale wydaje się, że autosprawia, że ​​ten problem jest bardziej powszechny (z mojego osobistego doświadczenia), z powodów, które wymieniłem na początku.

Myślę, że w miarę upływu czasu ludzie dostosują się i zrozumieją podział pracy: autowyprowadza podstawowy typ, ale nadal chcesz pomyśleć o referencji i stałości. Ale to zajmuje trochę czasu.

Inne odpowiedzi wspominają o wadach, takich jak „tak naprawdę nie wiesz, jaki jest typ zmiennej”. Powiedziałbym, że jest to w dużej mierze związane z niechlujną konwencją nazewnictwa w kodzie. Jeśli twoje interfejsy są wyraźnie nazwane, nie powinieneś przejmować się dokładnym typem. Jasne, auto result = callSomeFunction(a, b);niewiele ci mówi. Ale auto valid = isValid(xmlFile, schema);mówi wystarczająco dużo, aby użyć validbez martwienia się, jaki jest jego dokładny typ. W końcu przy zwykłym if (callSomeFunction(a, b))też nie znałbyś tego typu. To samo z innymi obiektami tymczasowymi podwyrażeń. Więc nie uważam tego za prawdziwą wadę auto.

Powiedziałbym, że jego główną wadą jest to, że czasami dokładny typ zwrotu nie jest tym, z czym chcesz pracować. W efekcie czasami rzeczywisty typ zwracany różni się od „logicznego” typu zwracanego ze względu na szczegóły dotyczące implementacji / optymalizacji. Najlepszym przykładem są szablony wyrażeń. Powiedzmy, że mamy to:

SomeType operator* (const Matrix &lhs, const Vector &rhs);

Logicznie rzecz biorąc, spodziewalibyśmy SomeTypesię , że tak będzie Vectori zdecydowanie chcemy traktować to jako takie w naszym kodzie. Jednak możliwe jest, że dla celów optymalizacji biblioteka algebry, której używamy, implementuje szablony wyrażeń, a rzeczywisty typ zwracania jest następujący:

MultExpression<Matrix, Vector> operator* (const Matrix &lhs, const Vector &rhs);

Otóż, problem polega na tym MultExpression<Matrix, Vector>, że najprawdopodobniej będzie przechowywać a const Matrix&i const Vector&wewnętrznie; oczekuje, że przekształci się w a Vectorprzed końcem pełnego wyrażenia. Jeśli mamy ten kod, wszystko jest w porządku:

extern Matrix a, b, c;
extern Vector v;

void compute()
{
  Vector res = a * (b * (c * v));
  // do something with res
}

Gdybyśmy jednak autotutaj skorzystali , moglibyśmy mieć kłopoty:

void compute()
{
  auto res = a * (b * (c * v));
  // Oops! Now `res` is referring to temporaries (such as (c * v)) which no longer exist
}

Jedną z wad jest to, że czasami nie można zadeklarować const_iteratorz auto. Otrzymasz zwykły (inny niż stały) iterator w tym przykładzie kodu zaczerpniętego z tego pytania :

map<string,int> usa;
//...init usa
auto city_it = usa.find("New York");

To sprawia, że ​​twój kod jest trochę trudniejszy lub uciążliwy do odczytania. Wyobraź sobie coś takiego:

auto output = doSomethingWithData(variables);

Teraz, aby ustalić typ wyniku, musiałbyś wyśledzić sygnaturę doSomethingWithDatafunkcji.

Podobnie jak ten programista, nienawidzę auto. A raczej nienawidzę tego, jak ludzie nadużywają auto.

Jestem (mocną) opinią, że autopomaga ci pisać ogólny kod, a nie redukuje pisanie .
C ++ to język, którego celem jest umożliwienie pisania niezawodnego kodu, a nie minimalizacja czasu programowania.
Jest to dość oczywiste z wielu funkcji C ++, ale niestety kilka nowszych, takich jak autoten, ogranicza pisanie na klawiaturze, co prowadzi ludzi do myślenia, że ​​powinni zacząć leniwie pisać.

W dawnych autoczasach ludzie używali typedefs, co było świetne, ponieważ typedef pozwalało projektantowi biblioteki pomóc ci ustalić, jaki powinien być typ zwrotu, tak aby ich biblioteka działała zgodnie z oczekiwaniami. Kiedy używasz auto, odbierasz tę kontrolę projektantowi klasy i zamiast tego prosisz kompilator o ustalenie , jaki powinien być typ, co usuwa jedno z najpotężniejszych narzędzi C ++ z zestawu narzędzi i grozi złamaniem ich kodu.

Generalnie, jeśli używasz auto, powinno to być spowodowane tym, że twój kod działa dla każdego rozsądnego typu , a nie dlatego, że jesteś po prostu zbyt leniwy, aby zapisać typ, z którym powinien działać. Jeśli używasz go autojako narzędzia pomagającego lenistwu, to w końcu zaczniesz wprowadzać do programu subtelne błędy , zwykle spowodowane niejawnymi konwersjami, które nie miały miejsca, ponieważ użyłeś auto.

Niestety, te błędy są trudne do zilustrowania w krótkim przykładzie tutaj, ponieważ ich zwięzłość czyni je mniej przekonującymi niż rzeczywiste przykłady, które pojawiają się w projekcie użytkownika - jednak łatwo pojawiają się w kodzie z dużą ilością szablonów, który wymaga pewnych niejawnych konwersji miejsce.

Jeśli chcesz mieć przykład, jest tutaj . Jednak mała uwaga: zanim skusisz się, by skoczyć i skrytykować kod: pamiętaj, że wiele znanych i dojrzałych bibliotek zostało opracowanych wokół takich niejawnych konwersji i są one tam, ponieważ rozwiązują problemy, które mogą być trudne, jeśli nie niemożliwe rozwiązać inaczej. Spróbuj znaleźć lepsze rozwiązanie, zanim je skrytykujesz.

autonie ma wady per se , i opowiadają się (ręcznie wavily) używać go wszędzie w nowym kodem. Pozwala kodowi na konsekwentne sprawdzanie typu i konsekwentne unikanie cichego cięcia. (Jeśli Bpochodzi od, Aa funkcja zwracająca Anagle zwraca B, to autozachowuje się zgodnie z oczekiwaniami, przechowując swoją wartość zwracaną)

Chociaż starszy kod sprzed C ++ 11 może opierać się na niejawnych konwersjach wywołanych użyciem jawnie wpisanych zmiennych. Zmiana jawnie wpisanej zmiennej na automoże zmienić zachowanie kodu , więc lepiej zachowaj ostrożność.

Słowo kluczowe autopo prostu wywnioskuje typ z wartości zwracanej. Dlatego nie jest odpowiednikiem obiektu Pythona, np

# Python
a
a = 10       # OK
a = "10"     # OK
a = ClassA() # OK

// C++
auto a;      // Unable to deduce variable a
auto a = 10; // OK
a = "10";    // Value of const char* can't be assigned to int
a = ClassA{} // Value of ClassA can't be assigned to int
a = 10.0;    // OK, implicit casting warning

Ponieważ autojest wywnioskowany podczas kompilacji, nie będzie miał żadnych wad w czasie wykonywania.

To, o czym nikt tu dotąd nie wspomniał, ale samo w sobie jest warte odpowiedzi, gdybyś mnie zapytał.

Ponieważ (nawet jeśli wszyscy powinni być tego świadomi C != C++) kod napisany w C można łatwo zaprojektować, aby zapewnić podstawę dla kodu C ++, a zatem być zaprojektowany bez zbytniego wysiłku, aby był zgodny z C ++, może to być wymaganie przy projektowaniu.

Wiem o pewnych regułach, w których niektóre dobrze zdefiniowane konstrukcje Csą nieważne C++i odwrotnie. Ale to po prostu spowodowałoby uszkodzenie plików wykonywalnych i zastosowanie ma znana klauzula UB, która w większości przypadków jest zauważana przez dziwne pętle powodujące awarie lub cokolwiek innego (lub nawet może pozostać niewykryte, ale to nie ma znaczenia tutaj).

Ale autopo raz pierwszy ¹ to zmiany!

Wyobraź sobie, że wcześniej użyłeś autojako specyfikatora klasy pamięci i prześlij kod. Nie musiałoby to nawet (w zależności od sposobu użycia) „złamać się”; faktycznie może po cichu zmienić zachowanie programu.

Należy o tym pamiętać.

¹ _{Przynajmniej za pierwszym razem, kiedy jestem tego świadomy.}

Jednym z powodów, które przychodzą mi do głowy, jest to, że tracisz możliwość przymuszenia klasy, która jest zwracana. Jeśli twoja funkcja lub metoda zwróciła długi 64-bitowy, a chciałeś tylko 32 bez znaku int, tracisz możliwość kontrolowania tego.

Jak opisałem w tej odpowiedzi, auto czasami mogą wystąpić dziwne sytuacje, których nie zamierzałeś. Musisz wprost powiedzieć, auto&że masz typ referencyjny, a robiąc to, po prostu automożesz stworzyć typ wskaźnika. Może to spowodować zamieszanie, jeśli pominie się specyfikator razem, co spowoduje kopię odwołania zamiast rzeczywistego odniesienia.

Kolejny irytujący przykład:

for (auto i = 0; i < s.size(); ++i)

generuje ostrzeżenie ( comparison between signed and unsigned integer expressions [-Wsign-compare]), ponieważ ijest podpisaną int. Aby tego uniknąć, musisz napisać np

for (auto i = 0U; i < s.size(); ++i)

a może lepiej:

for (auto i = 0ULL; i < s.size(); ++i)

Myślę, że autojest dobre, gdy jest używane w zlokalizowanym kontekście, w którym czytelnik łatwo i oczywiście może wywnioskować jego typ, lub dobrze udokumentowane komentarzem tego typu lub nazwą, która określa rzeczywisty typ. Ci, którzy nie rozumieją, jak to działa, mogą przyjąć to w niewłaściwy sposób, na przykład używając go zamiast templatelub podobnie. Moim zdaniem, oto kilka dobrych i złych przypadków użycia.

void test (const int & a)
{
    // b is not const
    // b is not a reference

    auto b = a;

    // b type is decided by the compiler based on value of a
    // a is int
}

Dobre zastosowania

Iteratory

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int> v();

..

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int>::iterator it = v.begin();

// VS

auto vi = v.begin();

Wskaźniki funkcji

int test (ClassWithLongName1 a, ClassWithLongName2 b, int c)
{
    ..
}

..

int (*fp)(ClassWithLongName1, ClassWithLongName2, int) = test;

// VS

auto *f = test;

Złe zastosowania

Przepływ danych

auto input = "";

..

auto output = test(input);

Podpis funkcji

auto test (auto a, auto b, auto c)
{
    ..
}

Przypadki trywialne

for(auto i = 0; i < 100; i++)
{
    ..
}

Dziwię się, że nikt o tym nie wspomniał, ale przypuśćmy, że obliczasz silnię czegoś:

#include <iostream>
using namespace std;

int main() {
    auto n = 40;
    auto factorial = 1;

    for(int i = 1; i <=n; ++i)
    {
        factorial *= i;
    }

    cout << "Factorial of " << n << " = " << factorial <<endl;   
    cout << "Size of factorial: " << sizeof(factorial) << endl; 
    return 0;
}

Ten kod wyświetli to:

Factorial of 40 = 0
Size of factorial: 4

To zdecydowanie nie był oczekiwany rezultat. Stało się tak, ponieważ autowydedukowałem typ zmiennej silnia, intponieważ została do niej przypisana 1.