Operator overloading – da sau ba?

Ambele suck, pentru ca presupune ca separatorul de cale este “/“.

Prima da, dar in cazul celei de-a 2-a, fiind vorba de o clasa separata (nu rezulta un string), aceasta poate contine logica necesara alegerii separatorului nativ al platformei curente.

Eu n-as folosi separatori diferiti in logica de pastrare a cailor. As folosi peste tot "/" si doar cind vreau sa tiparesc sau sa interactionez cu biblioteci specifice as face schimbarea. Problema este de perceptie, pentru cineva care a lucrat doar pe Windows ani si ani, daca trebuie sa foloseasca un asemenea cod nu percepe la fel de clar ce vrei sa faci. Pentru el / inseamna impartire. Si daca codul mai ii si de genul

auto a = b / c;

l-ai spart.

De-aia dpdmv si auto ala e cam cancer. Te ajuta sa fii lazy pe moment, dar peste 5 ani mult succes ca sa intelegi ca functia x returneaza nus ce hashmap sau functia y returneaza nus ce array de dracu stie de pointeri...


Daca clasa este utilizata intern si nu are nimeni acces la ea, evident ca poti folosi ce vrei...

Of, copiii astia... whatever, nu merita.

OriginalCopy: vorbim de doua lucruri diferite, de aceea pare ca nu ne-ntelegem
Exemplele tale cu proiecte de tip 1 si de tip 2 pun aceleasi probleme, indiferent de cum ai concatena caile respective - corect? Eu nu spun sa concatenezi folosind operator/ in locul folosirii unui dictionar.
Vezi exemplul lui dani.user, este exact la ce ma refer. Cu o precizare: ambele exemple presupun overloading pentru operator+

Am lucrat destul intr-un limbaj care nu suporta nici o forma de overloading - C - si am vazut tot soiul de uratenii, unele pe care nu ai cum sa le ocolesti. Acelasi exemplu simplu ar fi mult mai urat - si da, va trebui sa tii cont "manual" de separatorul nativ al platformei, ceea ce in std::filesystem e automat. Mi-e si sila sa scriu codul.

Mosotti, on 27 aprilie 2019 - 11:07, said:

As lua mediocrul care-a scris o asemenea bazaconie intr-o sala si i-as explica, asa, cu binisorul, cum sta situatia.
Stii care-i problema cu exemplul tau? Nu operator/, ci numele de variabile.

auto settingsFilePath = configPath / settingsFileName;

nu te duce cu gandul la impartire. Desi e unul din exemplele in care e discutabila folosirea lui auto.

Edited by MarianG, 27 April 2019 - 15:04.
daca nu merita, ne abtinem

Nu stiu ce rost are toata discutia asta. Cand au fost concepute limbajele (sau cand au fost modificate/imbunatatite) s-au gandit la subiect oameni probabil mult mai priceputi decat noi.

Wikipedia are chiar un tabel cu limbaje pe tema asta https://en.wikipedia...tor_overloading Java e unul dintre limbajele care au ales sa nu aiba operator overloading si cat pe ce nu aiba method overloading (v-ar fi placut?), folosind exact aceeasi logica. Bine, daca duci logica la limita, limbajul care iti interzice sa faci orice e perfect, pentru ca programul care nu face nimic nu contine nici o eroare.

Din lista aia, la unele care nu au, se poate argumenta ca nu e asa de mare nevoie de operator overloading. Multe sunt fie niste limbaje simpliste si jenibile la ora actuala (BASIC? ), altele, cum ar fi ObjectiveC, lucreaza foarte bine impreuna cu C++ (si C). Personal am folosit ObjectiveC doar la partea cu UIul si folosirea SDKului, in rest a fost C si C++. Asa ca n-am simtit limitarile.

