Wpis z mikrobloga

#embedded #programista15k #cplusplus

Miruny mam pytanko. Od ponad 5 lat siedzę w embedded. Początkowo głównie C, teraz c++ od 2 lat. Zastanawiam się, w która stronę pójść. Mimo wszystko znacznie więcej ofert jest w embedded C niż w embedded c++. Ostatnio dostałem propozycję stanowiska C++ z QT. Pytanie czy warto w to wchodzić?

Co byście wybrali?

  • Embedded C 20.8% (5)
  • Embedded C++ 25.0% (6)
  • C++ QT 41.7% (10)
  • Coś innego? 12.5% (3)

Oddanych głosów: 24

  • 24
  • Odpowiedz
Zastanawiam się, w która stronę pójść.


@r00ti: pytanie z gatunku czy myć ręce, czy nogi. I jedno i drugie!
C siłą rzeczy będzie wypierany przez c++, w miarę jak antyczne platformy i ludzie, będą wypierani przez młodszych następców.
20 lat temu byś pytał czy warto w ogóle uczyć się C, skoro większość embedded powstaje w assemblerze ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@r00ti: Zalezy co Cie kreci. Moze zmien jezyk na jakis czas, poznaj cos nowego? Za jakis czas bedziesz mogl wrocic. Chyba, ze sie Tobie podoba, ale rob cos innego wtedy hobbystycznie, zeby nie zakopywac sie w jednej niszy, zreszta to pozwala nauczyc sie wiecej, ba pozniej wykorzystywac to czego sie nauczyles w innych okolicznosciach.
  • Odpowiedz
@r00ti: Ja mogę tylko doradzić ze lepiej rozwijać się w dol niz wysokopoziomowo. Tj system operacyjny, współbieżność, optymalizacja pod pipeline CPU itd. Twoja wartość rynkowa będzie rosnąć bo ta wiedzę zastosujesz wszędzie i specjalistów jest niewielu.
  • Odpowiedz
C siłą rzeczy będzie wypierany przez c++, w miarę jak antyczne platformy i ludzie, będą wypierani przez młodszych następców.


@zetisdead: nie, nie będzie bo C to wciąż najpopularniejszy język embedded, kerneli, bootloaderów i nic nie wskazuje na to żeby miało się to zmienić. C++ i QT to nie jest embedded, nawet jak piszesz na ARM - to po prostu pisanie wysokopoziomowych aplikacji.
  • Odpowiedz
najpopularniejszy język embedded, kerneli, bootloaderów i nic nie wskazuje na to żeby miało się to zmienić.


@Boska_Klaudia: ile kerneli i bootloaderów napisałeś w swoim życiu a ile aplikacji?
Podejrzewam, że aplikacji jednak więcej, więc nie ma sensu sugerowanie się kernelami i bootloaderami.

Jeśli ktoś nie jest leśnym dziadkiem, to swoje aplikacje będzie pisał w c++, jeśli tylko narzędzia mu na to pozwolą.
  • Odpowiedz
ile kerneli i bootloaderów napisałeś w swoim życiu a ile aplikacji?


@zetisdead: od początku do końca - żadnej. Do ilu kontrybuowałem lub używałem - kilku. Ile aplikacji - wiele. W czym - w C. Na Cortex-A, Cortex-M, Arduino. W embedded pracujesz głównie w C.
  • Odpowiedz
@Boska_Klaudia: nie, to są projekty, które mają kilkanaście...dziesiąt lat historii i gdy zaczynały to użycie c miało sens. Tego sensu jest pozbawione rozpoczynanie pisania współczesnych projektów w c.
Jak ktoś chce być kustoszem i pisać w C, jego sprawa.

powyzywasz ich od leśnych dziadów bo nie piszą w C++


Tak się dziwnie składa, że największymi obrońcami C są ludzie którzy się zasiedzieli i przestali rozwijać, uczyć nowych rzeczy.
  • Odpowiedz
nie, to są projekty, które mają kilkanaście...dziesiąt lat historii i gdy zaczynały to użycie c miało sens.

Jak ktoś chce być kustoszem i pisać w C, jego sprawa.


Nie, nie o wiek tu chodzi a o używalność języka. C najlepiej ze wszystkich nadaje się do low-level - kerneli, bootloaderów, portowania na nową architekturę.

Tego sensu jest pozbawione rozpoczynanie pisania współczesnych projektów w c.
  • Odpowiedz
Nie, nie o wiek tu chodzi a o używalność języka. C najlepiej ze wszystkich nadaje się do low-level - kerneli, bootloaderów, portowania na nową architekturę.


@Boska_Klaudia: ale wiesz, że c++ zawiera w sobie c i to ty decydujesz, które elementy c++ użyjesz?
Dlatego c++ dokładnie tak samo się nadaje do niskiego poziomu co c.

Tak się dziwnie składa że C to jeden z najpopularniejszych
  • Odpowiedz
@pepepanpatryk: nie ma gotowej receptury na to. Najłatwiej zacząć pracować przy kernelu linuxa i małymi kroczkami poszerzać swoją wiedzę o nowe elementy.
Polecam tez próbę napisania prostego RTOSa. Do dosc dobre ćwiczenie które pozwoli naprawdę zrozumiec podstawy o ktorych pisalem wyżej.
Co do optymalizacji to zaczął bym od Intel Developer Guide i ew jakieś przykłady typu popatrzeć na kod bibliotek do memcpy czy innych mocno zoptymalizowanych fragmentów.
  • Odpowiedz
@zetisdead: nie zgodzę sie z kilkoma sformułowaniami których użyłeś. Sporo twoich wypowiedzi nasycone jest tym specyficznym tonem supremacji C++ nad C które spotkałem juz wielokrotnie u młodych programistów którzy nieświadomi podstaw próbują udowodnić swoja wyższość znajomością wyrażeń lambda i mnogością rozszerzeń standardu.
Niedawno opanowali język programowania a juz próbują uchodzić za wyjadaczy i pouczać co charakteryzuje dobrego programistę embedded a co nie.

Język to tylko narzędzie. Stosuj takie które jest dopasowane do potrzeb. Nie ma czegoś takiego jak "najlepszy język" albo "jezyk determinujący umiejętności". Jest cały ogrom rzeczy poza językiem które w embedded maja duzo większe znaczenie.

Embedded to nie WEB w którym trzeba napierniczac tasiemce kodu bo klient chce kolejne wodotryski. Zazwyczaj chodzi o jakość, łatwy maintanace (czytelność kodu) i niezawodność. Ten kod pracuje w urządzeniach które bez poprawek beda działać latami i wcale nie chodzi o to ile abstrakcji języka programowania sobie zastosujesz. Nikogo nie obchodzi to w jakim języku programowania napisany jest router, sterownik ABS
  • Odpowiedz
@Rosly: C++ nawet bez STL-a, bez RTTI czy bez Alokatorów na Embedded jest lepszy i tyle.

Sam silnik template i typowania o jakim się nie śniło w zwykłym C, że masz błędy kompilatora na poziomie typów (a nie dopiero w runtime) przy użyciu np. takiej biblioteki jak https://github.com/mpusz/units#tldr albo https://github.com/nholthaus/units#getting-started-guide czy istnienie static_assert rozwala prymitywne typy C na łopatki - bez narzutu w runtime - po prostu "darmowe" fail-fast, gdzie
  • Odpowiedz