KOJA: ze proste takhle dlouhou a dalekosahlou evoluci asi jiny jazyk nezazil mozna krome Fortranu?

Koncepty klepou na dveře, tady je blog post s malou ukázkou:
omni blogs
https://omnigoat.github.io/2020/01/19/cpp20-concepts/
Více také na https://en.cppreference.com/w/cpp/language/constraints

C++Now 2017: Daniel Pfeifer “Effective CMake"
https://www.youtube.com/watch?v=bsXLMQ6WgIk

ANT_39: Ja prave se dostal do faze ze uz algoritmy jsou pro mne citelnejsi ... nicmene s tim x.do_stuff(); mas pravdu, schazi tu neco jako std::for_each(container, do_stuff);

VEVERAK: Ja to obcas zkousim, ale mimo nejake sorty a podobne "velke" algoritmy mi to nepripadne moc prakticke. Takovy to for (auto const &x: xs) x.do_stuff(); mi v porovnani s std::for_each pripada citelnejsi, a ten zapis byva i kratsi.

Tu a tam narazim na potrebu napsat neco jako je v Pythonu print ",".join(foo(i) for i in kontejner), a co jsem se koukal par let zpatky, tak cyklus s booleanem, ktery ridi zda "," vypsat, nebo ne, byl proste nejcitelnejsi reseni.

V zasade jsem z tech algoritmu celkem zklamany. Ten jazyk porad jeste nema expresivitu, aby se to vyplacelo. Cast problemu je asi v tom, ze mam oko natrenovane na cteni te rozvinute formy, ale faktem je, ze kdyz se kouknu na tu syntaktickou polivku, ktera kolem toho volani algoritmu typicky vznikne, tak to radsi prepisu zpatky.

Poslednich par let ale C++ sleduju jen dost zdalky, mozna se to s C++17 zlepsilo.

Vzhledem k tomu ze na tom byl v mem projektu prostor, tak jsem si rekl ze na truc kromne util/ nikde nepouziju for/while.
Po case to zaclo drhnout na dvou vecech:

- Psat pokazde container.begin() a container.end(), hlavne v situacich kdy se jedna o delsi jmeno, je otrava a kazi to prehlednost.
- Par veci nejde udelat s standartnima algoritmama jednoduse (kombinovat je slozite za sebou nema smysl).

Skoncil jsem u toho ze jsem si napsal funkce forEach(Container container, UnaryFunction f) etc... ktere berou jen jeden argument (a ocekavaji begin()/end()) a doplnil par dalsich funkci na algoritmy ktere tam nejsou, napr: maxElement(container, f)

Ve finale to pro mne vedlo k sprehledneni kodu a jsem s tim i dlouhodobe spokojeny. V tenhle moment kdyz vidim kus kodu tak mam jasne co za algoritmus je spusteny nad daty a kontextove je typicky jasne kdy a jak se spousti dana funkce a kcemu asi slouzi, neni potreba analyzovat cely kus kodu. (Coz je fajn.)

Ovsem uznavam ze to kromne mne nikdo jiny necte takze muze byt biased nazor.

GitHub - lefticus/cppbestpractices: Collaborative Collection of C++ Best Practices
https://github.com/lefticus/cppbestpractices

UETOYO: Jeste jsem koukal na prezentaci o Ranges od Erica Nieblera ktera je tam zminovana.
CppCon 2015: Eric Niebler "Ranges for the Standard Library"
https://www.youtube.com/watch?v=mFUXNMfaciE

Je to vice-mene step-by-step popis toho prikladu s formatovanim kalendare. Posledni cca pulhodina jsou dotazy a pro mne byly asi jeste zajimavejsi (sentinely, implementace operaci na nekonecnych ranges, o tom jak se to ma s typama pri manipulaci s ranges apod.)

Jak jsem na to koukal, tak mi ale doslo, ze za tema par radkama kodu s autodedukovanyma typama je hromada kodu ktery je pro nas uplne virtualni, prekladac si ho sice vygeneruje (treba kdyz si udela instance konkretnich sablon) ale AFAGK (google mlci) pristup k nemu nemame, takze je nutne si ho modelovat jenom v hlave. Videt je vlastne jenom meta-C++ kod, pripadne AST a interni reprezentace kodu v prekladaci a pak az assembler. Rikam si jestli by nebylo zajimave mit moznost premluvit prekladac aby skutecne vygeneroval a dumpnul C++ kod po vsech compile-time vypoctech a pred optimalizacema. Jedine relevantni tool o kterem vim a ktery ale ma trochu jiny uhel pohledu a nevim nakolik je to jen proof-of-concept je meta-debugger Metashell (Templight) z dilny Abela Sinkovics a jeho studentu.

KOJA: Ten talk jsem nevidel, ale osobne jsem z pouziti std::accumulate, std::transform atd. taky rozpacitej. Ted c++ nepisu, ale kdyz jsem to pred nejakou dobou zkousel pouzivat, tak mi vetsinou vyslo, ze for cyklus je prehlednejsi a cistsi.