🚀 go-pugleaf

W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
> Pytanie do osób, które programują zawodowo w C lub C++. Której wersji 
> standardu używacie w projektach w pracy?
> 
> Zastanawiam się, czy to specyfika środowiska embedded, ale u nas nadal 
> obowiązuje C++03. "Się nie da" chociażby w C++11, bo używamy starego 
> kompilatora (bo nowego nie wspiera archaiczne środowisko).
> 
> A jak to jest u was (+ jaka branża, tak z grubsza, jeśli to nie 
> tajemnica)?

W branży embedded, jeśli się da (czyli np. na ARMy albo na jakieś linuksy) to korzystam z GCC i wówczas używam rozszerzeń GNU99 (-std=gnu99).

Flagi warningów mam
-Wall -Wconversion -Wno-float-conversion -Wno-sign-conversion -Werror=uninitialized -Werror=implicit-int -Werror=return-type -Werror=conversion

To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:

uint32_t f() {
  return JAKAŚ_DUŻA_WARTOŚĆ;
}

uint16_t x = f();

(co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)

Jak się nie da, to wtedy zależy co mi obsługuje kompilator (np. kompilator Cosmic dla STM8 ma jakieś tam swoje ograniczenia co do wersji języka C, nawet nie wiem, czy w pełni obsłuży C89; Keil uVision dla 8051 chyba podobnie)

Staram się w pracy utrzymywać kulturę pracy w terminalu uniksowym (MSYS2 albo WSL) z Makefile'ami. Moje doświadczenia w pracy z różnymi "dedykowanymi" środowiskami wykazywały, że choć niektóre rzeczy robi się prościej (np. debugowanie), to dedykowane środowiska stanowią barierę dla rozwoju i przenoszenia projektów na większą skalę. Staram się też dbać o to, żeby cała logika kodu, oprócz tego, że można ją uruchomić na kontrolerach, była też uruchamialna i testowalna na PCtach (i np. jak mam urządzenia, które normalnie komunikowałyby się po kablu albo po radiu, to ten sam kod może się komunikować po gniazdach sieciowych). Na pozór wydaje się, że to więcej pracy, ale w praktyce owo "więcej pracy" zajmuje w moim doświadczeniu o rzędy wielkości mniej czasu, bo mogę łatwo pisać testy automatyczne dla logiki, i takie środowisko do debugowania jest dużo wygodniejsze, niż dotykanie rzeczywistych urządzeń (oczywiście obsługę peryferiów trzeba ręcznie wytestować).

Zaletą jest też to, że w ten sposób powstaje lepsza architektura kodu, bo taka praktyka poniekąd wymusza, żeby oddzielać logikę aplikacji od obsługi peryferiów (widziałem projekty, w których to było ze sobą splecione, i nie polecam).

Od C++ wolę się trzymać z daleka.