Clasicul si modernul C++ - cine e interesat?

TS030, on 13 aprilie 2019 - 14:44, said:

Ti-am cerut niste exemple reale care sa te faca diferenta daca nu folosesti constexpr.

Existenta lui static_assert e doar un rezultat al cretinatatii limbajului. Doar iti umpli codul cu timpenii in loc sa faci testarea separat... static_assert nu isi are rostul cind exista disciplina si mai ales cind limbajul nu permite toate timpeniile

TS030, on 13 aprilie 2019 - 14:44, said:

Io nu ma refer neaparat la standarde, ma refer si la google in general. Crezi ca tu ai fi in stare sa raspunzi corect si complet la intrebarea "ce conditii trebuie sa indeplineasca o functie constexpr?" cind raspunsul e asta?

Quote

Practic scrii cod si dai compile si te rogi la dumnezo s-o nimeresti, daca nu, incepi sa tai

Sa nu mai zic ca se anuleaza unele pe altele citeodata, vezi mai sus ca nu poti folosi static_assert

dani.user, on 13 aprilie 2019 - 14:15, said:

Si nu ti se pare ca e o problema de productivitate cind din cauza necunoastelor tuturor chichitelor tot te lovesti de erori de compilare? Crezi ca daca nu calculai dimensiunea acelor vectori la compilare se schimba ceva in sensul ca a adus un atit de mare plus in aplicatie incit sa-si merite existenta? Sau e doar o chestie OCD de genul daca se poate calcula la compile time atunci neaparat sa se calculeze la compile time, chiar daca nici nu observi diferenta la run time?

Edited by Mosotti, 13 April 2019 - 15:59.

Mosotti, on 13 aprilie 2019 - 15:52, said:

In cazul particular al constexpr nu am simtit ca trebuie sa stiu chichite. Chichite a trebuit sa stiu pentru alte situatii.

Mosotti, on 13 aprilie 2019 - 15:52, said:

Daca nu calculam dimensiunea la compilare nu m-ar fi lasat sa aloc vectorul pe stiva. Ar fi trebuit sa aloc dinamic, crescand fragmentarea si pierzand memory locality. In acel proiect m-ar fi deranjat. In altele in care nu ma deranjeaza folosesc alte limbaje.


Compilatorul n-are nevoie de constexpr pentru a optimiza la compilare ce poate optimiza. Mai mult ajuta pentru situatii cand ai nevoie de o constanta (dimensiunea unui vector, constexpr if, etc).

 Untitled.png   30.54K   18 downloads

Edited by dani.user, 13 April 2019 - 16:18.

Pe topicul asta nu ne intereseaza mediocritatea. Ce-mi pasa ca alte limbaje nu suporta compile time computation? Ce-mi pasa limitarile autoimpuse ale altora? This is C++!

Singurul caz in care am vazut pe cineva incercand sa nimereasca un program a fost un programator Java incercand sa scrie "C++". Fara sa faca nici cel mai mic efort sa invete limbajul.
Utilizarea constexpr e banal de simpla, dupa cum am aratat. Cel putin chestiile de baza, nu trebuie sa memorezi conditii pe care oricum le gasesti pe Internet, iar compilatorul nu te va lasa sa gresesti.
Daca vrei sa scrii o librarie regexp cu evaluare la compilare, s-ar putea sa fie o idee mai dificil

static_assert e o chestie foarte faina. Ideal, erorile de programare sunt prinse la compilare - sau chiar cand scrii codul, cu un IDE suficient de puternic. La polul opus sunt limbajele gen Python, in care nu prinzi o eroare decat daca - atentie, daca! - incerci sa executi codul respectiv.

