Clasicul si modernul C++ - cine e interesat?

Din pacate (sau din fericire) nu exista nici un clasic si modern C++, exista doar C++. Si C++ nu-ti impune nimic, este si C cu clase si C cu cin si cout, este si C++ "modern". Programarea in C++ nu este mai usoara ca acum 20 de ani, dimpotriva. Nu ajunge sa te apuci acum de C++ si sa-l inveti "modern", pentru ca daca o sa lucrezi in lumea reala o sa lucrezi cu siguranta pe cod scris de altii, cum au avut chef sau cum era posibil.

Cind intr-un limbaj poti face acelasi lucru in 57 de feluri, deja se impute treaba. Chestia asta se intimpla si in Java...

Cit despre ora-om si ora-masina, daca limbajul este foarte complicat gasesti foarte greu oameni care sa-l exploateze la maximum. Asa ca daca te hotarasti sa folosesti limbajul ala probabil o sa trebuiasca sa te multumesti si unii mai mediocrii, care o n-o sa faca mare brinza cu ora-masina, deci o sa iti creasca ora-om si ora-masina o sa fie vai de mama ei

Mai mult, cu cit se schimba mai des limbajul, cu atita e mai greu sa tii pasul. In afara de aia care traiesc pentru programare si care sint o minoritate, majoritatea programatorilor au o viata, care nu le permite sa urmareasca non stop ce mai schimba aia, mai ales daca-s niste schimbari care nu aduc nimic spectaculos, doar rezolva tot felul de probleme de nisa, care oricum se pot rezolva altfel, la fel de eficient.

Ca idee despre complexitatea C++, de exemplu constexpr de mai sus

https://en.cpprefere...guage/constexpr

Deci practic ca sa fii prolific in C++ cind folosesti constexpr, trebuie sa stii toate chestiile alea. Daca nu stii ce scrie acolo, atunci probabil o sa-ti crape la compilare sau n-o sa obtii tocmai ce crezi, caz in care te duci si citesti chestiile alea. Doar ca n-o sa le tii niciodata minte, decit pentru cazul tau specific. Cind o sa vrei sa faci altceva, din nou te ia dracu si te intorci la citit. Asta e doar una bucata keyword.

Holy shit.

C++ vine din mediul academic, java sau alte limbaje vin din mediul de productie unde sa fac bani.

NaeCicolae, on 13 aprilie 2019 - 06:23, said:

Va rog eu mult, cand nu stiti ceva intrebati - si vom incerca sa gasim un raspuns.
Pentru ca presupunerea de mai sus este complet, absolut, iremediabil gresita!

C++ a fost dezvoltat de Bjarne Stroustrup, in cadrul AT&T, pentru a rezolva problema foarte reala a inexistentei unui limbaj care sa combine mecanisme de abstractizare (precum cele din Simula) cu apropierea de hardware si performanta (oferite de C). Bjarne lucra la un simulator distribuit, dimensiunea proiectului cerea mecanisme de abstractizare insa Simula pur si simplu nu facea fata.
Mai productie de-atat nu se poate!

Chiar si in prezent, cine e implicat in dezvoltarea si evolutia limbajului? Academii? Nici gand; ci companii precum Microsoft, Google, Facebook, Qt etc. - industria software, care va sa zica. Dezvoltatorii software; si da, oricine poate propune noi imbunatatiri - asta daca il tin curelele.

Nu vei gasi un limbaj mai "din mediul de productie" decat C++!

Este, Golang 🤓

Mosotti, on 13 aprilie 2019 - 06:21, said:

constexpr e chiar banal ca rar te apuci sa calculezi at compile time lucruri mai complicate de niste operatii matematice simple. constexpr if iar e banal dar foarte util: ai o functie generica si vrei sa executi un if doar daca tipul T de exemplu e numar cu semn.

Teme complexe, "de speriat" ar fi mai degraba:

• Argument-dependent lookup
  
• Perfect forwarding
  
• Memory model - asta-i intalnit in mai toate limbajele, eventual cu alte reguli.

Quote

In productie in Romania, sau cum?

Eu lucrez in momentul de fata pe doua proiecte foarte diferite, unul e pe IoT, celalalt e pentru ceva aparatura medicala. In ambele cazuri, 'productia' e C++.

In ambele cazuri, alegerea unui limbaj 'de productie' precum Java sau C# ar fi fost o greaseala fatala. Si intr-un caz s-a si intamplat, inainte de a ajunge eu sa lucrez pe proiect. Au incercat cu C#. Problema e ca trebuie prelucrate imagini de rezolutie inalta, sute de cadre pe secunda, in timp real. Nu-ti poti permite sa te loveasca garbage collectorul cand ti-e lumea mai draga si sa nu ai un control strict al memoriei folosite. Dupa ce au implementat ceva cat sa incerce sa vada ce iese, si-au dat seama ce prostie au facut si au trecut la C++. Din pacate pentru ei, n-am fost acolo de la inceput, ca le spuneam Am mai vazut istoria asta cu C# sau Java in loc de C++ de nenumarate ori.

Probabil ca e adevarat ca in Romania C++ nu e un limbaj 'de productie'. Catre noi (si indieni) se arunca munca de jos.

NaeCicolae, on 13 aprilie 2019 - 06:54, said:

Mai putina convingere si mai multe intrebari! Inteleg ca esti fan Java, insa acest topic nu e ca sa aratam care-i cel mai bun limbaj

Caci, iata, esti unul dintre cei ce nu stiu C++ - dar nu stiu nici ca nu stiu. Precum co-workerul meu cu "C++ nu are generics!".
Nimeni nu s-a nascut invatat; scopul meu este sa-ti arat ca nu cunosti limbajul, si eventual sa-ti trezesc curiozitatea in privinta acestuia.

1. Iarasi, este fix pe dos. Nu stiu ce "extensie a limbajului" ai vazut tu... asemenea lucruri nu sunt portabile.
C++ portabil inseamna C++ standard, evitand extensii ale compilatoarelor and stuff. Poti scrie o aplicatie consola complexa doar in C++ standard.
Apoi avem librarii si pachete de librarii precum Boost, care la randul lor folosesc C++ standard.
Apoi avem librarii si framework-uri disponibile pe mai multe platforme.

Ce ai fost invatat la facultate este complet gresit, iar indivizii care te-au sfatuit asa erau idioti. Idioti de doua ori daca ziceau malloc() si free(), care sunt functii C.
Crezi ca asemenea indivizi - care nu cunosc limbajul, ceva profesorasi sau asistenti la o facultate - ti-ar fi putut da sfaturi despre utilizarea C++ in industrie?
De ce nu-i intrebi pe cei din industrie? Suntem aici.

Simplificand nitel, pentru ca intotdeauna putem gasi cazuri speciale.
Nu folosesti malloc() in C++, pentru ca functia aceasta doar aloca memorie - nu apeleaza constructorii. Mai exista problema calculului manual al dimensiunii obiectului alocat (unde poti sa gresest), si conversia de tip care in C++ este necesara.
Nu folosesti insa nici new! Incepand cu C++11, managementul memoriei se face eficient si sigur prin RAII, utilizand smart pointeri - unique_ptr si shared_ptr. Avantajul enorm este ca nu te mai preocupa dealocarea, realizata automat cand smart pointerii ies din scop. Indiferent cum ies din scop - return, exceptie.
Iata un exemplu simplu:

auto a = std::make_unique<int>(42);

Voi discuta si despre auto. Codul de mai sus aloca dinamic un int, il initializeaza cu o valoare (42) si impacheteaza totul intr-un smart pointer - indiferent cum se iese din scopul respectiv, memoria va fi dealocata corespunzator, automat.
Atentie pentru fanii Java: in C++, de foarte multe ori variabilele pot/vor fi alocate pe stiva. De alfel e foarte usor sa recunosti un programator Java incercand sa scrie "C++": new pentru orice variabila, si nici macar un delete

