Rozdělovat pochvaly jsi začal ty, proto ta jízlivost ode mě (skutečně asi trochu přehnaná).
...
Bohužel, v C++ praxi se zdá, že takový std::variant je natolik nepraktický na používání, že je lepší ty typy nějak odlišit (tagování, wrapnutí).
Neviem, či som udeľoval pochvaly, do tejto diskusie som sa zapojil až po odpovedi #5, ktorá začína zamyslením nad nevyslovenou otázkou prečo v tomto ľudia tápajú a prečo je v tých odpovediach zmätok. Z odborného hľadiska. Pridal som stručne napísaný postreh, ktorý si myslím, že vôbec nie je nerelevantný a to nie len v tejto diskusii. No a nad rámec toho som uviedol, čo sú dobré odpovede plus to, že v #5 je pekný kód.
A s pochvalou pre teba je to trochu naopak. Všimol som si hneď na začiatku ten tvoj súcitný povzdych nad programátormi v C++, a aj keď ma taká starostlivosť naozaj dojala, tak si myslím, že to nie je vôbec na mieste. Zvlášť ak sa orientuješ, ako si písal v tej istej vete, podľa odpovedí na otázky v "nejakom" anonymnom fóre a nie podľa aktuálnej odbornej literatúry alebo prednášok z CppCon. Chápem a dúfam, že to bol viac menej nevinný vtip, ale aj tak...
Navyše za posledné asi 4 roky sa podľa nejakej štatistiky, čo som narýchlo našiel, počet programátorov v C++ zmenil z 4,4 mil na 5,4 mil, čo je prírastok asi 23%. To si naozaj myslíš, že na svete pribudlo za niekoľko málo rokov milión masochistov? A som skoro presvedčený, že s C++20 to bude ešte rásť, dokonca pravdepodobne rapídnejšie, pretože objemovo, z hľadiska nových vecí, je v C++20 tuším väčší prírastok ako bolo v C++11 a už to bolo veľkou vecou.
Normálne by som sa voči takej neprístojnosti ohradil, takéto poznámky iba vnášajú do komunity chaos a nerešpekt k práci a rozhodnutiam iných ľudí, veď to vidíš v niektorých ďalších odpovediach. Pritom námietky pochádzajú väčšinou z neznalosti aktuálneho stavu alebo z málo informovaných a vzdelaných komunitných zdrojov.
Že si prejavil aj snahu odpovedať k veci som si všimol, tak som si povedal, že ten mínus je vyvážený plusom.
Ale tým plusom sa znamienka navzájom iba vyrušili, ostala neutralita, tak mi nenapadlo, že by som ťa mal nejako osobitne chváliť alebo vyjadriť, že teba sa moja poznámka netýka. To by som musel písať oveľa dlhšiu odpoveď a to je strašne veľa práce. Videl si predsa vyššie ako by vyzerala moja štandardná odpoveď na túto otázku, nie? Pár slov.
Čo sa tvojej odpovede týka, tak z môjho pohľadu, hoci je to informácia vedúca k odpovedi nejakému riešeniu, je to stále iba časť a to riešenie, ku ktorému to vedie nie je idiomatické pre C++ a ani pre ten spôsob programovania, ktorý má pôvodca otázky v zadaní ako zdôvovnenie prečo to vlastne potrebuje.
On má totiž jeden problém a to je ten, že z dvoch základných aspektov jeho otázky, ktorými sú "čo chcem dosiahnuť" a "akými prostriedkami to chcem dosiahnuť", u ktorých sa ukázalo, že sa nedajú oba realizovať súčasne, kladie dôraz na to menej dôležité, teda na tie prostriedky, resp. jeden z nich, ten najmenej dôležitý.
Záleží samozrejme aj na tom ako si kto interpretuje to "čo chcem dosiahnuť". Keď sa pozriem na jeho prvotný kód, tak tam vidím sumárny typ, ktorý on považuje za primárny, ale som si vedomý aj toho, že je tam aj mechanizmus spracovania, kde je použitý funkcionálny prístup k programovaniu, náhrada cyklu štandardným algoritmom a potom ešte náhrada riadiacich štruktúr ako if a switch rozoznávaním vzorov pri vyhodnocovaní položky v kontajneri jednotlivých mien.
No a pre mňa je z tohto podstatný ten mechanizmus spracovania a sumárny typ ako taký je iba jeden z prostriedkov ako ho dosianuť.
V tom jeho príklade hneď hore nikde nie je explicitné vyťahovanie hodnôt z toho sumárneho typu podľa tagov, ktoré pôsobia ako diskriminátory. Tie sa používajú na pozadí automaticky počas spracovania rozoznávaním vzorov zabudovaným v jazyku, ktorý je použitý. Sú uvedené v definícii tej funkcie, jazyk si to správne ošetrí a programátor nemusí podľa diskriminátora hľadať hodnotu a niečo s ňou robiť.
Áno, samozrejme, v C++ sa to dá naprogramovať s opakovaním jedného typu niekoľkokrát a použitím indexu vo variante v kombinácii s príkazom switch, tak ako to PO urobil vo svojom poslednom príspevku, teda predtým ako si podrobnejšie prečítal tieto odpovede. Tým ale do značnej miery opustil štýl kódu, ktorý uviedol ako príklad a vrátil sa späť k štrukturálnemu prístupu, pričom jeho momentálne riešenie nie je ani kompaktnejšie, ani prehľadnejšie ani bezpečnejšie. Myslené v kontexte reálnej aplikácie, ktorá má nejaký rozsah, niečo naozaj robí, s ohľadom na modifikácie v budúcnosti a nie iba v kontexte triviality, ktorú vmestíš na dve obrazovky.
Takýto odklon od jedného prístupu k druhému mi nedáva vôbec zmysel a ten odklon nastal iba preto, lebo PO tvrdošijne vyžaduje, aby tagovaný typ bol ten sumárny a nie typy, ktoré sú v ňom vložené, pričom ale návod ako sa to idiomaticky robí v C++ dostal už v odpovedi #1.
Navyše, nikde nie je napísané, že diskriminátor musí byť explicitný. Môže byť implicitný, vo forme samotného zložkového typu. Mechanizmus vyhodnotenia rozoznávaním vzorov, aj jeho náhrada, si to aj tak bezproblémovo priradí.
Bez toho, aby som niečo o OCaml vedel, nebol by som vôbec prekvapený, keby OCaml vnútorne ten zápis jednotlivých zložiek sumárneho typu previedol na samostatné zložkové typy a tie vnútorne použil ako diskriminátory namiesto tagov, a teda pri volaní funkcie by vzor nevyhodnocoval podľa tagu, ale podľa toho interného zložkového typu.
Takže podľa mňa existuje určitá pravdepodobnosť, že to, čo je v C++ ako tag v zložkovom type uloženom v sumárnom type a to, čo je v OCaml ako tag v sumárnom type pri zložkovom type, sú iba dva rôzne zápisy toho istého, pričom uznávam, že ten zápis v OCaml je kompaktnejší a že esteticky vyzerá lepšie.
Ale to je jedno, to je implementačný detail jazyka, podstatné je, že v oboch prípadoch funguje požadovaný mechanizmus, že zápis aj funkčnosť sú principiálne podobné a aj keď to, čo je v C++ sa oficiálne neoznačuje ako rozoznávanie vzorov, (keďže nie je zabudované priamo v jazyku v rozsahu ako je bežné v iných jazykoch a keďže nejaké návrhy na to pravé zabudované riešenie sú vo vyhodnocovaní v rámci pracovných skupín pri ISO), stále to ako rozoznávanie vzorov funguje, rozhodne aspoň ako jeho značná podmnožina.
Táto forma rozoznávania vzorov bola v C++ vždy a je realizovaná bežným preťažením funkcií.
Toľko z môjho pohľadu. Tvoj môže byť iný a možno nám aj vysvetlíš ako sa sumárny typ s opakovaným typom používa v Rust-e a aké je to praktické.