Toti cred ca ati auzit de StackOverflow dar poate nu toti sunteti familiari cu fratele sau mai mic https://codereview.stackexchange.com/. Aici lumea aduce cod functional scris de ei alaturi de o descriere a ce rezolva acel cod si primeste sfaturi despre cum sa-l imbunatateasca.
E mai mult pentru cei mai la inceput de drum dar poate fi de folos si celor experimentati pentru a:
Vedea cum gandesc incepatorii si ce greseli repeta.
Exersa formularea unor raspunsuri cat mai potrivite.
Cateva exemple recente:
Incepator in accesarea bazelor de date din Java
Cate probleme identificati aici? (Hint: sunt multe)
A reinventat roata si a iesit mai rapida (sau asa crede)
Chestia cu much faster than a std::string este chiar amuzanta. Nu inteleg ce a crezut ca e special avand in vedere ca o implementatie mai simpla de atat nu avea cum sa faca.
Adica un string mai mai basic de atat nu ai cum:
struct {
// data
char *src = nullptr; // pointer to character array wich contains to value of object
size_t len = 0; // length of src, zero means empty
size_t siz = 0; // size of src in heap memory
};
Problema cu std::string este ca te compari cu o anume implementatie de std::string. Adica MSVC o implementeaza intr-un fel, GCC (libstdc++) in alt fel, Clang (libc++) si tot asa.
Majoritatea implementeaza o forma sau alta de SSO (Small String Optimization) in ultimul timp. In special de cand sa introdus std::string_view si std::span.
Si in functie de utilizare, o implementatie cu SSO ofera o performanta mai buna.
Am trecut si eu prin faza in care crezi ca std::string e un bottleneck. Mare greseala sa ai mentalitatea aia.
O performanta mai buna se obtine din utilizarea std::string_view si std::span si move semantics unde este cazul. Adica trebuie sa eviti alocarea de memorie heap cat mai mult. Sa obtii lucrul asta trebuie sa implementezi SSO. Dar asta vine cu alta problema. Creste marimea obiectului initial. Care te penalizeaza cand vrei sa il transferi sau sa il trimiti ca si argument. Pentru ca trebuie sa il dai ca si referinta la argumente. Deci se adauga inca o indirectie la pointerul actual catre bufferul cu string. Plus ca te penalizeaza destul de bine la move semantics. Aici intervine std::string_view si std::span care sun obiecte usor de copiat si care ofera o flexibilitate mult mai mare la un cost mult mai mic.
Sper sa realizeze eventual greseala pe care o face
