Czy to prawda, że ​​duże firmy wbudowane są "zmuszone" do używania starych standardów/kompilatorów?

Question

Nasz wykładowca powiedział nam, że przy wypełnianiu naszych zadań możemy używać tylko standardów C++ 98/C99, podając poprawne flagi do kompilatora, możemy zapewnić, że nie łamiemy tej reguły.

Rozumiem, że tak jest, więc ludzie mogą uczyć się "prawdziwego" C lub C++, w zależności od tego, co wybiorą, i wykonywać tę umiejętność bez jakiejkolwiek pomocy z nowych funkcji językowych (nie zgadzam się, ale kim jestem, aby dyskutować) .

Prosząc mój wykładowca dlaczego ta zasada odpowiedział (po wiedząc, że nie jestem zadowolony z powyższym odpowiedź): „ponieważ duże firmy, takie jak stare ASML, które współpracują z urządzeniami wbudowanymi mają stare codebases że (będzie) może przerwa po przełączeniu na C11/C++ 11).

Prosiłem o konkretny świat/praktyczny przykład kodu, który kompiluje się zarówno w C99/C11 (lub C++ 98/C++ 11) , jest zgodny ze standardem (C99/C++ 98), ale zachowuje się bardzo różnie, gdy jest w formie binarnej - podsumowując pytanie nie zostało odebrane. Jeśli stwierdzenie, że firmy trzymają się starych kompilatorów i standardów jest prawdziwe, może ktoś dostarczy taki kawałek kodu, który chcę zobaczyć sam?

Answer 1

Produkt w dużej firmie nie musi być z jednej bazy kodu. Podstawa kodu może być zależna od wielu innych bibliotek (w tym od trzeciej strony).

Kod produktu nie może być kompilowany przy użyciu najnowszego kompilatora, chyba że wszystkie jego zależności zostaną skompilowane przy użyciu tej wersji kompilatora. (Przynajmniej tak jest w przypadku bibliotek statycznych)

Zasadniczo trudno jest przejść do najnowszej wersji kompilatorów dla dużych produktów o dużych zależnościach. Istnieje również duże obciążenie testowe, które powinno zostać poniesione po przejściu do najnowszego kompilatora.

Kierownictwo zgodziłoby się to zrobić tylko wtedy, gdy zwrot z inwestycji (ROI) jest dobry, co rzadko ma miejsce w przypadku starego kodu.

Answer 2

nie wiem wiele na temat wbudowanego świata, ale trochę inne firmy przy użyciu C++ i mającej starego sprzętu/platformy

---

To naprawdę zależy od firmy i platformy, których używają. Ale przy pewnym wysiłku i otwartym zarządzaniu nie powinno być nic przeciwko posiadaniu nowoczesnego C++ wszędzie (z technicznego punktu widzenia)

W kilku firmach wiem, że programiści zachęcają do przejścia na nowoczesne C++ i poruszają się coraz bardziej.

Czasami trzeba włożyć w to więcej wysiłku niż "tylko" instalowanie nowego kompilatora. Kiedy musisz dostarczyć na starą platformę (np. Debian 6) i nie możesz zmienić systemu operacyjnego, musisz ręcznie skompilować bibliotekę libstdC++ na tej platformie i dostarczyć ją do swojego produktu/zlecić jej użycie konkretnego produktu (jest więcej szczegółów, ale dostajesz punkt).

---

Tak więc, być może są firmy, które trzymają się starego C++ z powodu konserwatywnego zarządzania lub deweloperów nie dbających o nowoczesne C++. Coraz więcej firm aktualizuje się. A uczenie się nowoczesnego C++ jest również niepoprawne , ponieważ "stary" styl zwykle zniechęca się w firmach, które używają nowoczesnego C++.

---

Kod może „break” podczas przełączania ich kompilatory, ale tylko na poziomie kompilacji i dlatego używali niestandardowych cech/składni (co niektóre starsze kompilatory są bardziej tolerancyjne). Ale jeśli chodzi o zachowanie, nie wiem o czymś, co "cicho" się zepsuje (standardowa komisja aktywnie próbuje tego uniknąć przy każdej zmianie), a także dostajesz lepsze i lepsze ostrzeżenia za pomocą lepszych kompilatorów.

Answer 3

To zależy od firmy, linii produktów wbudowanych i ich bazy klientów.

Niektóre firmy mają zakorzenioną kulturę, więc nalegają na używanie starszych technik, nawet w obliczu uzasadnionych technicznych argumentów do aktualizacji. Niektóre firmy są progresywne i wspierają aktualizację do nowszych kompilatorów i standardów, kiedy tylko to ma sens (i, przeciwnie, wsparcie pozostawiające starsze techniki, gdy TO ma sens). Niektóre firmy są tak zdeterminowane, że przyjmują najnowszy trend, że korzystają z niesprawdzonych technologii i naruszają stabilność swoich linii produktowych.

