Co dalej po przeczytaniu "Opus Magnum C++"

0

Cześć,
wiem, że dzieło Grębosza jest kwestionowane jako źródło nauki, ale mi ta książka podchodzi i powoli sobie przerabiam. Zastanawiam się natomiast co dalej, zakładając, że ogarnę zawarty w nim materiał. Sama książka, choć potwornie gruba, skupia się wyłącznie na języku i nie porusza całego ekosystemu, w którym porusza się C++ dev, a każde narzędzie, biblioteka tak naprawde ma swoją dedykowaną książkę czy kurs.
Krótko o mnie: jestem po studiach informatycznych, ale nigdy nie ogarnąłem na tyle programowania by się nazwać devem. Pracuje w IT jako sysadmin, jestem linuksowym geekiem i zawsze te programowanie - w szczególności C++ - siedziało mi w głowie. Na początku mój główny obszar zainteresowań nie wiąże się stricke z programowaniem zarobkowym jako dev, ale z kontrybucją (jakkolwiek to po polsku brzmi) w moich ulubionych projektach linuksowych open source, czyli przede wszystkim KDE (środowisko desktopowe Plasma, aplikacje, cały ekosystem), a w związku z tym Qt i programowanie GUI, ale również programowanie systemowe, aplikacje w CLI, których też jest pełno napisanych w C++. Fantanstycznie by było, gdybym potem przekształcić to w prace zarobkową, ale wiem, że do tego daleka droga.
Będę wdzięczny za każdą podpowiedź :)

2

ale jakiej odpowiedzi oczekujesz ? Bo w sumie nie widać pytania ? Domniemam, że po przeczytaniu Grębosza chcesz wiedzieć jakiej biblioteki uczyć się dalej ?

0
zkubinski napisał(a):

ale jakiej odpowiedzi oczekujesz ? Bo w sumie nie widać pytania ? Domniemam, że po przeczytaniu Grębosza chcesz wiedzieć jakiej biblioteki uczyć się dalej ?

coś w tym rodzaju. i może nie tyle co się uczyć, ale za pomocą czego. chodzi mi o to, że jak przerobie Grębosza, to co będzie dobrym, następnym krokiem w zakresie samego języka, bo może książka tego nie pokrywała, a jest kluczowe w dalszej nauce np. właśnie Qt, a nie jest książką typowo o Qt. i też by nie uczyć się tego samego co w książce, tylko np. inaczej opisane (co oczywiście samo w sobie też nie jest złe). mam nadzieję, że zbytnio nie namieszałem.

5

@bzk4aster:

Nie kazdy / niewielu (moje domniemanie, ale takie mam przeświadczenie) "absolwentów" Grębosza zostaje zawodowymi programistami C++.

  1. Język C++ na własną prośbę obsuwa się w nisze / niszę, a GUI to nisza w niszy
  2. Tak to już w naszym żywocie jest, że rzadko się pracuje w pierwszym poznanym języku . Programista w sensie profesjonalnym to zna 2-4 języki biegle, a w dodatkowych 3-5 się całkiem dobrze porusza, gdy pojawiają się jakies zadania uzupełniajace.
  3. Tradycyjnie - z czym nie do końca sie zgadzam - język C++ jest mocno zakorzeniony w dydaktyce. Bijąc się z Gręboszem - w sensie pozytywnym - i tak juz jesteś do przodu od dziesiątek tysięcy studentów, którzy liznęli C++ po łebkach, i de facto znają C.

Pora na podsumowanie.
Nie zrozum źle, nie namawiam do porzucenia C++, ale jest też ścieżka poszerzenia spektrum języków. Z jednej strony można zwrócić uwagę na Python - przez to że jest do zupełnie innych rzeczy niż C++, a przez to obszary się uzupełniają.
Z innej strony Java (projektowana 1995 w odniesieniu do wad C++) i C# (bardzo udana Java 2.0, mądrze zrobiony "klon")

Z niealgorytmicznych, to SQL, liznąć CSS+HTML

4

następnym krokiem w zakresie samego języka

nic, w samym komitecie standaryzacyjnym nie rozumieją tego języka. Pozostłało czytać książki, blogi, cppcon i płakać do poduszki.

A jak chcesz robić kontrybujce do c++ to cóż musisz pisać kod :) zacznij od imeplementajci jakiegóś softu własnego pomysłu nawet jeśli to odtwórcze. A później podpenij się pod projek.t

0
ZrobieDobrze napisał(a):

@bzk4aster:

Nie kazdy / niewielu (moje domniemanie, ale takie mam przeświadczenie) "absolwentów" Grębosza zostaje zawodowymi programistami C++.

  1. Język C++ na własną prośbę obsuwa się w nisze / niszę, a GUI to nisza w niszy
  2. Tak to już w naszym żywocie jest, że rzadko się pracuje w pierwszym poznanym języku . Programista w sensie profesjonalnym to zna 2-4 języki biegle, a w dodatkowych 3-5 się całkiem dobrze porusza, gdy pojawiają się jakies zadania uzupełniajace.
  3. Tradycyjnie - z czym nie do końca sie zgadzam - język C++ jest mocno zakorzeniony w dydaktyce. Bijąc się z Gręboszem - w sensie pozytywnym - i tak juz jesteś do przodu od dziesiątek tysięcy studentów, którzy liznęli C++ po łebkach, i de facto znają C.

Pora na podsumowanie.
Nie zrozum źle, nie namawiam do porzucenia C++, ale jest też ścieżka poszerzenia spektrum języków. Z jednej strony można zwrócić uwagę na Python - przez to że jest do zupełnie innych rzeczy niż C++, a przez to obszary się uzupełniają.
Z innej strony Java (projektowana 1995 w odniesieniu do wad C++) i C# (bardzo udana Java 2.0, mądrze zrobiony "klon")

Z niealgorytmicznych, to SQL, liznąć CSS+HTML

to tym bardziej skoro dev powinien się umieć obracać w kilku językach to nie wydaje mi się by wybór C++ był do końca zły skoro (do nauki programowania in general) z tej wiedzy mogę skorzystać ucząc się Rusta czy Go.

revcorey napisał(a):

następnym krokiem w zakresie samego języka

nic, w samym komitecie standaryzacyjnym nie rozumieją tego języka. Pozostłało czytać książki, blogi, cppcon i płakać do poduszki.

A jak chcesz robić kontrybujce do c++ to cóż musisz pisać kod :) zacznij od imeplementajci jakiegóś softu własnego pomysłu nawet jeśli to odtwórcze. A później podpenij się pod projek.t

myślę, że tak źle nie jest :) tzn. sama ilość publikacji o tym języku może tak sugerować :)
a jeśli chodzi o kontrybucję w sferze moich zainteresowań to znalazłem ciekawy guide: https://community.kde.org/Get_Involved/developmenta

3
bzk4aster napisał(a):

to nie wydaje mi się by wybór C++ był do końca zły

Dla kogoś ambitniejszego, a do takich cie zaliczam, C++ jest nie "mniejszym złem", a znać go jest obowiązkowe *) Baza, prawzór, nauka ogólnego programowania.
Chciałem tylko powiedzieć, że niekoniecznie na ścieżkę za którą mają ci płacić.

*) marnowaniem czasu ucznia/studenta i prowadzącego jest dla szczypiorko-leniwców. To wybitnie trudny język, gdyby traktować na serio.

0

Po ogarnięciu Grębosza polecam ci Qt oraz w zanadrzu do ogarnięcia C# z WPF - chyba, że wypowie się tu ktoś bardziej doświadczony czy poleca WPF czy np nie ma czegoś lepszego ?

Jeszcze SQL ci się przyda, jest niemal wszędzie

1

tak jak pisałem - interesuje mnie platforma Linux oraz ostatnio wszystko w okół WebAssembly

Tego o WebAssembly akurat nie pisałeś wcześniej (przynajmniej nie w tym watku)