Mosotti se inseala crunt cand zice ca static_assert e mai bine inlocuit de teste. In primul rand pentru ca un static_assert iti garanteaza ca nu vei livra software-ul cu respectiva eroare. Un test pentru acea conditie poate lipsi, sau poate sa nu fie executat.
In al doilea rand, cum am spus: vrei sa prinzi erorile cat mai repede. Chiar daca - sa zicem - intr-o ora ai rezultatul testelor, si acestea acopera o conditie obscura pentru care ai folosi static_assert - asta e o ora pierduta.
Apoi, testele nu acopera (garantat) conditii pe care vrei sa le verifici prin static_assert. Un exemplu banal: vrei sa verifici ca int are 4 bytes (nu discutam de ce nu folosesti std::int32_t, exemplul e didactic. IRL poate vrei sa verifici ca un tip intr-o functie generica e integral). Mai mult, poate verificarea are loc intr-o librarie 3rd-party.
E naiv sa crezi ca testele tale acopera tot; iar daca ai o alternativa mai buna, de ce sa n-o folosesti?

Apropo, urmatoarea chestie:

static_assert(sizeof (int) == 5, "nope");

nici nu ajunge la compilare; IDE-ul o subliniaza frumos cu rosu: "static assertion failed with "nope"". Ce poate fi mai direct de-atat?

Man, scuza-ma ca te intreb asa o nerozie, da cum se poate ca testul sa lipseasca si static_assert nu poate sa lipseasca la fel de bine?

Si se pare ca habar n-ai cum se fac testele daca crezi ca peste o ora o sa-ti vina rezultatul

Si exemplul tau cu sizeof e doar un argument al cretinatatii limbajului. Intr-un limbaj normal la cap int este la fel peste tot, nu trebuie sa te tot intrebi oare cit o fi

Idem si cu librariile. Practic static_assert nu e decit inca un feature care te ajuta cu propriile probleme generate de limbajul insusi...

In C++ pot scrie ce vreau intr-o functie generica:

template<typename F, typename T>
void foo(T parametru, F callback)
{
   callback(parametru.fa_ce_am_chef());
}

Abia cand aleg sa apelez foo cu T ce nu are acea metoda imi da eroare. In alte limbaje nu m-ar lasa sa scriu functia pana nu specific restrictii gen T trebuie sa implementeze o interfata cu metoda..., lucru foarte restrictiv mai ales cand poate vreau sa transmit un parametru ce depinde de rezultatul altei metode.

static_assert ma ajuta sa pun restrictii in functia generica, sa nu permit folosirea ei in situatii care in mod normal ar trece de compilare (poate nu vreau == intre doubles de exemplu). Cum astfel de cod face parte dintr-o biblioteca cum as putea suplini static_assert cu teste?

TS030, on 13 aprilie 2019 - 23:41, said:

Poate ar trebui sa ne intereseze. Majoritatea proiectelor nu au doar asi la C++, mai au si cativa mai slabi. Si da, poti face si analiza statica a codului cu alte instrumente, dar alte limbaje au multe euristici de acest gen built-in la compilare.

Asta ca tot ziceam ca C++ s-a nascut in pantecele industriei software.

Problema e ca programarea e un domeniu nou, noi inca exploram acest domeniu de 50+ ani incoace, si inca invatam de ce avem nevoie si de ce nu avem nevoie. Iar majoritatea limbajelor, inclusiv C++, are multe concepte care nu sunt ortogonale, de aici si faptul ca exista enspe metode de a face acelasi lucru. Toate limbajele sufera de asta, dar C++ e foarte vechi si sufera cel mai mult. E cel mai mamut limbaj cred.

OriginalCopy, on 14 aprilie 2019 - 14:40, said:

Evident ca nu trebuie sa fii geniu ca sa programezi in C++. Mediocritatea de care vorbeam e cea promovata aici de Mosotti: tot ce nu intelege el e inutil pentru restul lumii.
Eu zic sa-i ascultam pe cei mai destepti ca noi, poate se prinde cate o idee utila.

C++... am aratat ca poate fi usor de folosit, cel putin la un nivel basic (scrierea de librarii generice de calitate industriala este complicata). Avantajul sau este ca e usor de invatat gradual, incepand cu chestiile simple si, treptat, trecand la concepte mai complicate. Iata un program - posibil al doilea pe care-l va scrie un programator - ce contine printre altele input/output, alocare dinamica de memorie si manipulare de siruri de caractere:

#include <iostream>
#include <string>
using std::string, std::cin, std::cout;
int main()
{
cout << "Please enter your name:";
string name;
getline(cin, name);
cout << "Hello, " + name << "\n";
return 0;
}

Nu e mult mai complicat decat in Python - dar a scrie acelasi lucru in C poate fi mai greu decat credeti.
Pointeri? Da, vei ajunge sa lucrezi cu pointeri, dar asta dupa ce esti familiarizat cu scrierea unui program simplu. Template-uri? Mai intai inveti sa le folosesti, adica ceva de genul:

std::vector<int> my_vec;

si mult mai tarziu sa scrii propriile tale clase/functii generice. Template metaprogramming e un subiect infricosator, dar optional.

Despre analiza codului: stiu ca esti fan Rust.
Noile standarde C++ trebuie sa-si pastreze compatibilitatea cu codul existent, ceea ce inseamna si cu C++98 si cu ce s-a preluat din C. Exista exceptii minore, chestii deprecate pe care le poti numara pe degetele de la o mana. In consecinta, C++ nu este un limbaj frumos: C++ este un limbaj util.

Ideea cu analiza codului la compilare este evident buna, asa ca si pentru C++ avem asa ceva.
Iata, cel mai simplu program C++:

int main() {}

Compilatorul ma sfatuieste sa declar main noexcept. N-ai fi zis ca are ceva de carcotit, la un program atat de simplu...
Apoi, exista lintere si analizoare de cod integrate direct in sistemul de build; MSVC include chiar si CPP Core Guidelines. Iata un alt exemplu simplu (si incorect, poate ceva ce-ar scrie un programator Java):

int main()
{
int* a = new(int);
}

Obtin 3 warning-uri:
warning C26462: The value pointed to by 'a' is assigned only once, mark it as a pointer to const (con.4).
warning C26409: Avoid calling new and delete explicitly, use std::make_unique<T> instead (r.11).
warning C26400: Do not assign the result of an allocation or a function call with an owner<T> return value to a raw pointer, use owner<T> instead (i.11).

Sansa C++-ului sta in tool-uri, nu in breaking changes.

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

Tu ai spus ca e o nerozie. Daca ai fi fost incepator, si daca n-ai fi dat sfaturi cu aroganta si limbaj de mahala...

Ia zi, dupa tine, ce e mai probabil sa lipseasca: un static_assert inserat de programatorul care a scris codul ce depinde de conditia respectiva, la momentul respectiv - sau un test echivalent, scris cel putin 6 luni mai tarziu, de catre cu totul altcineva care se intampla sa foloseasca libraria respectiva?
Apoi, sa nu uitam ca toti cei ce se intampla sa foloseasca libraria respectiva vor trebui sa includa respectivul test.

Sunt unii care cred ca ei au descoperit apa calda si testele automate.
Daca scrii un test pentru fiecare conditie ce poate (si trebuie) verificata static la compilare, o ora e un termen optimist.
De fapt, termenul realist este probabil "infinit" - caci cum verifici prin teste ca o functie generica este apelata doar cu tipuri integrale?

Din nou, ce nu intelegi numesti "cretinatate". Nu, Mosotti, astea-s limitele si frustrarile tale pe care le versi aici pe forum.
Exista un motiv extraordinar de bun pentru care un int nu are o dimensiune fixa: C++, la fel ca C, este un limbaj apropiat de hardware. Tipurile de baza se mapeaza direct pe hardware: bytes, words, double words. Orice altceva ar insemna ineficienta, operatii inutile e.g. ca sa suporti un int de 32 de biti pe un controller pe 16 biti. C++, desigur, ruleaza pe o varietate imensa de platforme.
Daca un "int" nu este la fel pe toate procesoarele, de ce ar fi la fel in C++?

