Jak wygląda praca programisty C++ na codzień?

Czy piszecie raczej soft do obsługi firmy? A może jakieś ciekawe projekty, symulacje fizyczne, medyczne itp? A może w C++ robi się tylko gry? Jakie są wasze typowe zadania np. w ciągu ostatniego tygodnia/miesiąca? Jakie biblioteki warto w tej branży znać?

Ja w C++ pisałem głównie na różne dziwne urządzenia (wojskowa centralka telefoniczna, nawigacja samochodowa, samochodowe urządzenie trackujące, telefon z Tizenem, szpitalna pompa do strzykawek, samochodowe radio / komputer pokładowy z wbudowaną nawigacją, sprzętowy load balancer), najczęściej działające pod Linuxem, ale też z QNX-em lub bez żadnego "dorosłego" systemu operacyjnego (tylko z RTOSem zapewniającym przełączanie tasków i ich synchronizację). Jak wygląda praca w takim środowisku?

1. Narzędzia są z epoki kamienia łupanego. Najczęściej nie ma IDE. Ja osobiście jestem przyzwyczajony do emacsa, więc jak mogę, to go używam. Podpowiadanie składni, nazw metod, jump to definition itp. nie działa z automatu. Są narzędzia oparte na clangu, które umożliwiają takie rzeczy w emacsie, ale trzeba je skonfigurować. Osobiście nauczyłem się żyć bez tego (grep w okienku terminalowym do kodu projektu, google do bibliotek). Następna sprawa to build system. Jest ich multum (gołe make, autotools, cmake, scons, bitbake, buildroot, żeby tylko wymienić te, z którymi się spotkałem). Buduje się najczęściej z command line. Jeśli potrafisz zbudować z command line, to można komendę budowania wydać spod emacsa, a wtedy edytor potrafi wskazywać miejsca błędów kompilacji przy pomocy skrótów klawiszowych. Build system to często najbardziej syfiasta część projektu i zmiana pozornie prostych rzeczy (daną bibliotekę chcemy dołączać statycznie a nie dynamicznie, zmiana opcji kompilatora dla wybranych plików) potrafi zająć często cały dzień. Dodatkowo sprawę utrudnia kroskompilacja. Oczywiście wszystko robi się przez edycję plików tekstowych, często o dziwnej składni. Kolejny etap to deployment binarek: bardzo zależy od urządzenia (począwszy od katalogów montowanych przez NFS, poprzez scp, programatory JTAG, po żonglerkę kartami SD). Ostatnia rzecz to debugowanie. Tu rządzi gdb, więc znajomość gdbowego command line to mus. Można odpalić gdb spod emacsa, wtedy emacs pokazuje, gdzie jesteśmy w kodzie, lub w ostateczności użyć gdbowego TUI. Jeśli program lub przynajmniej jego część da się zbudować na PC (co bardzo polecam), to można używać narzędzi typu valgrind.

2. Wiedza jest słabo przenośna między projektami. Nie ma jak w Javie czy C#, że jak nauczysz się jednego frameworka, to można go używać w kółko w wielu firmach/projektach. Tutaj każdy projekt jest inny. Czasami jedziemy na bibliotekach i narzędziach otwartych (lepiej), czasami jest są jakieś zamknięte biblioteki lub SDK od producenta sprzętu (gorzej). Np. w komputerze pokładowym w Audi jest środowisko zwane MIB, działające pod QNX, z koszmarnie przekomplikowanym API podobnym do CORBy. Wiedza przenośna między projektami to biblioteka standardowa, jakieś kawałki Boosta, API posixowe. Warto mieć swoją ulubioną bibliotekę do parsowania JSONa i i drugą do XMLa. Do robienia HTTP od strony klienta najczęściej używa się curla. Jedynym grubszym frameworkiem C++owym, który warto znać, jest Qt. Ja raczej nie robię GUI, więc Qt znam słabo, ale jest spore zapotrzebowanie na interfejsy "macane" na różnych urządzeniach wbudowanych, i robi się je najczęściej w Qt. Jeśli zamierzasz robić grafikę, to oczywiście przydaje się też OpenGL, szczególnie w wersji ES.

Taki to jest lajf. Mam nadzieję, że nie zniechęciłem za bardzo :) Ja tam lubię rzeczy niskopoziomowe i grzebanie się w bitach. Projekty są często ciekawe i niestandardowe (nie piszesz kolejnego CRUDa). Obecnie jest ożywienie w branży ze względu na modę na Internet of things, wszyscy chcą podłączać swoje mikrofalówki do internetu.

2. Wiedza jest słabo przenośna między projektami. Nie ma jak w Javie czy C#, że jak nauczysz się jednego frameworka, to można go używać w kółko w wielu firmach/projektach. Tutaj każdy projekt jest inny. Czasami jedziemy na bibliotekach i narzędziach otwartych (lepiej), czasami jest są jakieś zamknięte biblioteki lub SDK od producenta sprzętu (gorzej). Np. w komputerze pokładowym w Audi jest środowisko zwane MIB, działające pod QNX, z koszmarnie przekomplikowanym API podobnym do CORBy. Wiedza przenośna między projektami to biblioteka standardowa, jakieś kawałki Boosta, API posixowe. Warto mieć swoją ulubioną bibliotekę do parsowania JSONa i i drugą do XMLa. Do robienia HTTP od strony klienta najczęściej używa się curla. Jedynym grubszym frameworkiem C++owym, który warto znać, jest Qt. Ja raczej nie robię GUI, więc Qt znam słabo, ale jest spore zapotrzebowanie na interfejsy "macane" na różnych urządzeniach wbudowanych, i robi się je najczęściej w Qt. Jeśli zamierzasz robić grafikę, to oczywiście przydaje się też OpenGL, szczególnie w wersji ES.

A raczej jeśli pracujesz w jakiejś firmie to cały czas przy jednym projekcie przez kilka lat?

Kolejna sprawa: rozumiem, że np. taki programista C++ pisze oprogramowanie do komputera pokładowego w Audi A5. Ile procent czasu zajmuje mu zadania typu: "jak połączyć się z komputerem silnika by odczytać obciążenie silnika" (klimatyzacje samochodowe mają teraz różne tryby, np. tryb oszczędzania, w którym komputer stara się przy używaniu klimatyzacji zużywać jak najmniej paliwa) a ile wymyślenie algorytmu w jaki sposób oszczędnie używać klimatyzacji? Czy może ten algorytm jest podany z góry? A programista tylko go implementuje? Na ile w takiej pracy pomaga znajomość działania sprzętu, który się oprogramowuje? A może nie pomaga wcale? Ja np. wiem jak działają wszystkie ważniejsze systemy w samochodzie. Wiem, że w nowoczesnych samochodach np. sprężarka klimatyzacji jest rozłączana podczas gwałtownego przyśpieszania by nie odbierać mocy. Wiem, że wielu programistów takich rzeczy nie wie... tylko ja akuratnie mam styczność z webowymi.

@zarazek: Brzmi dość ciekawie. A jak wygląda teraz rynek pracy C++, programowania urządzeń i takich niskopoziomowych tematów? Jak czasem przeglądam oferty pracy, to wszędzie szukają ludzi głównie od aplikacji serwerowych w różnych językach, front-endu lub ewentualnie aplikacji mobilnych. Bardzo rzadko widzę oferty dla C++, co nie zmienia faktu, że część programistów na pewno się tym zajmuje.

xxxxxxx napisał(a):

ile wymyślenie algorytmu w jaki sposób oszczędnie używać klimatyzacji? Czy może ten algorytm jest podany z góry? A programista tylko go implementuje? [...] Wiem, że w nowoczesnych samochodach np. sprężarka klimatyzacji jest rozłączana podczas gwałtownego przyśpieszania by nie odbierać mocy.

Tego typu algorytmów na pewno nie będzie obmyślał programista.
Programista dostanie co najwyżej specyfikację do zaimplementowania.

Na ile w takiej pracy pomaga znajomość działania sprzętu, który się oprogramowuje?

Prawie nigdy nie zna się sprzętu, który się oprogramowuje, ani nawet softu który przyjdzie ci rozwijać.

Ile procent czasu zajmuje mu zadania typu: "jak połączyć się z komputerem silnika by odczytać obciążenie silnika" (klimatyzacje samochodowe mają teraz różne tryby, np. tryb oszczędzania, w którym komputer stara się przy używaniu klimatyzacji zużywać jak najmniej paliwa) a ile wymyślenie algorytmu w jaki sposób oszczędnie używać klimatyzacji?

Ojej, to bardzo zależy. Ogólnie większość roboty programistycznej to zwykła klepanina, klejenie API ze sobą i odhaczanie wymaganej funkcjonalości. Co nie znaczy, że jest to proste, bo problem tkwi bardziej w zrozumieniu wymagań klienta, a szczególnie interakcji pojedyńczych funkcjonalności między sobą i zaprojektowaniu tego tak, żeby banglało. Kawałki, w których potrzebna jest jakaś bardziej zaawansowana algorytmika to rarytas.

Akurat w przypadku Audi byłem podwykonawcą podwykonawcy podwykonawcy, robiłem malutki kawałek: integrację nawigacji z danymi trafficowymi z radia (TMC) i nawigacji z Google Earth. Oprogramowanie automotive tego typu jest roboine w trybie mega-korporacyjnym, tzn. programista nie ma wpływu na nic, przychodzą z góry szczegółowe wymagania funkcjonalne oraz API, które ma się do dyspozycji i które trzeba zaimplementować samemu. Oprogramowanie MIB jest bardzo modularne, praktycznie ten sam soft chodzi w Volkswagenach, Audi, BMW i Porsche, jest tylko inaczej "oskórkowany" i lepsze modele mają więcej bajerów, ale podstawa jest taka sama. Robisz jak na linii produkcyjnej: każdy developer dostaje malutki kawałek do zrobienia. Przy integracji GoogleEarth - nawigacja trzeba było się chwilę zastanowić nad strukturami danych, ale nie było potrzebne żadne rocket science: STL wystarczył.

Jakieś rzeczy do obsługi firmy w C++, to robiłem głównie w latch 2000-2005, później zdarzyło mi się cos ronbić, ale to były raczej modyfikacje jakiś opensourcowych rzeczy. A tak to tylko w embeded, jak juz kolega @zarazek pisał...

Wiem, ze niemieckie firmy samochodowe wzajemnie kolaborują między sobą bo sam mam VW do którego pasuje płytka mapami BMW :P

Swoją drogą czy takie nowe modele to programowanie na jakiejś aktualnej wersji C++ czy klepie się to dalej w C++ 11?