Utrata wartości uważana za szkodliwą? [Zamknięte]

Właśnie kompilowałem swój własny kod z -std=c++0xflagą w GCC, ponieważ chcę niejasno nadążać za tym, co robią wszyscy młodzi ludzie (pod warunkiem, że pozostaną na moim trawniku), i skończyło się z mnóstwem ostrzeżeń o auto_ptrbyciu przestarzałym. Oczywiście wiedziałem, że auto_ptrto jest przestarzałe w C ++ 0x, ale ...

Czy amortyzacja nie jest stratą czasu i wysiłku? Powody, dla których nie jest to przestarzałe (na przykład auto_ptr):

• istnieje ocean kodu, który wciąż wymaga wsparcia, a miliony ostrzeżeń tylko kuszą ludzi do wyłączenia ostrzeżeń.

• auto_ptr jest trochę naff, ale w rzeczywistości robi to, co mówi na puszce.

• jeśli naprawdę chcemy zdezaktualizować rzeczy, nominuję printf(). Ale wyobraźcie sobie pisk, który się wydarzy. auto_ptrnie ma zbyt wielu przyjaciół, ale przynajmniej w moim kodzie C ++ jest używany częściej niż printf, co wcale nie jest używane.

• komitet ma kiepską sytuację, aby to naprawić - przestarzałe statyczne w zakresie przestrzeni nazw, a teraz wydaje się to nieaktualne - nie zdziwiłbym się, gdyby auto_ptrdokonał podobnego powrotu

• wreszcie, cokolwiek powie komitet, implementatorzy kompilatora ignorują je - po prostu nie mogą ryzykować złamania kodu klienta, mogą jedynie wydać irytujące ostrzeżenia.

Więc moje pytanie - czy uważasz zaniechanie (czegokolwiek, nie tylko auto_ptrs, a nie tylko w C ++) dobrym pomysłem, a jeśli tak, to dlaczego?

Powody rezygnacji (ogólnie):

• To wyraźnie wskazuje ludziom, że coś jest złą praktyką (i miejmy nadzieję sugeruje alternatywę).
• Okres amortyzacji daje ludziom szansę na zmianę kodu, zanim kompilator całkowicie go usunie.

Nie zgadzam się również co do ostatniego punktu. Kompilatory nie ignoruj komisję, a oni ostatecznie usunąć rzeczy, które są nieaktualne (np >?=oraz <?=w GCC - były przestarzałe następnie usuwane *).

Myślę, że istotną kwestią jest: niektóre rzeczy powinny zostać usunięte z różnych powodów i myślę, że deprecjacja jest jedynym rozsądnym sposobem, aby to zrobić. W tym konkretnym przypadku auto_ptrnależy go usunąć, ponieważ został zastąpiony przez unique_ptr. Zmiana jest łatwa, a ludzie będą mieli na to dużo czasu.

(*) Tak, wiem, że są rozszerzeniami, a nie standardem, ale chodzi o to, że dostawcy kompilatorów ostatecznie usuwają rzeczy po wprowadzeniu przestarzałości, niezależnie od tego, czy kod nadal na nich polega, czy nie.

Każdy wystarczająco skomplikowany interfejs API prawdopodobnie będzie miał wady, które nie zostaną wykryte, dopóki nie zostaną użyte przez pewien czas. Nasze opcje:

• Pozostaw rzeczy takimi, jakie są. Oznacza to, że interfejs API będzie gromadzić coraz więcej cruft w miarę ewolucji. Nawet jeśli zostaną dodane nowe i ulepszone wersje, stare będą również musiały być utrzymywane.
• Usuń go bez ostrzeżenia. Może to zepsuć dużo kodu.
• Przestarzałe i usuń je w późniejszej wersji. Daje to czas na naprawienie istniejącego kodu, zapewniając jednocześnie, że ilość cruft pozostaje ograniczona.

Odstąpienie jest najmądrzejszą z tych alternatyw.

Nie Odstąpienie może być naprawdę dobrą rzeczą. Zapobiega utknięciu technologii ze starym bezużytecznym bagażem.