Apoi, abstractizarea - C++ a fost conceput pentru includerea unor mecanisme de abstractizare Simula-like intr-un limbaj performant precum C.
Si vine neica nimeni sa spuna ca nu, el nu vrea abstractizare, el vrea sa vada malloc() si free()?
In industrie, faptul ca (exemple banale) vector si string isi au grija de memorie reprezinta un avantaj extraordinar. Pai, in loc sa scrii totul de mana, sa calculezi dimensiuni de buffere, adrese si inevitabil sa gresesti, ai o librarie solida, testata si care pur si simplu functioneaza!

Spuneai de auto type-casting in Java care nu-i altceva decat un set de conversii implicite. Boooriiing!
Desigur, exista asa ceva si in C (da, C, de unde-au fost preluate in C++).

O sa-ti arat ceva mai bun: automatic type deduction in C++. De fapt, ti-am aratat... acel auto din codul de mai sus.
Desigur, se poate specifica tipul variabilei:

std::unique_ptr<int> a = std::make_unique<int>(42);

a fiind, desigur, un smart pointer.
Oameni destepti s-au gandit, compilatorul stie deja tipul variabilei a - este ceea ce returneaza make_unique<int>; de ce sa fortam programatorul sa il scrie?
Asa ca scriem 'auto' si de restul are grija compilatorul.

Exemplul de mai sus este unul banal, care doar te scuteste de-a scrie niste constructii sintactice destul de urate.
Insa 'auto' poate mult mai mult de-atat, punand bazele unui nou tip de programare generica.

auto size = [](const auto& m) { return m.size(); };

Codul de mai sus reprezinta o lambda generica. Ai lambda si in Java, introdus cand noi in C++ ne-am plictisit de ele si-am inceput sa ne gandim cum sa le folosim mai bine
Nu trebuie sa scrii tipul variabilei size; va fi dedus de compilator.
Nu trebuie sa scrii tipul lui m; lambda va accepta orice m care are un membru size. Poate fi string, poate fi vector, poate fi YourTypeWithASizeMember.
Apelul? size(x).

Un exemplu frumos, cu dedicatie pentru fanii Python: structured bindings. Introdus in C++17, pentru ca, asa cum spuneam, limbajul evolueaza.
Una din chestiile interesante in Python este modul in care functiile pot returna mai multe valori.
Putem face asta si in C++? Desigur; acum insa este mai usor ca niciodata. Poti sa returnezi pointeri catre structuri, bla bla bla, daca ai ramas la C++98. Suntem in 2019, si C++17 deja e old news.

auto func()
{
int a{ 42 };
double b{ 42.0 };
return std::tie(a, b);
}

func() returneaza o pereche (pair) de int si double (de la trei in sus vorbim de tuplu). Tipul de return al functiei este auto dedus. Ah, si-n caz ca nu este clar, asta functioneaza bine-mersi cu tipuri definite de utilizator.
Partea frumoasa - pentru ca v-am promis - este despachetarea acestui pair (sau tuple), caci apelantul vrea sa acceseze a si b, pentru asta a apelat func(). Nu poate fi usor ca in Python, asa-i? Vorbim de C++ aici, musai sa fie o chestie urata si complicata. Iat-o:

auto [a, b] = func();

Variabilele a si b au tipurile corespunzatoare, deduse de compilator. Mai mult - si spre deosebire de Pyton - o greseala, sa zicem o variabila in plus/minus, va fi detectata la compilare.

Cei 3 care au votat "C++ evolueaza?" la ultima intrebare, ce ziceti, va revizuiti votul?

ovipic, on 13 aprilie 2019 - 10:32, said:

Golang nu este "mai de productie" decat C++. Ba as spune ca Golang a fost oarecum impus politic de catre Google - desi, iata, Google sustine si C++.
Nu exista "mai de productie" decat un limbaj realizat si dezvoltat pentru solutionarea unor probleme reale, de catre dezvoltatorii software.

dani.user, on 13 aprilie 2019 - 10:37, said:

Provocarea mea pentru Mosotti e sa-mi arate cum rezolva un alt limbaj aceeasi problema - compile time computation - mai simplu decat C++. Cu paginile de documentatie aferente.

