A komu to potrzebne - czyli zapotrzebowanie na programistów C++

Nie wierzę, że pisząc swoje aplikacje masz konieczność sięgać głębiej w celu znalezienia błędu w kodzie C++.

To się zdarza bardzo, bardzo rzadko. Ale jednak się zdarza.

To jest już brak umiejętności pracy z C++, a nie 'super fajna umiejętność grzebania w asmie'.

Najdziwniejsze jest to, że u innych ten sam kod (suma kontrolna się zgadza) działa poprawnie.

Jak w kodzie nawaliłeś byków to nie dziw się, że potem źle działa.

1. Zakładam, że błąd jest w moim kodzie.
2. Szukam błędu korzystając z różnych technik i okazuje się, że testy wskazują na plik "foo.cpp" w linii 123 oraz na dziesięć innych potencjalnych miejsc, gdzie coś mogło pójść nie tak.
3. Te same testy odpalone u kogoś innego nie wykrywają niczego.
4. Później okazuje się, że "problem jest znany i zostanie naprawiony w kolejnej wersji kompilatora/środowiska/czegośtam innego, co nie zależy bezpośrednio od mojego kodu". Przykład: jakiś czas temu podczas tworzenia okna w SFML dostawałem ciągle komunikat w stylu "Program nie odpowiada". Okazało się, że błąd był w implementacji SFML przeznaczonej dla GNOME, a mój kod był w porządku ([Linux] Fixed an issue where GNOME flags window unresponsive).

Miliony deweloperów tworzą nowe i rozwijają istniejące aplikacje. Nie ma tam takich wtf-ów, które Ty wymyślasz.

Ten przykład z xorem jest faktycznie dość dziwny i na pierwszy rzut oka ktoś mógłby stwierdzić, że gadam bzdury. Możliwe, że to po prostu wada fabryczna, bo ignorowanie pojedynczego klawisza jest niewątpliwie błędem. I to nie chodzi o to, aby "cośtam mocniej docisnąć" albo problemy typu "fizycznie uszkodzona klawiatura", bo po restarcie wszystko wraca do normy, więc problem raczej dotyczy oprogramowania. Zwłaszcza, że wykonywane instrukcje są co najmniej dziwne. Jak mi się uda to odtworzyć na emulatorze działającym na innym sprzęcie, to wtedy będę miał nieco więcej pewności, że to nie jest problem typu PEBKAC.

Czasem incremental build źle zadziała to budujesz całą solucję od zera i aplikacja będzie poprawnie zbudowana.

Są jeszcze błędy IDE (swoją drogą ciekawe, czy nowy Visual okaże się rzeczywiście lepszy). Zdarzały się przypadki, gdzie trzeba było od nowa utworzyć projekt i przenieść tam wszystkie pliki. A są i takie, gdzie ze względu na dziwne aktualizacje przyda się restart.

Jak dalej masz wtf-y to znaczy, że nabagniłeś zdrowo w kodzie i nie rozumiesz jak on działa.

Jeśli wina leży po mojej stronie, to wtedy dostaję nową lekcję pokory i traktowania swojego kodu z pewnym dystansem. A jak mam rację, to znaczy, że "błędy są wszędzie i trzeba zrozumieć tych ludzi, którzy wkładają tyle wysiłku w to, aby taki Kowalski mógł korzystać ze środowiska, które nie jest znowu takie tragiczne, jak mu się wydaje".

Zaglądanie 'pod maskę' w niczym nie pomoże i niczego nie zmieni.

Tylko, jeśli to mój kod jest błędny. A jak inaczej stwierdzić, kto jest winny bez schodzenia do niższych warstw?

O czym piszecie i czym są te 31c0 i 33c0?

Faktycznie, niezły offtop wyszedł. Niby temat jest pod dywanem, ale mimo wszystko może niepotrzebnie o tym napisałem. Chodzi o kody maszynowe operacji wykonywane przez procesory typu x86. To jeszcze niższy poziom abstrakcji, niż asembler. Zazwyczaj to jest właśnie to, co możesz sobie obejrzeć w edytorze szesnastkowym, gdy otworzysz nim jakiś plik wykonywalny, chociażby *.exe. Być może za mocno grzebię w takich rzeczach, bo gdy otwieram jakikolwiek zwykły plik, to jak widzę "90", to od razu myślę, że tam pewnie jest "nop" (i od razu sobie to kojarzę z "xchg ax,ax"), a przy "31 c0 ca 16" spodziewam się, że ten fragment odpowiada za czekanie na wciśnięcie dowolnego klawisza. Jak chcesz wiedzieć więcej, to w zasadzie zaczniesz się uczyć asemblera, czytać manuale Intela i takie tam... Ale na te pytania lepiej odpowie Google, niż ja, ewentualnie można o tym pogadać w oddzielnych tematach albo na nieco innych forach.

