Vreau sa cumpar o carte de C++ pentru un elev in clasa a IX-a
As vrea sa fie ceva gen “bible” , hardcover care sa fie valabila si peste 20 de ani. Sa porneasca de la zero si sa sa duca in cel mai mic detaliu.
Eu am invatat prin 99 din asa ceva, dar nu mai tin minte si stiu ca era un cost pe care nu mi-l permiteam
Any ideas?
Tx
La cum se schimba limbajele, in 5 ani o sa ai surpiza ca este deja expirata.
Pare ca asta este biblia
Dar este overkill pt cineva de clasa a 9 a care a buchisit programarea
Dar lucrurile de baza o sa fie valabile tot timpul.
cu ce te-a supărat? :))
Tx. Si eu am invatat dupa asta. Nu stiam daca mai este de actualitate
Asta era cam singura pe care o gaseam cand eram in liceu:
Daca e nevoie de bible la modul ăla, referințele de pe net sunt mai bune, eventual chiar standardul limbajului. Am avut și eu cartea aia la liceu, dar a fost destul de pointless. Nu era ce aveam nevoie. Cred că are și niște secțiuni de Windows systems programming care e o pedeapsa crunta pentru orice elev 
Dar random shot in the dark, cred că o carte de programare care să facă respectiva persoana interesata de software dev ca atare e mai buna pentru un elev de clasa a IX-a. O carte din seria “Learn $language the hard way” poate? Sau “Why’s poignant guide to Ruby”. Sau ceva mai nou de JavaScript.
Cărțile de “limbaj”, mai ales despre un limbaj uriaș și urat că C++ modern sunt opusul la asta (chiar daca școlile noastre insistă cu el).
Profa mea de info era nebuna dupa el
Mi se pare contraproductiv trendul ăsta contra C/C++, toată lumea descurajează pe toată lumea să mai înveţe C/C++. E ca şi cum ai recomanda ca arhitecţii să nu mai înveţe cum se fac cărămizile deorece
găseşti cărămizi gata făcute la Dedeman. Şi după ce mor aia care fac cărămizi şi le vând la Dedeman ce se va întâmpla?
C/C++ sunt fundaţia lumii electronice de astăzi, cum ar fi ca în 20 de ani nimeni să nu mai ştie să repare şi să întreţină această fundaţie?
Ooookey. Nu greșești cu ce zici in linii mari, dar e o extrapolare destul de mare de la ce am zis eu la ce ai concluzionat tu 
Reiterez, ca sa fie mai clar - nu recomand că un elev de clasa a IX-a sa se bage pe C++ - nici la nivel de cunoscut, daremite la nivel de “biblie”. E momentul să învețe “programming - the good parts” si sa devină pasionat de subiect. Are timp mai încolo sa sape și să învețe și măruntaiele și părțile nașpa și părțile periculoase. Nu eu fac programa de liceu, așa că rămân oamenii cu algoritmi și C++ 
Cred ca e bine de evitat idiomul “C/C++”. Sunt doua limbaje separate până la urmă și în versiunile mai noi de C și C++ nu mai exista nici măcar acea backwards compatibility - sunt programe C pe care un compilator C++ nu le accepta.
C sunt 100% de părere că trebuie cunoscut de orice programator. E latina domeniului nostru și o sa fie mult până când e înlocuit de altceva (deși Rust incepe sa facă niște avansuri considerabile). Când zici că C/C++ e de baza, 90% cred că te referi la C. C++ oricum nu a prea fost mult prin sisteme de operare, sau software-ul de sistem á la GNU. Acolo era C-ul de baza.
C++ on the other hand - stay away from that sh*t. Daca vrei sa lucrezi in “frontend” la jocuri, unele probleme din finance, unele sisteme embedded, unele sisteme legacy de prin FAANG-uri, etc atunci sigur, go for it și asuma-l ca un cost of doing business. Deși poți lucra bine-merci in aceste domenii și fără C++. Altfel e un limbaj urât (destul de verbose, separarea declarare/implementaree aiurea, digraphs&trigraphs (look it up, dar nu mă înjură după)) , cu multe design issues (templates, preprocessor, namespaces), multe lipsuri (module, sistem de pachete, sistem de build, librărie “standard” (hai poate boost prin zonă), excepții ca mecanism de flow control acceptat, etc). A mai evoluat ce-i drept - dar slabe șanse că să fie adoptate în codebase-urile mai vechi toate bunătățile noi. Dar aici mi se pare că ajungem la aceiași justificare că și pentru COBOL - not great in my book.
IDK, câteodată cred că e doar despre cat de “hardcore” zice lumea că e un limbaj, și nu despre cum e in sine, ce probleme te ajuta sa rezolvi, ce perspective îți deschide, etc
Eu zic ca nu exista motiv pentru a folosi o carte pentru C++. Iti trebuie doua monitoare: unul pe care deschizi referinta si un alt monitor pe care sa faci ceva curs/proiect de facultate si esti bun de invatat.
La noi in laborator aveam carti despre C/C++/Delphi/Pascal si stateau degeaba, profesorul il lua pe cel de Pascal daca a uitat ceva. In rest chiar si in carte era o pagina pe care scria ceva de genul “You can’t learn programming from this book”
In 99 cartile erau mult mai utile fiindca nu aveai internet, nu aveai doua monitoare la pret de nimic si aveai exemple foarte interesante direct in Turbo C++/Pascal.
Cred că ar fi mai util/interesant ceva care să nu se focuseze pe limbaj așa tare, ci pe a construi ceva, iar C++ să fie doar un detaliu. Pe moment nu am așa ceva, și sincer nu știu dacă C++ e limbajul cel mai potrivit pentru chestii de genul, dar ziceam ca idee. C++ e ditamai limbajul, ca să ajungi la cel mai mic detaliu nu prea poți decât citind din standard, care nu e ceva ce aș considera „fun”. C++ e plin de chichițe. Totuși, cea mai apropiată carte de ce ai vrea tu consider că este: Stroustrup: A Tour of C++ (Second edition)
Templates și namespaces de ce ar fi un design issue? Preprocesorul e inclus în limbaj pentru a fi backwards-compatible cu C.
Acum are și module. Package managers are (de exemplu vcpkg sau conan), problema e că nu e niciunul standard. Build systems cu siguranță are, și deși nu e oficial, CMake cam e un fel de standard pentru build systems pentru C++. Bibliotecă standard cu siguranță are, toate compilatoarele majore vin la pachet cu implementări pentru ea.
Sper că nu folosește nimeni excepțiile ca și mecanism de control flow în C++. Credeam că e destul de cunoscut că e o practică descurajată, cel puțin în C++. Singurul limbaj mai popular pe care-l știu care să încurajeze excepțiile ca și mecanism de control flow e python. Din ce știu eu excepțiile, în mod normal, trebuie folosite doar pentru atât, cazuri excepționale.
Punctele mele sunt daca vrei prin aspectul de “ergonomie” a limbajului. Sure, C++ are “toate feature-urile”, dar asta nu inseamna ca are un design inspirat pentru ele, sau ca sunt chiar niste treburi utile. Partea de design in orice activitate presupune si o munca de “ce sa nu faci”. C++ didn’t get the memo.
Templates sunt IMO mult prea puternice pe de-o parte si mult prea convoluted pe de alta parte. AFAIK toata treaba este Turing-complete deci ai mega putere. Dar sunt metode mai dragute si mai limitate de a obtine parametric polymorphism. Faptul ca fiecare instantiere genereaza si cod obiect separat aduga mult la binary size & bloat (sau asa era pe vremea mea).
Namespaces sunt fie module pe jumatate. Ai o separare de naming, dar nu mai mult. Sintaxa e urata de asemenea.
namespace myproject {
namespace repository {
namespace users {
... my code
}
}
}
Arata ciudat rau.
Ditto, inteleg de ce e preprocesorul acolo. Doesn’t make it a good idea. Ditto #ifdef-urile si celelalte. Sunt hack-uri peste hack-uri pana la urma.
Acum are și module. Package managers are (de exemplu vcpkg sau conan), problema e că nu e niciunul standard. Build systems cu siguranță are, și deși nu e oficial, CMake cam e un fel de standard pentru build systems pentru C++. Bibliotecă standard cu siguranță are, toate compilatoarele majore vin la pachet cu implementări pentru ea.
True, C++20 are module. Your company’s mission critical 20 years old codebase written in C++03 won’t be using them 
C++ modern are si type-inference, lambdas, si cateva goodies care fac viata usoara. Nu-i totul rau pe partea asta de ergonomie.
Nah, mai e si Blaze ca build systems, si cu siguranta ca sunt package managers. Dar nu exista PyPI, CPAN, npm, sau prietenii. Limbajul este o unealta pana la urma, si trebuie evaluat si vis-a-vis de intreg ecosistemul sau.
Librarie standard e for sure, dar e foarte slim. Cum mentionam e si boost prin zona care ajuta. Dar comparat cu Java, Python, Go, etc care vin cu batteries included, sau au un mecanism usor de a aduce cod extern, e destul de slim.
Sper că nu folosește nimeni excepțiile ca și mecanism de control flow în C++. Credeam că e destul de cunoscut că e o practică descurajată, cel puțin în C++. Singurul limbaj mai popular pe care-l știu care să încurajeze excepțiile ca și mecanism de control flow e python. Din ce știu eu excepțiile, în mod normal, trebuie folosite doar pentru atât, cazuri excepționale.
Relatia C++ cu exceptiile e … complicata. Sunt acolo ca feature de limbaj, dar multa lume le evita, si cateva companii chiar resping in totalitate folosirea lor. Intre timp “$everyOtherLanguage” foloseste exceptiile bine-merci 
- Python, Java, C#, PHP, JavaScript, etc.
In sfârșit, cred ca e o chestie de gust. Dacă-ți place C++ go for it. Joburi sunt. Dar dupa capul meu, daca nu e absolut nevoie, nu m-aș atinge
Să nu mă înțelegi greșit, sunt primul care să accepte că C++ e groaznic ca limbaj (mult prea complex) 
Aici e cu dus și întors. E adevărat, dar ăsta e cam singurul mod prin care să aibă generics fără overhead la runtime.
Ah, înțeleg acum, te refereai la mărime.
Credeam că ne referim strict la excepții ca și mecanism de control flow. Nici în Java/C#/JS nu cred că e recomandat ca excepțiile să fie folosite așa.
Majoritatea problemelor C++ vin din compatibilitatea cu C-ul, dar fără asta n-ar mai fi fost C++… E un fel de cerc vicios. Dar limbajul mai are și probleme care nu țin numai de asta. IMO o problemă mare e cu comitetul care decide ce intră în limbaj, stau o grămadă de ani pe niște features care sunt deja de mult timp în alte limbaje, ca apoi să le introducă în C++ și tot half-assed sunt (exemplu: ranges).
Faza e că nu te obligă nimeni să folosești toate feature-urile ciudate din C++. Eu îl folosesc mai degrabă ca pe un fel de “C pe steroizi”, și am observat că destulă lume îl privește și folosește tot așa.
De exemplu, acum câteva zile m-am apucat să fac în C++ un client de XMPP (cu gloox și wxWidgets, pe care nu le-am folosit înainte) și în surprinzător de scurt timp am avut o variantă minimă funcțională, 100% non-blocking event driven, cu minimizare în tray și comunicare cu window manager-ul din Linux să-mi aducă roster-ul in virtual desktop-ul curent (aici a fost ceva mai complicat, că am lucrat cu xlib foarte puțin și a trebuit să înțeleg cum să folosesc specificațiile NetWM).
Nu mi s-a părut nicio secundă că aș fi fost mai productiv cu alt limbaj, mai degrabă un limbaj non-C++ ar fi venit cu layere în plus pentru a pupa toate tehnologiile eterogene de care a fost nevoie.
Eu aș fi în stare să folosesc C++ doar ca C + strings + compile-time things. A trebuit odată să folosesc C pentru o chestie la care nu era nevoie de C (nu că C++ ar fi fost perfect, dar măcar aveam std::string), iar la code review pierdeam vremea numai la chestii legate de ownership de char*. Atunci am simțit cu adevărat lipsa unui std::string. Povestea cu string-urile din C e un coșmar. Și în general, în C++ e mai ușor să impui niște reguli de ownership pentru lucruri, nu numai strings.
Exemplul tău e perfect pentru C++, sunt puține limbajele în care e așa ușor să dezvolți un GUI nativ pe desktop. Nici măcar C nu stă așa bine, și e funny că îl ai până și pe Torvalds care și-a convertit SubSurface de la GTK la Qt.
Dacă ai probleme cu viteza de compilare, precompiled headers ajută enorm. Bagi acolo headerele pe care le folosești frecvent și compilarea devine cvasi-instantanee. Combinat cu ccache, inclusiv rebuild-urile masive se vor realiza incredibil de rapid.
LE: Apropo de string-uri, eu mi-am făcut propria clasă de string-uri, mult mai completă decât std::string (cu suport pt Unicode, de exemplu să funcționeze corect uppercase/lowercase chiar dacă am diacritice în string), exact să pot folosi C++ în loc de C, inițial cu zero STL (mai târziu am bagat în ea std::vector, ca mi-a fost lene să implementez o clasă pentru vectori).
Folosesc ccache și precompiled headers mereu, sunt utile. Oricum, problema cu timpul de compilare lung nu e numai la C++, cam orice limbaj care folosește monomorphization suferă de asta. Și știu că nu despre asta e topicul, dar foarte utile sunt și sanitizers, clang-format și clang-tidy.
De menționat că wchar_t mai rău te încurcă dacă vrei să suporți și windows. Îți recomand char32_t ca să fii sigur că folosește 4 bytes pentru un code-point. Evident, ca să fii sigur că ai suport bun pentru unicode atunci recomand ICU (dar poate e o dependință prea mare și ai testat deja clasa ta și funcționează pentru use case-ul tău).
Pentru windows folosesc crosscompilarea cu mingw, probabil mă pot baza e cam la fel treaba cu wchar_t (că e tot gcc), cel puțin n-am avut probleme până acum. ICU e prea mare, și oricum ideea era să am zero dependențe, pe mine mă interesa strict chestia lower()/upper() pentru diacritice, cu tabelele de lookup pare să funcționeze rezonabil de corect.
Înțeleg. ICU era worth it dacă aveai nevoie de suport calumea pentru unicode, dar dacă doar de lower/upper pentru diacritice ai nevoie atunci de acord, n-ai de ce să aduci ICU doar pentru asta. Dar tot aș alege char32_t peste wchar_t 
Din păcate C++ și Unicode sunt ca uleiul și apa.