Un subiect un pic mai subtil: alinierea datelor. Iarasi o chestie unde avem diferente de la platforma la platforma.
Ai putea sa-ti bagi picioarele si sa nu aliniezi nimic. Costul? Performanta dramatic scazuta. But this is C++.

TS030, on 14 aprilie 2019 - 17:39, said:

Bineinteles. Eu explicam de ce C++ e in situatia precara in care e, comparativ cu alte limbaje. Legacy e mare, lucru care e atat un avantaj (market share), cat si un dezavantaj (evolutia greoaie si cu ingreunarea limbajului, pentru ca nu se pot taia pur si simplu lucrurile vechi din limbaj).

Pe cand un limbaj nou are oportunitatea de a analiza greselile altora, si imbunatati situatia. Nu inseamna ca toate limbajele mai noi fac asta. Unele limbaje noi pur si simplu testeaza lucruri noi.

Dupa cum am zis, programarea e inca un domeniu nou, 50-100 de ani, depinde cum masori, noi inca invatam sa mergem, mai cadem, mai mergem de-a buselea, ne mai scrijelim genunchii, apoi ne ridicam si o luam de la capat.

E un ciclu destul de natural al evolutiei, chiar daca vorbim despre ceva tehnic.

TS030, on 14 aprilie 2019 - 17:39, said:

Cred ca rust e un pas inainte, dar nu stiu daca va reusi sa aiba repercusiuni adanci in domeniul programarii. E foarte probabil ca si rust sa devina aceasi gramada ordonata de concepte care e C++ acum.

Cred ca si daca rust esueaza, tot va deschide noi oportunitati de analiza a problemelor create de rust, si va ajuta la inventarea unui alt limbaj care sa aiba si mai putine neajunsuri.

Dar aici vorbim despre urmatorii 20-30-40 de ani, nu despre rezultate imediate. Asta daca nu se va gasi un fizician sau un matematician care sa inventeze o complet noua arhitectura de calcul de care limbajele actuale nu pot profita la maxim - si atunci un alt limbaj care se pliaza mai bine pe acea arhitectura va prinde aripi.

Edited by OriginalCopy, 14 April 2019 - 19:00.

OriginalCopy, on 14 aprilie 2019 - 18:57, said:

Nu te contrazic, ba sunt de acord.
Fara legacy C++-ul ar fi fost mort din fasa, el nebeneficiind de suportul unei companii precum Sun, Oracle sau Google. Unde alte limbaje au reusit prin marketing, unele prin hype, C++ a reusit prin propriile puteri.
D... cati de-aici stiu de el? - nu a beneficiat de un asemenea suport, nu a reusit.

Alte limbaje... da, pot evita unele chestii evidente in C++ (de exemplu, e banal sa "cureti" conversiile implicite). Vor exista mereu greseli (noi si chiar vechi) de facut
Si chiar pentru un limbaj atat de vechi C++ a facut multe lucruri corect. Distrugerea determinista a variabilelor, de exemplu, care face posibila RAII. Alte limbaje (cough*Java*cough) s-au dat peste cap pentru constructii oarecum similare dar inferioare, cand au realizat ca resursa nu inseamna doar memorie. Din a cata incercare le-a iesit ceva decent?
La alte limbaje, versiunea 3 nu poate rula codul scris cu versiunea 2. Samd. Nu exista, si nu va exista limbaj perfect.
C++ este cel mai bun limbaj imperfect pe care-l avem la dispozitie Asta pentru proiectele in care ai nevoie de puterea, performanta, flexibilitatea oferite.

OriginalCopy, on 14 aprilie 2019 - 18:57, said:

Rust, hmm... cam orice limbaj care-si propune sa fie unul general va creste semnificativ in dimensiune. Crede cineva ca Java e un limbaj micut si simplu? Specificatiile Java 11 au peste 700 de pagini, si asta fara librarii. Cam atat are si partea de limbaj din standardul C++.

