Kiedy nowe projekty C powinny być ukierunkowane na bardzo stare standardy C (> 20 lat, tj. C89)?

Czasami widzę duże, stosunkowo nowe projekty C typu open source ukierunkowane na bardzo stare standardy C, zazwyczaj C89. Przykładem jest systemd. W tych projektach stoją inteligentni ludzie, więc prawdopodobnie mają oni uzasadnienie tej decyzji, o której nie wiem. Pomijając tę ​​wątpliwość, prawie wydaje się, że uzasadnienie jest takie, że „starszy i znormalizowany jest zawsze bardziej przenośny i lepszy”, co jest śmieszne, ponieważ logiczny wniosek byłby taki, że FORTRAN jest lepszy niż C, a COBOL jest nawet lepszy niż FORTRAN.

Kiedy i dlaczego uzasadnione jest, aby nowe projekty C były ukierunkowane na bardzo stare standardy C?

Nie wyobrażam sobie scenariusza, w którym system użytkownika absolutnie nie może aktualizować swojego kompilatora C, ale poza tym może instalować nowe oprogramowanie. Na przykład wersja LTS Debiana ma pakiet gcc 4.6, który obsługuje C99 i niektóre C11. Wydaje mi się, że ten dziwny scenariusz musi istnieć, a programy takie jak systemd atakują tych użytkowników.

Najbardziej rozsądnym przykładem użycia, jaki mogę sobie wyobrazić, jest to, że użytkownicy oczekują egzotycznych architektur, na których dostępny jest tylko kompilator C89, ale są oni w pełni gotowi zainstalować nowe oprogramowanie. Biorąc pod uwagę spadek różnorodności architektur zestawu instrukcji, wydaje się to zbyt hipotetycznym scenariuszem, ale nie jestem pewien.

... „starszy i znormalizowany jest zawsze bardziej przenośny i lepszy”, co jest śmieszne ...

To oświadczenie osiągnęło absurdalność, gdy stało się lepsze , co jest całkowicie subiektywne. Nie wybierasz języka i standardu dla projektu, ponieważ używała go połowa osób na ostatnim spotkaniu, na które byłeś; wybrałeś go, ponieważ przestudiowałeś i zrozumiałeś rozwiązywany problem i ustaliłeś, że jest to odpowiednie narzędzie do pracy.

Jeśli chodzi o standardy, w niektórych projektach można poruszyć kwestię przenośności, i to właśnie tam wybór starszego ma pewne zalety. Jest to szczególnie ważne, gdy tworzysz biblioteki jako produkty, które są środkiem do osiągnięcia celu kogoś innego. Ostatnią rzeczą, którą chcesz zrobić, to napisać coś, czego nie możesz sprzedać, ponieważ wymaga kompilatora, którego klienci, których jeszcze nie spotkałeś, mogą nie mieć. Komentarz Philipa Kendalla na temat osadzonego świata jest natychmiastowy; wiele się dzieje, ponieważ ludzie nadal muszą pisać nowy kod dla starych, stabilnych platform lub tych, którzy nie korzystają z dodatkowych funkcji i nie mają aktualnego kompilatora. Gdy masz pełną kontrolę nad każdym aspektem swojego projektu, możesz „

W przypadku C pojawia się pytanie, co otrzymujesz w zamian za przestrzeganie najnowszego standardu. Przejście z K & R na C89 było dużą zmianą, która wymagała dużego wysiłku, aby oczyścić stary kod, ale ostatecznie zrobiła wiele dobrego. Te zmiany w C99 i C11są niewielkie w porównaniu, a większość ostatnio opracowanego spotkania CI nadal przejdzie C89, ponieważ nie korzysta z nowych funkcji. Trudno argumentować, że nałożenie C99 na C89 byłoby właściwe, ponieważ obsługuje komentarze jednowierszowe, ma rodzimy logiczny typ danych i może wykonywać tablice o zmiennej długości. Komentarze i booleany mają nieprzyjemne obejścia, a VLA mogą być obsługiwane w inny, nieco mniej wydajny sposób. C11 zdegradował VLA do opcjonalnych, i może to być uzasadnienie wyboru starszego C99, jeśli mają one znaczącą rolę w twojej implementacji.

Gdy ważna jest przenośność na wielu platformach. Może to obejmować przestarzałe platformy i wiele wbudowanych procesorów, dla których dostępny jest tylko minimalistyczny kompilator.

Istnieje również poczucie, że C89 jest „najniższym wspólnym mianownikiem”. Była to pierwsza odpowiednio ustandaryzowana wersja i można założyć, że prawie każdy kompilator w użyciu implementuje jakiś nadzbiór C89.

Istnieje również problem polegający na tym, że Microsoft Visual C ++, chociaż był stosunkowo dobry w utrzymywaniu standardów C ++, utknął na C89 przez długi czas w trybie C. Tak więc każdy, kto nie korzysta z najnowszego programu Visual Studio, może być ograniczony do wersji C89.