Właśnie na arenie C ++ pamiętam „funkcję” Microsoftu polegającą na niepoprawnym wspieraniu deklaracji zmiennych wewnątrz instrukcji for. Trwało to około dekady i wiele z nich stało się nieprzenośnych. To jedna „funkcja”. Cieszę się, że była przestarzała.

Mówiąc bardziej ogólnie, Apple miał nawyk od lat 80. oznaczania niezdarnych starych API jako „przestarzałych” przez 5-7 lat, zanim je wyszarpał. Właśnie rozmawiałem z inżynierem Apple z WWDC o wycofaniu niektórych starożytnych interfejsów API QuickTime C i bardzo się ucieszyłem, że to robią, ponieważ ciągłe wsparcie dla modelu opracowanego około 1990 r. Całkowicie utrudniało to, czego można by się spodziewać zrobić na nowoczesnych 64-bitowych procesorach wielordzeniowych.

W praktyce pisarze kompilatorów zajmą dużo czasu, aby zrzucić auto_ptr, i prawdopodobnie będą obsługiwać tryb zgodności wstecznej przez dekadę lub dwie, ale to dobra rzecz, imo.

jeśli naprawdę chcemy przestać działać, nominuję printf ()

printfjest przydatną funkcją. Pozwala na formatowanie rzeczy krótszych niż iostreams. I to jest funkcja C. Głównym powodem, dla którego C ++ istnieje i jest używany, jest to, że jest kompatybilny z C. Tak więc przestarzałe printfwydaje się mniej przydatne.

Czy ktoś jeszcze jest na krucjacie przeciwko deprecjacji?

Komitet zdaje sobie sprawę z niektórych problemów związanych z obecnym domniemanym znaczeniem amortyzacji. Zobacz znaczenie wycofania .

Języki i interfejsy API muszą iść do przodu. Mimo że w zależności od starej funkcji może być mnóstwo kodu, może istnieć nowy i lepszy sposób na zrobienie czegoś, a koszt obsługi starej funkcji jest po prostu zbyt wysoki.

Wycofanie daje również ostrzeżenie, że w przyszłości funkcja zostanie usunięta. Daje to programistom czas na aktualizację kodu, jeśli nadążają za nowym interfejsem API. Jest to znacznie lepsze niż alternatywa: całkowite usunięcie. Pamiętaj, że amortyzacja jest ostrzeżeniem, a nie błędem.

A jeśli jest to stary program, którego nie chcesz aktualizować, nic nie stoi na przeszkodzie, abyś używał starego API (lub w tym przypadku kompilatora).

W obecnej formie wycofanie ma co najmniej dwa znaczenia.

• Zostanie on usunięty w przyszłej wersji
• Stworzyliśmy lepsze alternatywy, a teraz funkcja jest zbędna (ale nie całkowicie bezużyteczna). Nowi gracze lepiej by to pominęli podczas nauki języka; nie zostanie on jednak wkrótce usunięty.

Myślę, że statyczny należy do tej drugiej kategorii, ale tylko czas pokaże, czy auto_ptr naprawdę zasługuje na usunięcie, czy też lepiej jest zachować go w języku.

Wycofanie nie jest szkodliwe, jeśli przejście na alternatywę można wykonać w ciągu 1 dnia roboczego: np. proste wyszukiwanie / zamiana starej funkcji na nową lub warstwa zgodności jest łatwa do skonfigurowania.

Jeśli musisz przepisać duże części oprogramowania z powodu wycofania, jest to szkodliwe.

Dobrym przykładem może być prawdopodobnie PHP mysql API, w zasadzie wystarczy po prostu wymienić wszystkie mysql_ * na mysqli_ * i podać identyfikator linku do nich i gotowe.

Jednym złym przykładem jest wycofywanie i usuwanie glBegin, glEnd i wszystkie inne elementy obliczeń macierzowych z OpenGL, jeśli chcesz, aby Twój kod działał na OpenGL3 lub nowszym, musisz przepisać cały kod renderujący, aby użyć buforów wierzchołków.

Myślę, że to dobry sposób, aby poinformować ludzi, że istnieje lepszy sposób. Wolę raczej miłe wycofanie niż funkcję, która po prostu znika.