Cat despre fizicieni si matematicieni, no way! Uite-asa mai apare cate-un Haskell
Just kidding. C++, desigur, include cateva elemente utile de programare functionala... uh... monads?

TS030, on 14 aprilie 2019 - 17:39, said:

Stii vorba aia, bine ca esti tu dastept
Eu nu promovez nimic, doar incercam sa-ti temperez avintul si eventual sa-i avertizeze pe aia care ar putea fi "interesati" de strutzocamila asta numita Siplasplas: IT AIN'T GONNA HAPPEN!

Daca o sa se angajeze undeva, mai mult ca sigur ca n-o sa lucreze DOAR in C++ modern si nici n-o sa poate face multe din lucrurile "minunate" pe care le vezi pe internet. Ti-am pus mai ieri regulile de la Google cu "fara aia, fara aia". Crezi ca daca te angajezi la Google si faci o strofocare de cod alambicat cu tot felul de template-uri n-o sa-ti zica aia sa o lasi moale ca trebuie sa inteleaga si altii?

In plus, chiar daca poti sa spui despre mine ca-s mediocru, ceea ce-mi convine de minune, nici nu pretind ca as fi expert, cum explici ca aia de la Google s-au apucat sa faca un limbaj nou pentru ca aveau aceeasi parere despre C++. Sigur ca dpmdv mai bine nu se oboseau, ca le-a iesit un cacat si mai mare, dar nu poti sa spui ca si aia sint mediocri. Adica io daca zic ca C++ e de cacat ma opresc aici, aia si-au inventat alt limbaj de programare, deci pasiunea lor in a dovedi aceasta afirmatie este la un cu totul alt nivel

Alexandresu, care probabil e la nivel de guru in C++, s-o sculat intr-o dimineata si o zis "bag picioarele, ce-ar fi sa fac io alt limbaj?" si asa s-o dus sa faca D. Care vine de la faptul ca e "ca dracu" probabil. Dar deja divagam...

Eu folosesc bine mersi C++ cu Qt (iubirea mea pentru Qt este eterna ) si ma doare la banana de modernitate, atita timp cit chiar nu am nevoie de ceva care aduce un plus real. Nu trebuie sa-mi umplu codul cu assert-uri, pentru ca sint suficient de destept sa stiu in orice moment ce o sa intre unde si cum si ce iese. Io-s programatorul, adica dumnezo, si prin urmare sint atoatestiutor si atotputernic. Si btw, mi-am schimbat analiza codului pe "all rules" si n-am nici un warning. Se pare ca e perfect OK fara modernisme, cel putin din prima Microsoft, ce dracu stiu aia de programare anyway... I embrace mediocrity

Apropo de Java, in C++ posibilitatile de testare sint cit se poate de penibile si de oribil de folosit, poate si de-aia se testeaza manual toate prostiile la compilare. La fel si chestii de genul lucru cu baze de date (OCCI, par example, e un cacat cu oki)

TS030, on 14 aprilie 2019 - 18:24, said:

In limbajele normale la cap si mai moderne decit C++, librariile sint testate si codul care se bazeaza pe librarii se testeaza si el. Si nu dureaza ore ca sa crape ca n-ai testat la compilare. Serios, chiar exista asa ceva, stiu ca pare incredibil pentru C++ unde tre sa testezi daca intu e de 4 biti au ba si alte stupizenii de anii 80, in timp ce-ti freci creierii 3 saptmini cu template-uri ca sa faci o chestie pe care o faci in alt limbaj in juma de timp, plus teste. Deci da, e o nerozie sa testezi manual la compilare, precum e o nerozie toate povestea aia cu template metaprogramming.

Unul din cele mai utile feature-uri la un limbaj in 2019, cind nu se mai pune problema de performanta si de bitzi si bitzisori ca in 1984, este sa fie cit mai usor de testat.

TS030, on 14 aprilie 2019 - 18:24, said:

Probabil pentru ca e cod retardat daca ai o functie care accepta o infinitate de tipuri si tu verifici la compilare daca se apeleaza cum trebuie. Poate ca problema ta se poate rezolva mai elegant? Poate intr-un limbaj in care nu trebuie sa verifici manual la compilare 1000 de chestii?

TS030, on 14 aprilie 2019 - 18:24, said:

Degeaba e un limbaj apropiat de hardware, daca e idiot. Cind trebuie sa verifici cit de mari sint tipurile de date deja nu mai poti vorbi de modernitate. Daca era modernitate, faceau ceva in privinta asta in 30 de ani, nu sa-ti ofere metode sa verifici. Cit despre rularea pe o imensitate de platforme, ia zi tu cite dintre compilatoare sint la zi cu implementarea, adica "moderna"? Uite aici

https://en.wikipedia...s#C _compilers

TS030, on 14 aprilie 2019 - 18:24, said:

Care performanta scazuta dramatic? Da-mi un exemplu de performanta scazuta dramatic sau scoti epitete de pe undeva?

Bottom line, ca poate nu-s inteles... N-am zis ca C++ nu e fabulos, puternic, minunat, isi are locul lui in istorie etc. Tot ce incerc sa spun e ca e un limbaj de cacat in esenta lui, nu are absolut nimic "frumos". Partea buna este ca-ti permite sa faci ce vrei, asta daca stii ce faci. Daca nu stii ce faci, partea proasta e tot ca iti permite sa faci orice.

Eu vad viitorul C++ destul de gri, daca nu chiar negru. Lumea cauta acuma chestii mai haioase, nu sa frece pointeri, fie ei si smart, toata ziua. Uita-te la Bjorn, i-a zburat tot parul din cap incercind sa faca limbajul mai bun si n-a facut mare brinza...

Mie imi place sa fac o comparatie intre C++ si WoW, in sensul ca mai sint destui jucatori, da foarte putini noi. Aia care au ramas, au ramas pentru ca asta fac cel mai bine si n-au chef sa schimbe. Nu se poate vorbi ca iubesc limbajul, pentru ca daca ai iubit limbajul acum 10 ani n-ai cum sa-l iubesti acum, cind e complet schimbat si viceversa. E un status quo destul de deprimant.

Mosotti, on 14 aprilie 2019 - 19:45, said:

Cum sa nu, iti promovezi incompetenta si aroganta extrema - cu un limbaj de mahala to match.

Ca nu intelegi la ce-ar ajuta compile time computing, ca nu intelegi arhitectura calculatoarelor - ai facut asta foarte, foarte clar. Esti depasit complet.

Mosotti, on 14 aprilie 2019 - 19:45, said:

Google - inca o chestie pe care n-o stii? - sunt direct implicati in dezvoltarea limbajului C++.
De pe https://isocpp.org/std/the-committee:
Project Editor: Richard Smith (Google). The project editor is the person ultimately responsible for applying committee-approved changes to the standard’s working draft.
Library Evolution, aka LEWG: Titus Winters (Google).
SG5, Transactional Memory: Hans Boehm (Google). Exploring transactional memory constructs for potential future addition to the C++ language.
SG7, Compile-time programming: Chandler Carruth (Google). Initially focused on compile-time reflection capabilities, then expanded to compile-time programming in general.

Ca sa fie clar, astia-s doar "liderii" grupurilor respective.
Amuzant, nu? Cineva de la Google - Chandler Carruth - conduce grupul pentru Compile-time programming. Hai sa auzim cum exemplul Google nu mai e bun!

Cat despre "strofocare de cod alambicat cu tot felul de template-uri", esti dintr-o alta lume... exemplele pe care le dau sunt cum sa faci lucrurile mai simple.

TS030, on 13 aprilie 2019 - 23:41, said:

Trecand peste aspecte IMPORTANTE ca "depinde de cerintele proiectului" sau "python e cum e by design", sa zicem ca avem doua proiecte pentru care am ales limbajul potrivit: unul in C++, altul in Python.

