Incearca sa instalezi o librarie din 2005 la un proiect nou, o sa iti schimbi si kernelul sa il faci sa ruleze degeaba ai apt. Am avut de multe ori probleme cu apt pe ubuntu/debian tocmai din cauza asta, am schimbat ceva librarie si s-a dus naibi tot sistemul de operare.
Cred că tu faci confuzie între compilator și bibliotecile cu care este linkeditat binarul tău (între noi fie vorba, nu te oprește nimeni să linkezi static binarul și obții zero dependențe). Un cod C++ scris corect în 1998 se va compila perfect cu ultimul răcnet de compilator din 2022.
Și chiar dacă ar fi cum zici tu, în ziua de azi oricum rulezi toate aplicațiile web în containere. Livrezi aplicația web sub formă de container și cu asta basta.
La o aplicație mai complexă care face multă matematică (jocuri), glu, directx se văd diferențele între operatori și tipurile de date. Trebuie să folosești flag-uri să faci un compilator mai nou să calculeze ca unul vechi.
Vorbeam de webapp. Dacă e vorba de performanță, indiferent cât de prost ar performa o aplicație scrisă în C++, tot va performa mai bine decât în orice alt limbaj de nivel înalt.
O biblioteca din 2005 ma astept sa fie compilabila azi folosind clasicul ./configure && make && make install, eventual instalata intr-o locatie separata daca vreau s-o izolez.
*Dacă nu are dependințe care depind de ceva din kernel.
La un webapp nu vei avea problema, sau o vei avea, vezi ImageMagick, n-a fost fun nici cu php.
1 Like
Asta e valabil în orice limbaj, nu are legătura cu C++.
M-as intreba de multe ori de ce as avea nevoie de o biblioteca ce depinde de detaliile kernelului din 2005 in loc de vreun API standardizat.
In C ai nevoie mereu de headere din kernel, e.g sys/socket.h, epoll_ctl(2) - Linux manual page - care te blocheaza sa folosesti ceva sub linux 2.6.9 cu un glibc curent.
API-ul standardizat de care vorbesti a fost scos abia in 2008: Linux and glibc API changes
Chiar si asa, un mic extras:
- With the exception of 32-bit and 64-bit Intel architectures, the minimum kernel versions required for glibc 2.24 is Linux 3.2. For intel architectures, the minimum kernel version is 2.6.32.
- For reasons explained in the readdir_r(3) man page, the readdir_r() function has been deprecated. Instead, readdir(3) should be used. For further information, see Austin Group bug report 696 and this glibc bug report.
In C++ poti avea ceva fatada, dar dupa iti plange libraria de ce s-ar plange C. Daca te uiti la extrasul de mai sus, practic e vorba de readdir, orice aplicatie care citeste un fisier foloseste readdir.
Cred ca eu sunt singurul care a incercat sa scrie programe de grafica, interfete in C++, wxwidgets si mi-am batut capul de pereti pana am gasit compilerul sau flag-urile sa nu imi fie imaginea cu susul in jos sau sa imi apara un buton. Daca i-ai trimis profesorului acelasi cod el iti zicea ca lui ii merge bine.
Eu produc din 2009 un program de facturare. Este disponibil pentru toate sistemele de operare desktop majore (Linux Fedora/Centos, Linux Debian/Ubuntu, OS X, Windows 32 bit, Windows 64 bit).
Stii care e procedura de release? “cd pkg; make all” si in 5 minute mi-a scuipat toate binarele (inclusiv cele de Win si Mac, cross-compilate). Pe Linux singura problema e ca daca l-am compilat pentru Centos 7, nu o sa functioneze pe Centos 6 (dar cine mai foloseste o versiune atat de veche pe desktop?).
Utilizatori sunt probabil peste 20.000. Știi cate bugreporturi am primit legat de incompatibilitati cu OS-ul sau bibliotecile? Cam… zero. Bugreport-uri legate de crash-uri din motive de buffer overflow? Cred că una sau două, în anumite edgecase-uri foarte specifice. În peste 10 ani.
So… există scenarii în care C++ poate o unealtă excelentă, cu condiția să-i cunoști finețurile. Dar asta-i valabil pentru orice alt limbaj/ecosistem, right?
2 Likes
sys/socket.h face parte din POSIX, de exemplu astea le gaseai in versiunea din 1997. epoll e Linux specific. Daca pui un boost::asio peste profiti de implementarea lor sub diverse sisteme de operare fara sa-ti bati capul cu detalii.
Pentru iterat prin directoare ofera C++17 un API. Treaba lor sa-l tina actual sub diverse sisteme de operare.
Pentru tine.
DLLuri descarcate random?
Cam o dai in SFuri pe-acolo.
Acum nu, dar in trecut cel putin pe Windows inainte sa stiu de Linux descarcam dll-uri pana nimeream unul care merge. Nu cred ca am incercat sa fac ceva ce era 100% open-source, mai nimic nu era. (jocuri/plugin-uri) Am facut scripting cu C++, smalltalk, lua si cand mergea era bine. Am avut multe probleme cu compilatul, e.g. pe windows mergea si dupa pe linux nu mergea acelasi script.
Github nu exista, fiecare isi tinea sursele/dll-urile pe site-ul/forumul lui. Pe linux aveai repository-uri, dar mai nimeni nu folosea Linux.
Din 2008 si C++ are tooling mai modern, dar problemele raman, am folosit Qt zilele astea si e mult mai complicat decat ce primesti cu IntelliJ si Java cu gradle sau Visual Studio si C# cu nuget. Qt inca e un framework platit si scump. Boost n-am folosit niciodata, deci nu pot sa comentez.
cppreference.com - multe chestii noi in C++11 si mai sus, care nu existau.
@serghei O data ce ai proiectul si nu adaugi librarii nu cred ca vei avea probleme, depinde mult ce dependinte ai. Eu folosesc make inclusiv cu js si docker, e mai flexibil. Dar daca intram in makefile-ul ala sa vedem comenzile date sigur folosesti ceva cross compiler sau arata atat de urat incat nici tu nu mai intelegi ce-i acolo.
Tu tot povestesti de problemele pe care le-ai avut tu, dar nu generaliza de la tine.
Posibil. In toate limbajele de programare dureaza la fel de mult sa astepti dupa IO (baza de date, alt serviciu, etc.). Majoriteatea webapps cu asta se ocupa. 
1 Like
Dacă nu faci niciun fel de caching, probabil. Sure, există memcache, dar cumva mi se pare mult mai simplu și mai eficient să faci caching direct în spatiul de memorie al aplicatiei. Dacă ai și acces nemijlocit la acea memorie, footprint-ul și overhead-ul poate fi redus drastic.
Plus că există posibilitatea de scriere in db asincronă, care nu-mi imaginez cum s-ar putea face în php de exemplu.
Apar subtilitati si aici. De exemplu astepti in paralel dupa mai multe cereri IO sau pe rand. Sau aloci cate un thread pentru fiecare client VS solutii mai eficiente.
Ceva procesare apare apoi inevitabil prin cod. De exemplu aici se plange ca are nevoie de 4 GB RAM si ceva CPU pentru a procesa 30 MB de text: javascript - High CPU and memory usage iterating over 300K objects - Code Review Stack Exchange
In alte limbaje ar fi o banalitate.
Caching, async/await, event-based processing a la epoll/kqueue, threads vs processes, across, etc sunt concepte oarecum ortogonale cu “performanta” limbajului pe CPU-bound work. Sigur, unele limbaje se insoara cu o paradigma si atunci ai probleme cand se schimba.
A mai fost si Silverlight, Flashul de la Microsoft care a murit foarte repede - apucasem sa fac ceva in el si s-a dus…
Dacă PHP (sau un limbaj echivalent) nu ar fi existat, probabil că web-ul n-ar fi fost ce e azi.
Nu mă înțelegeți greșit, consider că PHP e o mizerie de limbaj care ar trebui dus pe o stradă lăturalnică unde să i se curme rapid suferința, dar acum vreo 20+ ani a fost absolut revoluționar și tot ce avem azi se datorează direct sau indirect faptului că un tip s-a gândit să facă un limbaj în care e ușor de făcut site-uri dinamice.
3 Likes