Niektóre produkty wbudowane korzystają z określonych komponentów sprzętowych, które nie są już produkowane i dla których nie ma ekonomicznej alternatywy dostępnej dzięki połączeniu nowszego sprzętu lub oprogramowania. Na przykład w przypadku trudnych systemów czasu rzeczywistego może istnieć stary sprzęt spełniający krytyczne ograniczenia czasowe, ale nowszy sprzęt nie może być łatwo uzyskany, który spełnia pierwotne wymagania.

Niektóre produkty osadzone mają wysoką krytyczność (bezpieczeństwo krytyczne, krytyczne dla misji itp.) W aktywnym organie regulacyjnym, które nalega na dostarczenie solidnych dowodów technicznych przed zatwierdzeniem aktualizacji (i delegatem, który wylogowuje się na taka aktualizacja bez udokumentowanych dowodów będzie prawnie odpowiedzialna, jeśli coś pójdzie nie tak w polu - na przykład system zabije kogoś z powodu błędu synchronizacji). Ta dokumentacja może być bardzo kosztowna w produkcji. Firma z takim produktem może uznać za bardziej opłacalne trzymanie się starszego (akceptowanego przez regulatora) środowiska programistycznego. Konieczność zapłaty kilku milionów dolarów w celu uzasadnienia aktualizacji nowszego kompilatora ma tendencję do ograniczania gotowości firmy do rozwikłania nowych dowodów uzasadniających korzystanie z nowego kompilatora.

Ostatecznie, aby sprzedać produkt, konieczne jest przekonanie płacącego klienta, aby zapłacił za niego. Jeśli duży odsetek klientów starszego systemu nie jest skłonny zapłacić za aktualizację - w końcu istniejący system działa dobrze - nie ma uzasadnienia dla sprzedawcy do aktualizacji - chyba, że ​​mogą uczynić zmianę neutralną kosztowo dla klienta (co jest często trudne do osiągnięcia przy aktualizacji krytycznego systemu wbudowanego, chyba że sprzedawca jest skłonny pochłonąć duże koszty). Podobnie, kluczowy klient mógł faktycznie zapłacić za rozwój, a następnie utrzymanie istniejącego systemu i może uznać, że dalsze płacenie za utrzymanie istniejącego systemu jest lepsze pod względem wartości, niż opłacanie aktualizacji i przechodzenie przez proces dostarczania dowód działa zgodnie z wymaganiami.

Answer 4

Tylko w tym roku użyłem dwóch różnych kompilatorów, które mają więcej niż 20 lat. Nie było to jednak w przypadku nowych projektów. Miało to na celu utrzymanie produktów, które mają również około 20 lat. Produkty wbudowane mogą być obsługiwane przez dziesięciolecia. W jednym z moich przypadków element sprzętowy stał się przestarzały, co wymagało niewielkiego przeprojektowania, które wymagało aktualizacji oprogramowania. W drugim przypadku projekt sprzętu musiał zostać zaktualizowany pod kątem zgodności z RoHS, a wynikowy projekt wymagał aktualizacji oprogramowania. W obu przypadkach uważam, że byłoby więcej pracy i większe ryzyko korzystania z nowoczesnego kompilatora. Ten stary kod i plik binarny został sprawdzony dzięki 20-letniemu doświadczeniu w pracy.

W trzecim przypadku mikrokontroler stał się przestarzały i przeprojektowaliśmy go z układem FPGA z miękkim procesorem. W tym przypadku wymagane było pewne portowanie i użyłem innego, bardziej nowoczesnego kompilatora. Ale wciąż byłem dość ostrożny, jak bardzo zmieniłem oryginalny kod źródłowy.

Nie powiedziałbym, że jestem "zmuszony" przez politykę do używania tych starych kompilatorów i unikania nowych funkcji kompilatora. Kiedy zachowujesz stare projekty, może to być kwestia praktyczności. Lub może być wybór dokonania mniej zmian, aby uniknąć przypadkowego zerwania czegoś, co zostało udowodnione, że działa.

W przypadku nowych wzorów używamy nowoczesnych kompilatorów. I nigdy nie musiałem ograniczać się do starszego C standardu.

PS: Dla jeszcze trudniejszego doświadczenia można ograniczyć się do kompilatorów, które działają tylko w systemie Windows XP i debugger, który wymaga portu równoległego na komputerze.