Ce conteaza?

Conteaza sa livrezi produsul la timp si fara buguri.

Deci doar o chestiune de a profita la maxim de avantaje, si de a minimiza dezavantajele fiecarui limbaj.

Daca e sa ma gandesc ca as fi facut un proiect facut in Python in C++, sunt aproape sigur ca as fi avut intarzieri: sa stai sa cauti atatea biblioteci care nu sunt incluse, sa compilezi si sa rulezi teste de fiecare data, s.a.m.d. - m-ar fi incetinit cu siguranta.

Pe cand cu python am avut bucla de dezvoltare atat de scurta (10-30 secunde) incat am amortizat costul lui "verificare la runtime", si in plus am primit apreciere de la client ca am livrat la timp.


Dincolo de limbaj, nu trebuie sa uiti de scopul adevarat - de ce programam?

Post dupa post numai cu:

Mosotti, on 14 aprilie 2019 - 19:45, said:

Ma intreb, cum naiba mai esti tolerat pe Professional Zone? Na, ca-ncep sa vorbesc si eu urat.

Mosotti, on 14 aprilie 2019 - 19:45, said:

Deci, vorbeam de problemele de performanta care apar la accesul nealiniat la date. Si tu intrebi ce-i aia.
La ce nivel ar trebui sa-ti explic? Sa te iau cu bazele arhitecturii calculatoarelor?

Mosotti, on 14 aprilie 2019 - 19:45, said:

Nu trebuie sa ma uit nicaieri. Apropo, pagina corecta este asta: https://en.cpprefere...ompiler_support

MSVC e C++17 complete (limbajul 100%, cu unele exceptii prin librarii). Include chestii experimentale din C++20, precum modules.
GCC, Clang. Si avem cele 3 compilatoare majore, cei 3 dezvoltatori de compilatoare direct implicati in dezvoltarea C++.

OriginalCopy, on 14 aprilie 2019 - 20:26, said:

Nu am spus niciodata ca sa folosim C++ pentru orice aplicatie. Sau ca o aplicatie ar trebui scrisa intr-un singur limbaj.

Da, conteaza sa livrezi produsul la timp si - nu fara buguri, asta-i imposibil, ci fara buguri importante.
Ce inseamna insa sa livrezi produsul? Trebuie sa livrezi ceva ce corespunde cerintelor clientului; uneori asta include anumite cerinte de performanta, memory footprint, consum de resurse etc.
Mentionam intr-un post anterior de calcule complicate ce trebuie realizate in 1/60s. In acel domeniu C++ e rege... pentru ca n-ai incotro, ci trebuie sa folosesti un limbaj mapat direct pe hardware.
Oare cum e sa constati, spre finalul proiectului, ca esti departe de-a respecta cerintele de performanta dar ca nu prea ai ce face? parabellum vorbea despre un asemenea caz, in care un proiect a fost rescris din C# in C++. Stiu si eu aplicatii cu probleme grave de performanta (unele defuncte, la altele s-a lucrat enorm); dar o sa dau un alt exemplu de aplicatie rescrisa in C++: Cassandra/Scylla. Performanta imbunatatita de 10 ori fata de implementarea Java.
Iar Chandler Carruth vorbeste la fiecare CppCon despre optimizarea codului.

Uneori, alegerea potrivita este C++. N-o sa spun niciodata intotdeauna. Pentru un script, deschid Notepad++ si bag ceva Python. Daca specificul aplicatiei se potriveste cel mai bine diverselor framework-uri Java, o sa-i las pe colegii mei javisti.

Deci, despre ce vorbim?

Edited by TS030, 14 April 2019 - 20:52.

TS030, on 14 aprilie 2019 - 20:14, said:

Scuza-ma ca te intreb, unde am zis io ca TOTI de la Google ar avea ceva cu C++? Tu ai idee cit de mare e Google. Ideea este ca unii care au ajuns la Google, deci putem concluziona ca sint mai destepti ca mine sau ca tine, au decis ca C++ e ca dracu si au facut un nou limbaj. Nu cred ca si aia erau la fel de prosti ca mine, sa nu stie ce e cu compile-time programming in general