Ale wróćmy do tematu. Co jeszcze chcesz wiedzieć o potencjalnych zastosowaniach C++?

Właściwie nic, już wiem, że uczyłem się (prawie) wymarłego języka
A tak na poważnie :D...
To chyba wszystko, dowiedziałem się wszystkiego co chciałem. Tematu nie zamykam, może chcecie sobie kontynuować... to co robicie :p
Dzięki

EDIT: jest jedna rzecz,

Several high-performance and high-reliability components.

Facebooka? Stronę internetową? W C++? Jakie to komponenty?

a przy "31 c0 ca 16" spodziewam się, że ten fragment odpowiada za czekanie na wciśnięcie dowolnego klawisza

Chodzi o CD 16, czyli int 0x16? CA to opkod dalekiego RET z 16-bitową liczbą bajtów do zdjęcia ze stosu.

Oczywiście, to wiele wyjaśnia: piszesz pod goły BIOS, który jest nieustandaryzowany, zbugowany i przestarzały. Nie dziwię się, że na niektórych maszynach coś ci nie działa. Na mojej w ogóle by nie działało, bo kompatybilność z BIOSem jest wyłączona :P

Trudno żeby nie, odpowiadając na takie ciężkie głupoty, jakie wtedy napisałeś.

Jeżeli tak twierdzisz to najwyraźniej nigdy nie miałeś okazji porównać projektów aplikacji prowadzonych w C++ie z projektami C#owymi.

Co to za argument w porównaniu języków, że jednego trzeba się nauczyć, a drugiego już najwyraźniej nie, skoro to zauważalna wada 'tego złego języka', ale już do przemilczenia w 'tym dobrym języku'.

Napisałem, że dużo łatwiej jest się nauczyć C# niż C++ i dużo prościej w nim pisać. Chociażby dlatego, że:

• w C# jest mniejszym językiem (posiada w standardzie więcej bibliotek, ale sam język jest mniejszy)
• wspiera jeden paradygmat a nie wiele
• dużo prościej zarządzać pamięcią 
• dużo prościej testować jednostkowo kod C#. Z samego faktu wspierania testowania przez język i środowisko. Tworzenie mocków jest proste z powodu pełnej informacji o typach, praktycznie generują się same. W C++ giniesz w mieszance google mocków, cppunitów i boosttestów. Sam język z racji ograniczonych możliwości sprawia, że ilość ścieżek w programie jest mocno ograniczona co bezpośrednio wpływa na łatwość/trudność testowania
• w C# dużo prościej instalujesz biblioteki bo za pomocą NuGeta
• w C# dużo prościej wybrać bibliotekę do aplikacji okienkowych, a biblioteki te są wspierane przez środowisko
• w C# dużo prościej zarządzać procesem budowania i czasem budowania
• w C# dużo prościej wystawić interfejs RESTowy czy SOAPowy
• w C# dużo prościej serializować dane XMLowe czy JSONowe
• w C# dużo prościej połączyć się z bazą
• w C# dużo prościej mapować dane z bazy dzięki DTO
• w C# operacje na tekście są dużo prostsze
• w C# operacje na systemie plików są dużo prostsze

Można tak długo. Nie mówię tego jako wady czy zalety ale po prostu stwierdzam fakt. I nie pisze się tego 'tylko szybciej', ale 'szybciej i prościej'.

To samo napisałeś o wielowątkowości - poprawne pisanie aplikacji wielowątkowych to szeroki temat. Łatwo napisać "async/await i gotowe", trudniej wstawić w to coś pożytecznego i nie nabawić się problemów z powodu naiwnego podejścia do sprawy.

Aby poprawnie używać async/await w C# nie potrzebujesz praktycznie żadnej wiedzy i również nie wpadasz w żadne problemy. Pozwala ci to napisać dobrze działającą aplikację, która będzie responsywna, która nie będzie wieszać wątku GUIowego. W C++ musisz się nauczyć dużo więcej, aby osiągnąć ten sam rezultat i co więcej, robić to w zgodnie z ideologią wpisaną w bibliotekę GUIową a nie w sam język. Ile bibliotek GUI w C++ zaadaptowało standardowy system wątków z C++11? A może znakomita większość dalej implementuje swoje rozwiązania?