To może jak chcesz (w miarę) niskopoziomowe języki to teraz dla odmiany Rust? Taki C++ 2.0 (pozwolę sobie na taką nazwę skoro C# został tu już nazwany Javą 2.0 :p ) BTW już całkiem dużo materiałów jest na temat kompilacji Rusta do WebAssembly, np Rust 🦀 and WebAssembly 🕸 lub Compiling from Rust to WebAssembly

UPDATE

a tak w ogóle po co oni tworzą coraz to nowe wynalazki typu rust

Po co taki Rust sobie istnieje? C++ zebrał dużą liczbę featurów przez lata. Najbardziej przeładowany język w historii. Rust atakuje tą samą niszę co C++ mając bardziej przemyślaną składnię i bardziej przemyślane feature'y. Dodatkowo jest borrow check co by tak łatwo po nie swojej pamięci nie jeździć (dalej się da oczywiście, to nie Haskell :P )

0
KamilAdam napisał(a):

Po co taki Rust sobie istnieje? C++ zebrał dużą liczbę featurów przez lata. Najbardziej przeładowany język w historii.

to że ma ogromną ilość funkcji to dobrze, raczej nie powiedziałbym, że to jakaś ujma, przecież jak dysponujemy kompletnym narzędziem, które stale jest ulepszane, to wtedy jesteśmy w stanie więcej zrobić i nie musimy później szukać innego narzędzia i uczyć się jego obsługi po to by rozwiązać inny problem ?

4

Ludzie traktują książki jakby były lekarstwem na wszystko, a tam często lanie wody jest i powierzchownie wszystko opisane.

Ale jak celujesz w QT, to kończ tą książkę i bierz się za pisanie aplikacji.
Poznaj sobie potem cmake, którym się buduje projekt w qt, na początku ide qt, ci wszystko zbuduje, ale spróbuj samemu napisać CMakeLists.txt, plik i z konsoli go sobie ogarnij.

A reszta to rozbrajasz tam w tym QT różne problemy, komunikacja z serwerami http rest api i np. parsowanie jsonów.

Każdy rozwiązany problem będzie ci nasuwał kolejne pomysły i tak samo napędzając się machina ruszy.

0
Wypierdzistyy napisał(a):

Ludzie traktują książki jakby były lekarstwem na wszystko, a tam często lanie wody jest i powierzchownie wszystko opisane.

Ale jak celujesz w QT, to kończ tą książkę i bierz się za pisanie aplikacji.
Poznaj sobie potem cmake, którym się buduje projekt w qt, na początku ide qt, ci wszystko zbuduje, ale spróbuj samemu napisać CMakeLists.txt, plik i z konsoli go sobie ogarnij.

A reszta to rozbrajasz tam w tym QT różne problemy, komunikacja z serwerami http rest api i np. parsowanie jsonów.

Każdy rozwiązany problem będzie ci nasuwał kolejne pomysły i tak samo napędzając się machina ruszy.

no właśnie ja w ten sposób uczę się Qt i jeszcze od groma zostało do ogarnięcia... mimo, że umiem zrobić w pełni działający program na bazie danych to i tak ledwie Qt liznąłem, bo to bardzo ogromne narzędzie, a jeszcze do przerobienia C# z WPF... już nawet nie wspomnę, że goły C++ jest ledwo co odkryty, a ile jeszcze zostało ? Czy jest ktoś, kto to wszystko ogarnia ?

3

Opus magnum C++ i co dalej

Teraz pozostaje tylko nauczyć się programować.

2

(edit) Ale mi wyszła ściana tekstu, współczuje czytania, doradzanie początkującemu zawsze prowokuje takie posty. Tym nie mniej sądzę, że udało mi się trafnie wyrazić swój punkt widzenia i sądzę @bzk4aster że byłbyś w stanie wyciągnąć z tego coś pożytecznego dla siebie. Zachowaj jednak otwarty umysł, z pewnością nie wszystko co napisałem, jest prawdą oświeconą.

co zatem polecasz w kontekście tego co jeszcze napisałem?

Ciężko coś doradzić, bo z każdym aspektem podanego przez Ciebie kontekstu będzie się wiązało rozczarowanie lub frustracja na którymś etapie. Tak więc IMHO to nie podany jawnie przez Ciebie kontekst się liczy, ale z jaką frustracją będziesz w stanie sobie poradzić? Otóż....

kontrybucją (jakkolwiek to po polsku brzmi) w moich ulubionych projektach linuksowych open source, czyli przede wszystkim KD

KDE to wielka krowa i jako początkujący ledwo potrafiący obsłużyć kompilator najprawdopodobniej będziesz w stanie kontrybuować jakieś bardzo specyficzne pierdołki w bardzo specyficznych pakietach. Jeśli jako początkujący liczysz, że za pół roku zostaniesz autorem widgetu/modułu instalowanego na dziesiątkach tysięcy maszyn to mam dla Ciebie smutną wiadomość. Nie nauczysz też się dobrze programować, jeśli przez większość czasu będziesz czytać kod innych.

programowanie systemowe

No to jeszcze musisz się nauczyć C oraz jak działa OS, w sensie tak pod spodem a nie tylko to co widzi sysadmin. Wiedza systemowa przydaje się na rynku jako jeden z elementów, ale rezultaty i codzienna praca jest mało seksi, często gęsto to nikt nawet nie zauważa włożonego wysiłku.

Fantanstycznie by było, gdybym potem przekształcić to w prace zarobkową

To długi temat, ale jakbym miał skrócić rynek obecnie to systemowcy najczęściej są potrzebni przy projektach gdzie używa się RTOS a tam gdzie wymaga się twardej znajomości Qt to zazwyczaj jest nudno. W ciekawych projektach gdzie na liście pojawia się Qt najczęściej pojawia się on w sekcji Nice to have i główny nacisk pojawia się w innych aspektach. Jeśli chciałbyś być mantainerem czegoś w KDE to wygląda to tak, że jakaś firma sponsoruje etat gdzie Twoim obowiązkiem jest kontrybucja, ale sam nie wiem ilu jest takich ludzi na świecie konkretnie w KDE. Nawet nie wiem czy to tak działa w tym przypadku, zakładam, że działa to podobnie jak w projekcie jądra linuksa.

I teraz dochodzimy do sedna mojego zdecydowanie zbyt długiego postu.

gdy dalej obce są mi podstawy i napisać umiem co najwyżej skrypt w bashu

No właśnie. Pochwalam twarde stąpanie po ziemi, oszczędzi to Ci to czas i pomoże poradzić sobie z frustracją decyzji jaką podejmiesz, jakakolwiem by ona nie była, a w mojej ocenie opcje masz dwie. Albo nauczysz się programować, żeby potem mieć opcje na kolejne frustracje wymienione wyżej, albo rzucasz to w cholerę. Jeśli chcesz się nauczyć programować to opcję masz jedną - musisz zacząć programować.

A zaczynasz w ten sposób - bierzesz jakiś względnie prosty projekt CLI i go wykonujesz. Jak wybrać projekt? Jeśli w ogóle nie czujesz języka to ja zawsze polecam implementację algorytmu DES do szyfrowania plików. Jest to przestarzały algorytm, który do niczego Ci się nie przyda, ale implementowałem go ręcznie kilka razy i wiem, że jest na tyle skomplikowany, że przeciągnie Cię przez wszystkie podstawowe mechanizmy języka ale jednocześnie na tyle prosty, że początkujący ogarnie. To jest zawsze mój pierwszy projekt jak się uczę nowego języka. Jak skończysz i działa to przerabiasz CLI na GUI. Potem możesz napisać sobie czat tekstowy. Jak się uda to przerobić klienta CLI na GUI. Potem mógłbyś zrobić sobie klienta torrentowego, a potem np. klienta poczty gmail. Jeśli masz pracę i inne hobby to jako początkujący na pół roku przynajmniej masz już co robić.

W między czasie jako oderwanie się od pisania kodu polecam ściągnąć coś dużego by spróbować podebugować, tak na początek, żeby podejrzeć jak wygląda kod pisany przez innych ludzi a potem spróbować dowiedzieć się dlaczego tak różni się od tego, który Ty piszesz. To również poszerzy Twoje horyzonty. Takim dużym projektem jest chociażby QGIS albo QtCreator.

0
several napisał(a):

(edit) Ale mi wyszła ściana tekstu, współczuje czytania, doradzanie początkującemu zawsze prowokuje takie posty. Tym nie mniej sądzę, że udało mi się trafnie wyrazić swój punkt widzenia i sądzę @bzk4aster że byłbyś w stanie wyciągnąć z tego coś pożytecznego dla siebie. Zachowaj jednak otwarty umysł, z pewnością nie wszystko co napisałem, jest prawdą oświeconą.
[...]

Dziękuję, bardzo wartościowy post i dodam go sobie do zakładek :)
Czy zatem wg Ciebie źródłem mojej przyszłej frustracji będzie to jaki język (i wszystko co z nim związane) sobie wybrałem i przy Pythonie/Go/Ruby/Rust (innych nie wymieniam, bo nie są w sferze moich zainteresowań) by tak nie było albo było w mniejszym stopniu?

1

Pan mnie kod pokaże

Jak uczysz się programowania a nie masz kodu który możesz pokazać to nie uczysz się programowania.

4

Czy zatem wg Ciebie źródłem mojej przyszłej frustracji będzie to jaki język (i wszystko co z nim związane) sobie wybrałem i przy Pythonie/Go/Ruby/Rust (innych nie wymieniam, bo nie są w sferze moich zainteresowań) by tak nie było albo było w mniejszym stopniu?

Frustracje, które opisałem są agnostyczne względem technologii. Frustracje związane z samą technologią również przyjdą i każda ma swoje własne więc o nich nie wspominałem. Jakbym miał podsumować setki książek i artykułów na temat C++ by skondensować jego problem to pewnie opisałbym to w ten sposób - to jest język którego uczysz się dwa razy, najpierw jak działa i jak się w nim poruszać a potem drugi raz gdy poznajesz całą masę wyjątków od reguły i sytuacji brzegowych.

Inne technologie też mają swoje problemy, tylko tak jak wspominałem wcześniej, to jest indywidualna sprawa kto z jakimi frustracjami potrafi żyć a z jakimi nie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1