Io cred ca ti-i ciuda ca nu poti convinge lumea ca strutzocamila e viitorul programarii

TS030, on 14 aprilie 2019 - 20:29, said:

Nu te mai preface mimoza. Las ca stiu io cum vorbesc programatorii in realitate. Faci pe mimoza ca o mimoza si te legi de chestii puerile... Imi aduci aminte de politicianu ala care zicea politicos si civilizat "domnule, dumneavoastra sinteti un idiot"...

TS030, on 14 aprilie 2019 - 20:29, said:

Tu esti in stare sa dai un exemplu concret? De genul "am vrut io odata sa fac un program si merea ca curu in orice limbaj as fi incercat... cind am incercat C++ a mers ca raketa". Sau doar te dai expert in "arhitectura calculatoarelor"?

Tu ai auzit vorba aia "premature optimization is the root of all evil"? Prin urmare ce ar fi daca, si sigur ca asta e doar o idee nastrusnica, in loc sa ai un limbaj in care trebuie sa verifici toate prostiile la compilare, ce-ar fi daca s-ar inventa un limbaj in care s-ar compila codul intr-un singur fel si apoi pe fiecare arhitectura s-ar recompila nativ. Sint sigur ca ar merge muuuuult mai incet, nici nu merita incercat

OriginalCopy, on 14 aprilie 2019 - 20:26, said:

Cu Python nu poti calcula Fibonacci la compilare si totusi indata ii ia fata lu C++. Gee I wonder why, probabil ca sint prea multi mediocrii pe lumea asta

Incercati sa va intelegiti omenste.

Edited by MarianG, 14 April 2019 - 21:18.

TS030, on 14 aprilie 2019 - 20:50, said:

Vorbim despre fanboism si despre cultism, nu mai vorbim despre ratiune. In primul rind, nu s-a imbunatatit performanta de 10 ori. Asta a fost doar ceea ce au pretins aia. In al doilea rind nu s-a facut imbunatatire de performanta prin magie, doar trecind de la C++ la Java, au rescris ceva, un lucru mult mai usor e sa inovezi decit sa inventezi. In al treilea rind, uite Cassandra vs Scylla "de 10 ori mai rapid"

https://db-engines.c...sandra;ScyllaDB

Cum iti explici ca Cassandra e pe locul 10 si Scylla "de 10 ori mai rapid" e pe locul 122? Io, care nu cred in fat-frumosi, stiu raspunsul: bullshit.

Benchmark-urile sint o imbecilitate. Cine isi cumpara ceva pentru ca a vazut un benchmark pe net e un cretin cu pene. Asta se inmulteste cu cel putin 10 daca benchmark-urile sint facut de producator.
Niciodata sa nu crezi ce zice producatorul, decit daca iti lipseste o doaga.
Scylla ruleaza doar pe Linux (si aici se vede trade-off-ul folosirii C++, au targetat special Linux, dar sa faca acelasi lucru pe Windows sau altceva le-ar fi imposibil sau foarte, foarte dificil, altfel ar fi facut-o)

Acuma ce concluzii putem trage? Cassandra a mers pe Java, a implementat rapid ce-a implementat, pe platforme multiple, cu performante acceptabile. Implementarea C++ a supt tot cea putut dintr-un anumit Linux, ca nu merge pe toate, folosind un anumit framework, obtinind viteze superioare (dar nu fantasmagorice cum pretind aia), ceea ce e perfect normal. Dar dpdv business, cine a fost mai cistigat? "Cassandra is used by 40% of the Fortune 100"

Oricum cind e vorba de NoSQL, io as alege MongoDB la orice ora...

[ https://www.youtube-nocookie.com/embed/b2F-DItXtZs?feature=oembed - Pentru incarcare in pagina (embed) Click aici ]