Skomplikowane algorytmy, które wymagają zrównoleglenia lub które są nietrywialnie do zrównoleglenia, systemy pracujące na nietrywialnych wspólnych zasobach, optymalizacje dostępu co do instrukcji, minimalizacja oczekiwań wątków - takie zadania faktycznie wymagają odpowiedniego zrozumienia wielowątkowości i dogłębnego poznania języka. Natomiast puszczanie sobie 'z boku': zawołania do bazy danych, parsowania pliku, kopiowania danych czy oczekiwanie na serwis są w C# do bólu trywialne i to niezależnie od wybranej biblioteki oraz nie wymagają dodatkowego kodu.

Napisanie aplikacji okienkowej w C# i w C++ jest równie proste. Nie musi być równie szybkie, ale jest równie proste.

Nie, nie jest. Z tych powodów, które napisałem wyżej. Nawet mając doświadczony zespół.

Porównując prędkość implementacji analogicznych featurów w projektach C# i C++ widać różnicę na korzyść C#. Również projekty C++owe cechują się dużo większą ilością błędów zgłaszanych przez klientów, dużo mniejszą wykrywalnością błędów na poziomie testowania jednostkowego mimo dużo większej liczby testów. Po prostu w C++ łatwiej zrobić błąd.

Nie chce się kłócić, który język jest lepszy, a który gorszy. Każdy z nich jest dobry w swojej dziedzinie. C# jest wybierany przez biznes nie dlatego, że ktoś się obraził na C++ ale dlatego, że projekty aplikacji okienkowych prowadzone w C# są szybciej setupowalne, łatwiejsze w zarządzaniu, tańsze w utrzymaniu i łatwiejsze w uzbieraniu zespołu.

Nie twierdzę, że w C++ nie da się zrobić dobrej aplikacji okienkowej bo połowa aplikacji Adobe jest napisana właśnie w C++. Ale nie dlatego, że było to równie proste ale dlatego, że ich aplikacje przetwarzają duże ilości danych i muszą robić to szybko. A przeciętne wczytanie 600 MB pliku w C# potrafi zużyć 2GB pamięci.

To mój ostatni offtopowy post, ponieważ jeżeli to cię nie przekonuje, to nic cię nie przekona. Też kiedyś uważałem C++ za króla wszystkich języków, a teraz po prostu wiem, że jest królem w swojej kategorii, i nie jest tą kategorią pisanie modern responsive gui applications.

Jeszcze dopowiadając autorowi bez żadnych wycieczek tematycznych:
@latajacaryba
Pytanie 'Czy warto się uczyć C++?' jest podobne do pytania czy warto się uczyć niemieckiego/fińskiego/chińskiego. Wszystko zależy od tego co chcesz robić i jakie zagadnienia cię kręcą.

wiem, że uczyłem się (prawie) wymarłego języka

Nie no, chyba nie jest aż tak źle. Zwłaszcza, jeśli spojrzysz na to, co dzieje się ostatnio. Może kiedyś będzie lepiej... Poza tym, czegoś się przecież nauczyłeś i to się pewnie przyda przy nauce nowych języków. W sumie to jeśli wybierzesz na przykład taką Javę, to raczej łatwiej będzie przejść z C++ do Javy, niż odwrotnie.

może chcecie sobie kontynuować... to co robicie :p

Grzebanie w asemblerze? Robię to tylko, jeśli muszę, a wydarzenia z ostatnich dni wskazują na to, że raczej wzniosę się znów na wyżyny abstrakcji.

Chodzi o CD 16, czyli int 0x16?

Fakt, zawsze myliło mi się "ca" z "cd".

CA to opkod dalekiego RET z 16-bitową liczbą bajtów do zdjęcia ze stosu.

Z ciekawości sprawdziłem i rzeczywiście obok tych "int-ów" faktycznie były "ret-y". Na szczęście w najbliższym czasie pewnie nie będę musiał do tego wracać.

Oczywiście, to wiele wyjaśnia: piszesz pod goły BIOS, który jest nieustandaryzowany, zbugowany i przestarzały. Nie dziwię się, że na niektórych maszynach coś ci nie działa. Na mojej w ogóle by nie działało, bo kompatybilność z BIOSem jest wyłączona :P

Dobra, teraz mam UEFI. Czas pokaże, czy było warto...

wspiera jeden paradygmat a nie wiele

Co nie musi być zaletą. Ale o tym przekonasz się, gdy zechcesz coś napisać inaczej, niż imperatywnie (chociażby funkcyjnie).