Muszę przyznać, że nadal piszę kod pseudo-C89 (nie w pełni zgodny z C99) głównie z powodu Microsoftu. Opieram się mocno na MSVC po stronie Windows i nadal nie są one w pełni zgodne z C99, zamiast tego skupiają się głównie na C ++ 17 i nowszych.

Ponadto pracuję nad pakietami SDK języka C, w stosunku do których wielu programistów wtyczek używa MSVC do opracowywania wtyczek, a niektórzy wciąż używają MSVC 2010. Tak więc nadal istnieją popularne kompilatory szeroko stosowane na platformach, które nie są tak egzotyczne (chyba że uważasz, że Windows egzotyczne), które nawet nie w pełni implementują C99. Gdy dążysz do zapewnienia szerokiej kompatybilności z największą gamą kompilatorów (co jest jednym z głównych powodów, dla których SDK jest napisany w C, a nie w C ++), nadal wiele z nich jest powszechnie używanych (przynajmniej MSVC), które są opóźnione jeśli chodzi o wsparcie C. Minęło już prawie kilkadziesiąt lat od C99 i nadal nie mamy VLA, np. W MSVC AFAIK (jeszcze nie sprawdziłem MSVC 2017, ale biorąc pod uwagę stanowisko Microsoftu w C, wątpię, że jest znacznie bardziej zgodny z C99) .

Tak więc wciąż istnieją niestety nowe kompilatory, które są całkiem dobre z dobrymi optymalizatorami i debuggerami, które wciąż nie są w pełni zgodne z C99. Oczywiście, gdyby nie to, skakałbym po całym C11.

Oprócz kompatybilności źródła z wtyczkami i MSVC, istnieje również interakcja z innymi językami. Niektóre inne języki używają zestawu SDK za pośrednictwem interfejsu FFI, a niektóre z tych interfejsów obsługują tylko C89. Nie może zrozumieć, boollub _Booljako prosty przykład podczas importowania funkcji z dylib i tylko zrozumieć, powiedzmy int.

Tak, argumentem przemawiającym na korzyść jest przenośność, ale pytanie brzmi, czy faktycznie istnieją nie hipotetyczne systemy, które mogą korzystać tylko z kompilatora C89, ale kompilują nowe dystrybucje oprogramowania. tzn. gdybym rozpoczynał nowy projekt C, jak zdecydowałbym, czy przestrzeganie C89 mogłoby zwiększyć liczbę potencjalnych użytkowników?

Właśnie zauważyłem ten jeden, ale jakby echo Blrfl, wzrost wydajności przy użyciu C99 i C11 nie jest tak ogromny w moim przypadku, a utrata możliwości pozwalania ludziom na pisanie wtyczek w MSVC może być ogromnym kosztem (szczególnie, ponieważ produkt, w którym pracuję Zdecydowanie największy udział w rynku ma strona systemu Windows, a przeciętny użytkownik często kupuje i pobiera wiele wtyczek stron trzecich). Rodzaj produktu, nad którym pracuję, znajduje się prawie w połowie drogi między środowiskiem programistycznym / programistycznym a produktem końcowym dla artystów, ponieważ tak wielu ludzi chce nad nim opracowywać nowe funkcje, aby umożliwić nowe możliwości i osiągnąć specjalne efekty mili ludzie jeszcze nie widzieli. Tak więc w moim przypadku była to dość prosta decyzja, aby faworyzować C89 przynajmniej dla SDK.

Podejrzewam, że musisz spojrzeć na kompilatory wokół ciebie i spróbować ustalić docelową sytuację demograficzną. Jeśli nie tworzysz architektury wtyczek dla systemu Windows, nie tworzysz żadnego oprogramowania wbudowanego ani nie próbujesz zbudować zestawu programistycznego, który może być używany przez najszerszą gamę dostępnych kompilatorów i języków, z pewnością łatwiej jest sięgnąć po C99 +, prawda z dala. Zastanów się też, ile możesz zwiększyć produktywności od C99 wzwyż. Nie czerpię zbyt wiele korzyści z takich rzeczy jak VLA, ponieważ polegam na wystarczająco prostych sposobach użycia stosu, gdy dane pasują i stertują się inaczej.

Ale istnieje wiele rzeczy opóźnionych od popularnych kompilatorów, takich jak MSVC, do FFI w innych językach, które są fajne w tym sensie, że mogą importować i wywoływać funkcje C bezpośrednio z dylib, ale mogą być również nieco opóźnione czasy. Dlatego w zależności od domeny należy rozważyć o wiele więcej praktycznych rzeczy biznesowych niż po prostu faworyzowanie starszych i ustandaryzowanych pod kątem estetyki.