constexpr if este iarasi o alternativa faina la o chestie care pana acum era urata rau (brrr... SFINAE).
Deocamdata ignor topicurile de speriat, pentru ca nu vreau sa sperii pe nimeni Va garantez, scrierea de librarii in C++ e partea complicata; ca utilizatori de librarii viata va e mai usoara ca niciodata. Na, ca fac si rime.

Quote

Te rog frumos sa lasi aberatiile de tipul asta. Care parte din 'in timp real' n-ai inteles-o? Pana ajung imaginile de la device la cluster, deja sunt prelucrate pe un banal PC. La un pret incomparabil mai mic. Habar nu ai despre ce e vorba, dar arunci cu TB si sute de procesoare, cand dispozitivul e portabil si utilizabil si unde n-ai acces la net. Sute de cadre pe secunda, rezolutie mare, transferate la cluster. Nu vreau ce fumezi tu pe acolo.

Edited by parabellum, 13 April 2019 - 13:03.

Depinde de imagine si de ce fel de procesare vorbim totusi.

Avantajul cel mai mare al lui C++ e si cel mai mare dezavantaj: e vechi, are multe chichite, are multe peticeli adaugate recent pentru a imbunatati situatia - dar nu are metode clare de eliminare a metodelor vechi, ceea ce inseamna ca trebuie sa te bazezi pe educatie, iar asta nu e usoara cu un limbaj asa vechi. Un incepator trebuie sa stie atat C++-ul modern, cat si pe cel vechi, ca sa stie de ce sa se fereasca si cum sa imbunatateasca un cod.

Compara asta cu alte limbaje unde planuri de depreciere a codului vechi sunt integrate direct in compilator/interpretor, care iti da pentru o perioada de cativa ani o avertizare, si apoi o eroare, cand detecteaza cod vechi.

Exista o duzina de metode de a face acelasi lucru, multe dintre ele la fel de optime - deci limbajul nu are concepte ortogonale.

NaeCicolae, on 13 aprilie 2019 - 13:14, said:

Da. Mai pe si mai scurt: sclavi. Romania e o tara de sclavi.

Dar noi nu vorbim aici despre Romania, ci despre limbaj.

@NaeCicolae:
Depasesti orice limita, prin agresivitatea si limbajul folosit.
Avem preferinte diferite, lucram la proiecte diferite, dar ne respectam ca niste profesionisti, OK?

Realizezi ca unul din avantajele enumerate chiar de tine ale platformei JVM, si anume "write once run anywhere", este complet irelevanta in contextul acestei aplicatii de imagistica medicala? Parabellum poate sa confirme, dar din cate vad aplicatia va rula pe hardware specific, posibil si certificat.

O intrebare: pe cate platforme ruleaza efectiv aplicatia la care lucrezi? Cea la care lucrez eu, pe vreo 5, si asta nu bate nici un record. 95+% cod portabil, cu cateva module dependente de platforma.
Si toate modulele platform-specific ar fi eliminate, daca s-ar accepta rescrierea folosind un standard mai actual.

OriginalCopy, on 13 aprilie 2019 - 13:23, said:

Depreciere se intampla si in C++, insa nu la o scara prea mare. Primul exemplu ce-mi vine in minte e: https://en.cpprefere...memory/auto_ptr

Avertizarile oferite de compilatoare ajuta si ele; personal prefer chiar sa activez tratarea avertizarilor drept erori de compilare.

Cam ce elemente ale limbajului credeti ca ar trebui eliminate? Folosirea new/delete nu poate fi restrictionata (uneori nu ai de ales). Apelul malloc/free, iar nu ar putea fi interzis.

Edited by dani.user, 13 April 2019 - 13:49.

OriginalCopy, on 13 aprilie 2019 - 13:23, said:

C++ a fost dezvoltat conform cerintelor din industria software, iar una dintre acestea a fost: "codul existent trebuie sa mearga in continuare!".
Rezultatul e un limbaj mai urat decat ar fi putut fi, un limbaj utilitar mai degraba decat urmarind o frumusete academica. Si totusi... spune-mi ca structured bindings nu e o solutie eleganta!

