Funkcja typu powrotu stylu

Question

Uczę się c++0x, przynajmniej części obsługiwane przez Visual C++ Express 2010 Beta. To jest pytanie o styl, a nie jak to działa. Być może jest jeszcze za wcześnie, aby styl i dobre praktyki ewoluowały jeszcze w przypadku standardu, który jeszcze nie został jeszcze wydany ...

W c++0x można zdefiniować typ zwracanej metody za pomocą -> type na końcu funkcja zamiast umieszczania typu na początku. Wierzę, że ta zmiana w składni jest wymagana ze względu na lambdy i niektóre przypadki użycia nowego słowa kluczowego decltype, ale możesz go używać w dowolnym miejscu, o ile wiem.

// Old style 
int add1(int a, int b) 
{ 
return a + b; 
} 

// New style return type 
auto add2(int a, int b) -> int 
{ 
return a + b; 
} 

Moje pytanie naprawdę wtedy, podano, że niektóre funkcje będą musiały zostać zdefiniowane w nowy sposób jest ono uważane za dobry styl zdefiniowanie wszystkich funkcji w ten sposób do spójności? Czy powinienem trzymać się go tylko wtedy, gdy jest to konieczne?

Answer 1

Nie zachowuj spójności stylu, tylko dlatego, że są spójne. Kod powinien być czytelny, tzn. Zrozumiały, to jedyny rzeczywisty środek. Dodawanie bałaganu do 95% metod jest spójne z pozostałymi 5%, cóż, to po prostu nie brzmi dobrze dla mnie.

Answer 2

Wydaje mi się, że to by zmieniało nawyk życia dla wielu programistów w C++ (i innych C podobnych).

Jeśli użyto tego stylu dla każdej pojedynczej funkcji to może być tylko jeden robi :-)

Answer 3

Istnieje ogromne codebase, który używa/Obecne zasady „stare”. Założę się, że tak będzie przez długi czas. Problem spójności jest dwojaki: z kim będziesz konsekwentny, kilka kodów, które będą wymagały nowej składni lub całego istniejącego kodu?

Będę trzymał się starej składni, gdy nowa nie jest wymagana przez chwilę, ale potem znowu, tylko czas pokaże, co staje się powszechnym użyciem.

Należy również pamiętać, że nowa składnia jest jeszcze trochę dziwne: zadeklarować typ zwracany jako auto a następnie określić, co oznacza auto na końcu deklaracji podpisem ... To nie czuje naturalny (nawet jeśli nie porównaj to z twoimi własnymi doświadczeniami)

Answer 4

Zgaduję, że obecny standard wygra, tak jak dotychczas z każdą inną proponowaną zmianą w definicji. Został on na pewno rozszerzony, ale zasadnicza semantyka C++ jest tak rozbudowana, że ​​nie wydaje mi się, że warto ją zmienić. Mają wpływ na tak wiele języków i stylów prowadzi do absurdu.

Jeśli chodzi o twoje pytanie, chciałbym spróbować oddzielić kod na moduły, aby było jasne, gdzie używasz starego stylu i nowego stylu. Tam, gdzie dwie mieszanki, upewnię się i wytyczę je w jak największym stopniu. Pogrupuj je razem, itp.

[osobista opinia] Uważam, że to naprawdę wstrząśnięte przeglądanie plików i obserwowanie zmiany stylu w tę iz powrotem, lub radykalnie się zmieniać. Po prostu zastanawiam się, co jeszcze tu czai się [/ osobistą opinię]

Answer 5

Osobiście użyłbym go, gdy jest to konieczne. Podobnie jak this-> jest wymagany tylko podczas uzyskiwania dostępu do elementów szablonu bazowej klasy (lub gdy są one w inny sposób ukryte), więc auto fn() -> type jest konieczne tylko wtedy, gdy typ powrotu nie może zostać określony przed widocznością reszty sygnatury funkcji.

Stosowanie tej reguły prawdopodobnie pomoże większości czytelników kodu, którzy mogą pomyśleć "dlaczego autor uważał, że musimy napisać oświadczenie w ten sposób?" Inaczej.

Answer 6

Dobre zmiany w stylu - jeśli mi nie wierzysz, spójrz na dobry styl w 98 i co jest teraz - i trudno jest wiedzieć, co będzie uważać za dobry styl i dlaczego. IMHO, obecnie wszystko, co dotyczy C++ 0X, jest eksperymentalne, a dobry lub zły styl kwalifikacji po prostu nie ma zastosowania.

Answer 7

Nie uważam, że należy go używać do regularnych funkcji. Ma specjalne zastosowania, dzięki czemu łatwo możesz zrobić to, co wcześniej było dość niewygodne. Na przykład:

template <class Container, class T> 
auto find(Container& c, const T& t) -> decltype(c.begin()); 

Tu nie wiem, czy Pojemnik jest const, czy nie, a więc czy typ zwracany byłby Container::iterator lub Container::const_iterator (można wyznaczyć z co begin() wróci).