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.

UETOYO: Nejenomze posloucha ale dobre se na to i kouka. Me to malem dojalo.
Nektery veci jsem si "taky vymyslel" (triviality jako pouzit lambdu kdyz chci inicializovat const instanci pomoci funkce ktera bere v rozhrani referenci na vysledek), takze na jednu stranu jo, je zajimavy videt, ze nekdo uvazuje podobne.

Na druhou stranu mam ale trochu dilema protoze kdyz vidim kam tenhle zpusob psani v C++ vede (treba pokusy pouzit std::accumulate, std::for_each nebo std::transform namisto jednoducheho for cyklu), tak si pak v nekterych pripadech reknu, ze C++ na tohle proste nebylo navrzeny a radsi to napisu "C-ckove" protoze expression-oriented zapis je dost krkolomny a i ja sam bych na to za mesic taky mozna koukal jako pero z gauce. Pravda ale je, ze znacnou prekazku vidim v reprezentaci "kolekci" objektu pomoci dvou iteratoru vsude v STLku.

Na hodnoceni takovych tech znasilnovani ruznych operatoru pro syntakticky cukr (potazmo tvorbu DSL) mam zatim malo dat ale prozatim jsem spise opatrny protoze leccos vypada presne na takovyhle slidech moc hezky ale v realu se do toho zatim vzdycky bud pripletl nejaky zakerny detail C++ nebo byla implementace toho aparatu natolik slozita, ze pri pomysleni na jeho debugovani jsem ja i temer vsichni ostatni vymekli a napsali to "postaru" a jednoduse.

BTW nevite nekdo o nejake vetsi (verejne citelne) C++ code-base kde by byly takovehle novoty konzistentne pouzivane? Nebo aspon nejake sepsane zkusenosti a poznatky kde to drhlo?

Phil Nash -- autor knihovny Catch -- ,á medový hlas :D, dobře se to poslouchá.
Functional C++ for Fun and Profit by Phil Nash
https://www.youtube.com/watch?v=YgcUuYCCV14&t=250s

Stojí za shlédnutí
C++Now 2017: Niko Matsakis "Rust: Hack Without Fear!"
https://www.youtube.com/watch?v=lO1z-7cuRYI

Things that Matter - Scott Meyers | DConf2017
https://www.youtube.com/watch?v=RT46MpK39rQ

UETOYO: jo, mam jeden projekt jako staticky qt pod msvc. pouzivam cmake na vsechno a sem s tim celkem spokojenej. qmake pouzivam jenom na vybuildeni qt.

to jejich Qt IDE je takovy vselijaky: pouzivam z toho qt creator, protoze je to o hodne mensi opruz nez to psat v kodu nebo rovnou v xml (i kdyz clovek musi obcas i to, protoze creator neumi moc dobre copy/paste slozitejsich widgetu do layoutu).
samotnyho vyvojarskyho ide se trosku vyhybam - dycky byl opruz zprovoznit/nakonfigurovat spravnej toolkit. no a hlavne programatorsky pohodli celkem zadny oproti msvc + visual assist a debugger ma taky msvc lepsi (zvlast kdyz je vybavenej natvisem, kterej lidi od qt udrzujou)
na mensi veci klidne, ale kazdej den bych s tim delat nechtel, to radsi vim/emacs + gdb...
--
btw 2017 rc mam, zkousel sem parkrat ten jejich cmake subsystem, ale asi to funguje jenom na mensich projektech, na pracovnim to doslova vyblilo nesmysl - fakt, to snad nebyl ani platnej projekt :)

co je dobry, aspon budou muset do cmake dodelat podporu pch (cmake netusi o pch vubec nic, pro nej sou to jenom prepinace, msvc je ma navic udelany trosku jinak nez gcc a dohromady to boli)

UETOYO: Nejakou dobu jsem to s tim zkousel a docela to slo. Pokud jsi zvykly na VS, tak se to da; ja jsem spis zvykly na Qt Creator. Jsou k tomu oficialni Qt VS Tools a dela se s tim dobre. Funguje bez problemu QMake projekt, CMake projekt i VS projekt vsechno s Qtem. Kdyz mas stazene zdrojaky, tak se to da Qt i krasne debugovat z VS. Za nejvetsi minus povazuju obecne nestabilitu a naprostou neintuitivnost VS. Neustale zaseky, zpomaleni, "cekani na interni procesy" apod. Nic co by souviselo s Qtem nicmene. :-) Imho je to o preferencich, jake IDE chces pouzivat a jake ti vyhovuje.

https://github.com/nlohmann/json/releases/tag/v2.1.0

Qt 5.8 released - Qt Blog
http://blog.qt.io/blog/2017/01/23/qt-5-8-released/