Foarte relevanta observatia ta despre educatie, de altfel si acest topic isi propune sa starneasca o curiozitate catre acest subiect, al educatiei.
Avem documentatie excelenta, trebuie doar popularizata - la gunoi cu Herbert Schildt, avem autori precum Bjarne Stroustrup, Sutter, Meyers, site-uri, bloguri...

Si avem analiza statica de cod. De unele chestii te avertizeaza compilatorul; mai nou, IDE-ul a inceput sa ma sfatuiasca sa pun noexcept daca functia nu arunca exceptii, sa nu aloc dinamic memoria daca nu e cazul, samd. Apoi mai exista pasi suplimentari de analiza, lintere, chestii.
Avem si C++ Core Guidelines:
https://github.com/i...pCoreGuidelines

In loc de versionare - care nu are sens in C++ - esti indrumat catre urmarea unor bune practici.

TS030, on 13 aprilie 2019 - 11:50, said:

Raspunsul este foarte simplu: nu am nevoie de compile time computation. Never had, never will. Practic rezolva o problema pe care imensa majoritate a oamenilor n-au intilnit-o niciodata. Da-mi niste exemple din lumea reala, nu prostii de Fibonacci, in care inainte de a exista acest feature programul tau suferea groaznic la performanta pentru ca nu putea face calcule la compilare.

dani.user, on 13 aprilie 2019 - 10:37, said:

Nu e nimic banal acolo, sint citeva zeci de rinduri cu zeci de reguli. Daca as lua la puricat pe unu care pretinde ca "stie" C++, doar din pagina aia, ar iesi un dezastru. E banal pentru ca te gindesti doar in contextul in care l-ai folosit tu.

C++ este un limbaj atit de complicat incit sint sigur ca nu-l cunoaste nimeni la modul sa-ti spuna orice fara sa se uite prin standarde. Apoi mai e si problema de implementare a acelor complicatii in diversele compilatoare, ceea ce duce la probleme de portabilitate.

Practic orice firma serioasa care foloseste C++ are propriile reguli prin care isi seteaza un subset de limbaj si la restu ii da cu flita (nu folosi aia, aia si aia, foloseste aia doar in caz ca, daca nu foaie verde trishpe). Ca exemplu iti citez la nimereala din regulile de la Google:

Quote

https://google.githu...e/cppguide.html

Practic multe dintre ele sint oarecum ambigue si sint sigur ca se distreaza de minune la code review...

Mosotti, on 13 aprilie 2019 - 13:59, said:

In C++11 cand a aparut constexpr era foarte limitat. Nu puteai folosi if, asa ca aveai ?: peste tot. Ulterior s-au relaxat regulile putand folosi tot mai multe facilitati.

Nu te obliga nimeni sa le stii pe toate, da eroare compilatorul daca folosesti ceva interzis:

 Untitled.png   29.97K   17 downloads

Cel mai adesea l-am folosit pentru a calcula dimensiunea unor vectori statici, pe stiva.

Mosotti, on 13 aprilie 2019 - 13:59, said:

Deci daca n-ai tu nevoie, nimeni nu are?

Fa diferenta dintre un exemplu didactic, si aplicabilitatea in mediul real. Ce am aratat eu e cat de simpla este aceasta facilitate a limbajului.
Un exemplu mai real ar fi static_assert. Aici nu mai e vorba de performanta, ci de corectitudinea programului.

Mosotti, on 13 aprilie 2019 - 13:59, said:

Nu trebuie sa te uiti prin standarde - sau, foarte rar trebuie sa te uiti prin standarde, ca sa clarifici niste edge case-uri, asta la nivelul de expert. Avem documentatie mult mai accesibila.
C++ este standard international, compilatoarele nu au mana libera sa-si implementeze propria versiune.

Inchis pentru curatenie.

Multumiri @NaeCicolae

DONE(ish)

Va rog din suflet sa treceti peste ce posturile sale (cand se intoarece).

Edited by MarianG, 13 April 2019 - 15:14.