Najbardziej oczywiste to programowanie systemowe, embedded.
Jeszcze od biedy przy kompilatorach, o ile kompilatory nie poszły teraz ostro w C++.
Jeszcze jakieś działki?
0
0
Tizen :D
0
Wesoły Mleczarz napisał(a):
Tizen :D
?
0
Tizen jest systemem operacyjnym Samsunga. Jednym ze sposobow pisania aplikacji jest wlasnie pisanie w C, jest to "glowny" jezyk Tizena.
Co prawda nie jest to wygodne, ale mozesz byc programista aplikacji Tizena w C.
0
tizen jest na zegarkach samsunga
0
Define guru :) A jakie miasto? Może coś się znajdzie.
Tizena odradzam: https://arstechnica.com/gadgets/2017/04/samsungs-tizen-is-riddled-with-security-flaws-amateurishly-written/ Moje doświadczenia pokrywają się z tym artykułem.
0
Osobiście uważam, że w dzisiejszych czasach nie powinno się w ogóle zaczynać projektu w gołym C, jeśli nie ma twardych wymagań wymuszających jego użycie (np. ma to być moduł kernela Linuksowego). C++ lub Rust są dużo łatwiejsze w ogarnięciu na dłuższą metę. Może jeszcze jakieś małe rzeczy na mikrokontrolery łatwiej się pisze w C, ale pierwszy malloc w programie powinien dać do myślenia, czy nie lepiej Rust lub C++.
1
Nie można być "guru" danej technologii, bez wiedzy gdzieś jest wykorzystywana i jakie są najlepsze zastosowania lub które firmy mają fajne w tym projekcie.
0
zarazek napisał(a):
O C++ lub Rust są dużo łatwiejsze w ogarnięciu na dłuższą metę.
Znakomita krotochwila milordzie.
0
datdata napisał(a):
Nie można być "guru" danej technologii, bez wiedzy gdzieś jest wykorzystywana i jakie są najlepsze zastosowania lub które firmy mają fajne w tym projekcie.
No ajkoś nikt nie podał adnej działki poza tymi wymienionymi w 1szym poście. Więc o co ci chodzi? :D
4
Bogaty Karp napisał(a):
zarazek napisał(a):
O C++ lub Rust są dużo łatwiejsze w ogarnięciu na dłuższą metę.
Znakomita krotochwila milordzie.
Debugowałeś kiedyś problemy z pamięcią w dużym, starym, pisanym przez wiele osób programie? Może na dodatek wielowątkowym? Może takim, który używa własnych alokatorów zamiast malloc/free albo musi działać na tyle szybko, że użycie valgrinda nie wchodzi w grę? A może lubisz kontenery zrobione na makrach i/lub rzutowaniu na void*? Może lubisz ręczne zliczanie referencji? Z pętlami, o których trzeba pamiętać i rozwiązywać je? Pewnie nigdy nie pomyliłeś się przy obliczaniu rozmiaru alokacji (struktura właściwa + rozszerzalna tablica na końcu + Bóg wie co jeszcze). Pewnie nigdy nie zapomniałeś sprawdzić kodu błędu zwracanego przez funkcję API. Itd. itp. Na wszystkie te problemy Rust i nowoczesne C++ mają odpowiedzi (przynajmniej do pewnego stopnia).
0
zarazek napisał(a):
Bogaty Karp napisał(a):
zarazek napisał(a):
O C++ lub Rust są dużo łatwiejsze w ogarnięciu na dłuższą metę.
Znakomita krotochwila milordzie.Debugowałeś kiedyś problemy z pamięcią w dużym, starym, pisanym przez wiele osób programie?
Tak - w kernelu znanym pod nazwą Linux.
Może na dodatek wielowątkowym?
yup
Może takim, który używa własnych alokatorów zamiast malloc/free albo musi działać na tyle szybko, że użycie valgrinda nie wchodzi w grę?
yupi kay yey, I did it
A może lubisz kontenery zrobione na makrach i/lub rzutowaniu na void*? Może lubisz ręczne zliczanie referencji? Z pętlami, o których trzeba pamiętać i rozwiązywać je? Pewnie nigdy nie pomyliłeś się przy obliczaniu rozmiaru alokacji (struktura właściwa + rozszerzalna tablica na końcu + Bóg wie co jeszcze).
Jak ktoś się boi, że się spoci to może sobie podłączyć biblioteki do zarządzania pamięcią za niego.
Pewnie nigdy nie zapomniałeś sprawdzić kodu błędu zwracanego przez funkcję API. Itd. itp.
Gdzieś tak od 3ciej klasy liceum mi się jakoś nie zdarzyło.
Na wszystkie te problemy Rust i nowoczesne C++ mają odpowiedzi (przynajmniej do pewnego stopnia).
Meh. Rozwiązują je tylko połowicznie/iluzorycznie, na dodatek bohatersko walczą ( czy raczej programiści potem walczą ) z problemami nie znanymi w innych językach.
0
Gołe C to legacy code. Ktoś to musi utrzymywać, ale proszę nie wytwarzać tego więcej. - zarazek dziś, 10:36
Taaaa, piszmy sterowniki i kernele w C# albo Javie xD
0
Bogaty Karp napisał(a):
Gołe C to legacy code. Ktoś to musi utrzymywać, ale proszę nie wytwarzać tego więcej. - zarazek dziś, 10:36
Taaaa, piszmy sterowniki i kernele w C# albo Javie xD
Pardon, miałem napisać "w Node.js"
0
Albo w Rust.
0
Tak - w kernelu znanym pod nazwą Linux.
Przyznaję się, nie jestem kernelowym wymiataczem. Napisałem może kilkaset linijek kodu do kernela Linuxowego. I nie, nie ma ich w mainline.
Jak ktoś się boi, że się spoci to może sobie podłączyć biblioteki do zarządzania pamięcią za niego.
I jakie podłączałeś w kernelu? :) A w niekernelu?
Na wszystkie te problemy Rust i nowoczesne C++ mają odpowiedzi (przynajmniej do pewnego stopnia).
Meh. Rozwiązują je tylko połowicznie/iluzorycznie, na dodatek bohatersko walczą ( czy raczej programiści potem walczą ) z problemami nie znanymi w innych językach.
Może jakieś konkerety?
Pardon, miałem napisać "w Node.js"
Najlepiej sprowadzić rzecz do absurdu.
0
Bogaty Jeleń napisał(a):
Jeszcze jakieś działki?
To może jeszcze:
- High speed networking; Np. Data Plane Development Kit, Open Data Plane, itp.
- Krypto
Poza tym (uściślając embedded i programowanie systemowe) to kernele, rówież inne niż Linux, firmware, bootloadery, RTOSy, systemy do walidacji chipów
0
Może powiesz co robiłeś wcześniej, skoro jesteś takim guru w C?
Jeśli interesuje Cię dobra i ciekawa praca w C to polecam Automotiwe. Tam C było, jest i będzie. Najlepiej za granicą, bo w Polsce to jak wiadomo jakie są zarobki.