Fortran, MATLAB, C++, ca sa numesc cateva, au operator overloading. Asta sugereaza ca daca lucrezi la un program care contine in specificatii mai mult decat blablaologie, deja e un lucru util sa ai operator overloading. Ada, pomenit pe acolo, e inca folosit substantial in avionica. Fortran e inca rege in calcule matematice. https://wordsandbutt...ll_a_thing.html Multi care scriu in limbaje hyped de fapt fac o gramada din treaba prin apeluri in biblioteci implementate in fortran. MATLAB e folosit o gramada in stiinta si inginerie. C++ e C++. In Mathematica (limbajul e Wolfram) care nu-i pomenita pe-acolo, se pot implementa chiar operatori care n-au semnificatie 'by default': https://reference.wo...InMeanings.html

Edited by parabellum, 27 April 2019 - 12:04.

TS030, on 24 aprilie 2019 - 09:00, said:

Eh, daca ai avea cunostinte de baza despre cum functioneaza un compilator, nu ai mai intreba asta.

TS030, on 24 aprilie 2019 - 09:00, said:

Pai normal ca nu stii. Programatorii stiu. E de notorietate faptul ca mai multe limbaje de larga raspandire ce nu suporta op. overloading (intre care si java si javascript) au + supraincarcat pentru concatenare de stringuri pe langa functia matematica de adunare. Apoi ai alti operatori sau simboluri cum ar fi (), []. {} care au semnificatii diferite in functie de context.

dani.user, on 27 aprilie 2019 - 09:57, said:

Pai e. in prima varianta ai variabila + "string" + variabila

Ce poate fi aia altceva decat concatenare de stringuri? Intr-o lume normala la cap ma refer, ca in c++ cine stie... sunt destule limbaje in care + e folosit pt. concatenare de stringuri

In cate limbaje ai vazut tu / utilizat pentru concatenare? Aia pentru majoritatea programatorilor va duce a impartire. Si esti foarte optimist cu denumirea variabilelor.

Intr-un limbaj OOP eu zic ca solutia potrivita ar fi o clasa Path care sa contina diverse elemente ce formeaza o cale: root, separator, directoare, fisier(poate si symbolic link) plus o varietate de operatiuni care pot face(inclusiv concatenare) sau iti pot arata diverse chestii,

TS030, on 27 aprilie 2019 - 11:12, said:

Ai lua pe dracu lacu daca codul a fost scris acum 5-7-10 ani. Sau daca codul a fost scris de cineva caruia nu i-a pasat de chestiile astea, de exemplu cod open source facut de o singura persoana, care a facut  ce a avut chef. Elitismul asta retardat pe care-l afisezi nu are nici o legatura cu lumea reala. Programarea nu exista doar in conditii ideale. Este de notorietate folosirea numelor de variable prescurtate la extrem, mai ales in limbaje de genul C / C++, gen "strrchr" sau "crbegin", chestii extrem de sugestive, nici nu trebuie sa cauti ce ar putea sa insemne. Poti multumi limbajelor de genul Java ca au venit cu ideea fabuloasa de a folosi limbaj natural

Faptul ca se pare ca tu nu ai maturitatea si experienta de a fi avut de a face cu proiecte la care au lucrat sute de oameni, proiecte care au trecut prin tot felul de crize, nu inseamna ca nu exista sau ca nu vor exista in continuare. Oricum e bine ca tu ai de-a face doar cu cod superb, scris de programatori supercompetenti, care nu au nici un fel de probleme in lumea reala si sint complet si absolut focusati pe frumusetea codului. Sa hi sanatos in bula ta ireala

Quote

Constructia aia face parte din C++ 17. Despre ce vorbesti tu aici? Cine a folosit C++ 17 acum 10 ani?

Si stai linisit, nu java a inventat apa calda. Cat despre 'language verbosity' nu e neaparat un lucru bun. Chiar este criticat la java (si nu numai). Poti ajunge sa nu mai vezi padurea de copaci.

parabellum, on 27 aprilie 2019 - 13:22, said:

nu e C++ 11 ?

Trebuie sa prinzi tot contextul discutiei. Era vorba de asta: https://en.cpprefere...filesystem/path

parabellum, on 27 aprilie 2019 - 15:01, said:

Exact unde anume vezi tu mai sus "aia"? Ca nu rezulta de absolut nicaieri! Citeaza postul, sa vedem!

DemocracySucks, on 27 aprilie 2019 - 15:10, said:

Rezulta din discutia despre cai si operator/
Dar ai dreptate, n-ar fi trebuit sa presupunem ca ceilalti stiu despre C++17, ci sa fi precizat explicit.

TS030, on 27 aprilie 2019 - 15:36, said:

Nu rezulta absolut deloc. Constructii de tipul auto a = b / c; exista din 11.

Chiar trebuie sa ne certam pe chestia asta? Citeste posturi din urma, se pornise de la compunerea cailor de fisiere. Iar ideea era ca acea constructie ar putea fi confundata cu o expresie matematica, fara a fi asta.
Si chiar daca n-ar reiesi din context, am clarificat acum - nu e asta cel mai important?

Edited by TS030, 27 April 2019 - 15:57.

TS030, on 27 aprilie 2019 - 11:12, said:

Daca te uiti doar la un copac, da, e aceeasi problema, dar daca privesti padurea in ansamblul sau, nu.

Eu vorbesc despre compromisuri si unde tragi linie, vorbesc despre factori umani, de managementul unei echipe (am zis "daca asta te face sa vii zambind la munca"), lucruri d-astea interdisciplinare, si rolul sau nerolul lui operator/ intr-un proiect.

Vorbesc integrativ.

Faptul ca plantezi intr-un cod "path1 / path2" e un detaliu de nivel incepator, dar cand si cum alegi sa folosesti sau sa nu folosesti acest syntactic sugar e o decizie mai complexa ce tine de alti factori.

Tipurile de proiecte 1 si 2 sunt diferite w.r.t. paths, deciziile pe care le iei ar fi bine sa fie diferite. Ca una e sa vrei sa schimbi temporar o cale intr-un singur loc din cod, alta e sa trebuiasca sa o faci consecvent in tot proiectul. Si "consecvent" e dificil intr-un proiect in care ai path1 / path2 de mii de ori rasfirat prin tot codul. Chiar daca suna usor, tipul asta de situatii este cel care creeaza buguri  bugurile mari nu se intampla aproape niciodata cand dezvolti initial, ci cand trebuie sa faci ulterior schimbari.


Per total nu inteleg ce vrei sa spui, pentru ca nu stii sa discuti. Spui doar "nu" la ce nu iti convine, dar nu articulezi clar lucrurile cu care esti de acord. Cand vorbesti cu cineva, decent e sa stabilesti si lucrurile comune sau macar compatibile.

A, si nu mi-ai raspuns la intrebare.

Edited by OriginalCopy, 27 April 2019 - 17:30.

TS030, on 27 aprilie 2019 - 15:50, said:

Se pornise, dar nu a pomenit nimeni de c++17 sau de vreo facilitate de acolo. Nu ca ar avea teribila relevanta.

Da, evident ca se confunda cu operatia de impartire. La fel cum se confunda multe altele in c++, avand codul cel mai ilizibil dintre limbajele majore. De aia nu-l mai foloseste nimeni decat unde e neaparata nevoie (low latency, grafica performanta, embedded & co.)

Edited by DemocracySucks, 27 April 2019 - 18:36.

Quote

Cel mai ilizibil, pentru cei care nu cunosc limbajul.
Tiobe arata ca e destul de folosit: https://www.tiobe.com/tiobe-index/
Poate e neaparata nevoie in locurile alea.
Pe undeva am pus corespondenta C++ - python cand se folosesc librarii in stilul python (exemplul era pe OpenCV acolo). Ilizibilitatea aia nu era deloc evidenta. Dimpotriva, C++ e mai lizibil din cauza tipurilor.

Sa nu mai vorbim ca se aplica considerentele discutate la link-ul pe care l-am pus mai sus (Fortran is still a thing).

dani.user, on 20 aprilie 2019 - 11:27, said: