Příspěvky

91

Vývoj / Re:Upcasting potomka na abstrakciu

« kdy: 17. 12. 2020, 23:28:13 »

Samotné auto (u upcasted2-4) nemůže být reference. Musíš použít auto&.

Ďakujem vyskúšam.

Já bych zkusil normální IClipboardReader reader = slot; Ale nenapsal jste ani co je to za jazyk. Vypadá to sice jako C++, ale co když je to něco jiného…

Dobrý deň, toto som skúšal ako prvé, vo vyšších jazykoch to takto pekne jednoducho funguje. Ale v C++ neni vyšší jazyk a všetko mu treba pekne po lopate vysvetliť. Čo je na druhej strane aj výhoda lebo aspoň programátor pochopí ako to funguje.

Já bych zkusil normální IClipboardReader reader = slot; Ale nenapsal jste ani co je to za jazyk. Vypadá to sice jako C++, ale co když je to něco jiného…

Je to C++, takže IClipboardReader reader = slot; nebude fungovat.
IClipboardReader je abstraktní třída (interface). Nedají se od ní vytvářet instance. Jdou jenom pointery a reference. A samotná instance musí být něco odvozeného.

Fungovat bude třeba :

Kód: [Vybrat]

IClipboardReader &reader = slot;
IClipboardReader *reader = &slot;

Kód: [Vybrat]

 
IClipboardReader reader = slot;

dělá slicing. Zkopíruje bázovou třídu do nové instance. A protože je abstraktní, tak to nejde. To je ta hláška "cannot instantiate abstract class"

Pro Fortrana :

Kód: [Vybrat]

	auto upcasted2 = (IClipboardReader&)slot; // Error: 'IClipboardReader': cannot instantiate abstract class
	auto upcasted3 = std::forward<const IClipboardReader&>(slot); // Error: 'IClipboardReader': cannot instantiate abstract class
	auto upcasted4 = static_cast<const IClipboardReader&>(slot); // Error: 'IClipboardReader': cannot instantiate abstract class

dělá taky slicing. Auto dělá z referencí hodnoty, pokud se mu neřekne jinak. Dokonce bych řekl, že je to rozumné defaultní chování. C++ není Java. Chování podobné intům je žádoucí.

Druhá věc je, proč ten cast vůbec chcete ručně dělat. Volat metody předka jde i na potomkovi. A pokud budete volat nějakou funkci co bere referenci na předka, tak ten cast udělá překladač sám. Za sebe si nepamatuju, kdy jsem potřeboval ručně castit na předka. Je to fakt vzácné.

Jinak std::forward slouží k forwardování obecných parametrů a k ničemu jinému. Uvnitř je to sice cast, ale nepoužívejte to tak. Pokud nepíšete nějakou optimalizovanou ale zároveň generickou šablonu, tak forward nechcete používat. V běžném kódu se vyskytuje minimálně.

Ďakujem Vám za podrobné vysvetlenie.

Prečo to chcem pretypovať? Občas chcem pred programátorom zobraziť len metódy predka. Aby som ho nerozptyloval metódami potomka. Dajme tomu že si urobíte Modul File a v ňom funkciu File::GetStat ktorá vám vracia kompletný objekt FileStat obsahujúci info o súbore (časy modifikácie, IdSkupiny, IdJednotky, Velkosť súboru). Ale kôli užívateľskej prívetivosti si možno chcete urobiť aj wrapper File::GetTimes, od ktorého, ale programátor očakáva že bude obsahovať len časy ale už nie IdSkupiny IdJednotky a podobne. Viem že čistejší sposob by bolo ručné namapovanie objektu FileStat na FileTimes lenže takto je to jednoduchšie a hlavne omnoho rýchlejšie.

92

Vývoj / Re:Upcasting potomka na abstrakciu

« kdy: 15. 12. 2020, 01:10:08 »

Pre jednoduchšie čítanie kódu som to hodil aj na https://pastebin.com/kiwWjcd5

93

Vývoj / Upcasting potomka na abstrakciu

« kdy: 15. 12. 2020, 01:04:48 »

Dobrý deň, ako správne upcastnúť potomka na predka? Skúšal som rôzne spôsoby, ale pri väčšine som dostal chybu: Error: 'IClipboardReader': cannot instantiate abstract class. Prvý (z ľava do prava) a posledný spôsob (pointer) mi funguje. Viete mi prosím vysvetliť prečo ostatné nie? A ako sa to, upcastuje správne (ale z prava do ľava)?

Kód: [Vybrat]

using binaries = std::vector<char>;

class IClipboardReader
{
public:
	virtual binaries Read() const = 0;
};

class IClipboardWriter
{
public:
	virtual void Write(binaries bins) = 0;
};

class ClipboardSlot : public IClipboardReader, IClipboardWriter
{
public:
	binaries Read() const override
	{
		// ...
		return { 'a', 'b', 'c' };
	}

	void Write(binaries data) override
	{
		// ...
	}
};

template<typename CharType = char>
std::basic_ostream<CharType>& operator<<( // vypisanie vectoru
	std::basic_ostream<CharType>& out,
	const std::vector<CharType>& value
)
{
	for (auto& c : value) out << c; return out;
}

void main()
{
	auto slot = ClipboardSlot();
	IClipboardReader& upcasted1 = slot; // OK
	auto upcasted2 = (IClipboardReader&)slot; // Error: 'IClipboardReader': cannot instantiate abstract class
	auto upcasted3 = std::forward<const IClipboardReader&>(slot); // Error: 'IClipboardReader': cannot instantiate abstract class
	auto upcasted4 = static_cast<const IClipboardReader&>(slot); // Error: 'IClipboardReader': cannot instantiate abstract class

	auto slotPtr = std::make_shared<ClipboardSlot>();
	auto upcasted5 = static_cast<std::shared_ptr<IClipboardReader>>(slotPtr); // OK

	std::cout << "upcasted1:" << upcasted1.Read() << std::endl; 
	std::cout << "upcasted2:" << upcasted2.Read() << std::endl;
	std::cout << "upcasted3:" << upcasted3.Read() << std::endl;
	std::cout << "upcasted4:" << upcasted4.Read() << std::endl;
	std::cout << "upcasted5:" << upcasted5->Read() << std::endl;
}

94

Vývoj / Re:C++ inicializácia immutable typov

« kdy: 13. 12. 2020, 22:45:14 »

Bohužel nelze kombinovat uživatelský konstruktor a inicializaci jako v C (aggregate initialization).

https://en.cppreference.com/w/cpp/language/aggregate_initialization

An aggregate is one of the following types:
class type (typically, struct or union), that has
no user-declared or inherited constructors

Šlo by to obejít vytvořením statické metody místo konstruktoru, např.:

Kód: [Vybrat]

struct FileTimesInfo
{
    const __time64_t LastAccessTime;
    const __time64_t LastModificationTime;
    const __time64_t LastStatusChangeTime;

    constexpr static FileTimesInfo create(const struct _stati64& stat) noexcept
    {
        return FileTimesInfo{
                 .LastAccessTime = stat.st_atime,
                 .LastModificationTime = stat.st_mtime,
                 .LastStatusChangeTime = stat.st_ctime
               };
    }
};

Vďaka za tento hack príznam sa že ma to ani nenapadlo aj keď som to v iných jazykoch občas používal. A ďakujem aj za informáciu, že to nejde, ostáva len dúfať že to zase opravia v > 20 verzii C++. V iných jazykoch sa objekty takto dajú bežne inicializovať a funguje to aj keď majú custom konštruktor, napr. C#:

Kód: [Vybrat]

class SomeComponent
{
    public string Status { get; private set; }
    public bool IsEnabled { get; set; }
    public SomeComponent(string status)
    {
        Status = status;
        IsEnabled = false;
    }

    public void DisplayStatus()
    {
        Console.WriteLine(
            IsEnabled
                ? "Enabled with status: " + Status
                : "Disabled"
        );
    }
}

var abc = new SomeComponent("Abc") { IsEnabled = true };
abc.DisplayStatus();

[quote author=mjakl link=topic=23970.msg341350#msg341350 date=1607508960]
Potřebujete constructor, co bere std::initializer_list.
[/quote]

Initializer list má template parameter a keď chcete inicializovať viac typov tak čo mu predáte? Okrem toho skúšal som to a nepodarilo sa mi to zfunkčniť takým spôsobom ako som načrtol v prvom poste.

95

Vývoj / C++ inicializácia immutable typov

« kdy: 09. 12. 2020, 01:04:55 »

Na úvod len spomeniem že používam najnovšiu verziu C++ kompilátr čisatočne podporuje C++ 20, ktorá ešte tuším ani neni hotová, ale niektoré časti normy sú už známe a všetky najrzšírenejšie C++ kompilátory ju do určitej miery podporujú... To čo tu rozoberám je súčasťou C++ 20... a teraz k veci.

Mám takýto typ:

Kód: [Vybrat]

struct FileTimesInfo
{
	const __time64_t LastAccessTime;
	const __time64_t LastModificationTime;
	const __time64_t LastStatusChangeTime;
};

ktorý vieme inicializovať takto (namiesto núl si tam doplnte hodnoty aké chcete):

Kód: [Vybrat]

auto ti = FileTimesInfo{ .LastAccessTime = 0, .LastModificationTime = 0, .LastStatusChangeTime = 0 };

keď ale typu pridám nejaký konštruktor napr.

Kód: [Vybrat]

struct FileTimesInfo
{
	const __time64_t LastAccessTime;
	const __time64_t LastModificationTime;
	const __time64_t LastStatusChangeTime;

	FileTimesInfo(struct _stati64 stat) :
		LastAccessTime(stat.st_atime),
		LastModificationTime(stat.st_mtime),
		LastStatusChangeTime(stat.st_ctime)
	{
	}
};

Tak sa dá inicializovať len cez ten nadefinovaný konštruktor. Ale už ho neviem inicializovať tak ako pred tým:

auto ti = FileTimesInfo{ .LastAccessTime = 0, .LastModificationTime = 0, .LastStatusChangeTime = 0 };

Prečo to tak je? a ako tento problém napraviť tak aby som mohol inicializovať triedu oboma spôsobmi? Aj cez custom konštruktor aj cez inializátor? Teraz si len domýšlam... moj predpoklad je že keď v C++ nenadefinujem žiadny konštruktor C++ nadefinuje nejaký implicitný defaultný konštruktor, ktorý umožňuje atribúty inicializovať priamo cez inicializátor. keď ale explicitne nadefinujem konštruktor prídem o ten implicitný ktorý C++ vytvára automaticky. Ako teda triede definovať custom konštruktor pričom nechcem prísť aj o tú formu priamej inicuializácie cez membery? Vopred ďakujem za vysvetlenie.

96

Hardware / Re:Otázky na audiofilov - načo sú optické audio výstupy a káble toslink?

« kdy: 02. 12. 2020, 14:34:40 »

Dobe vedieť. Ďakujem Vám obidvom za informácie.

97

Hardware / Otázky na audiofilov - načo sú optické audio výstupy a káble toslink?

« kdy: 02. 12. 2020, 13:58:53 »

Moja PCIe zvukovka Sound Blaster Z má okrem analógových vstupov a výstupov (5 jackov) aj dva digitálne. Googlil som si čo to je. Ale moc nechápem ako by som to mohol využiť? K zvukovke mám pripojenú takú vežičku so zosilovačom subwooferom a dvomi reprákmi (len 2.1, lebo 5.1 by sa mi do kanclu nezmestilo) ale tá veža nemá optický vstup (len RCA). Takže ju mám so zvukovkou prepojené analógovo jack a potom redukcia na RCA.

Keby som si kúpil toslink kábel a pripojil naň nejaký D/A prevodník a na to pripojol RCA a viedol to do veže získal by som tým niečo? Akú výhodu má ten toslink? Teda tuším že asi bude menenj náchylný na rušenie keďže je vedený opticky a ešte digitálne. Takže na to nebudú mať vplyv typické rušenia. Ale zase ten analógový kábel neni ničím rušený. A myslím že už aj tá zvukovka má v sebe zabudovaný dosť kvalitný D/A prevodník.

Joo a ešte doplňujúca otázka nedávno som si nakupoval rôzne zbytočnosti a kúpil som aj 2 elektrónkové predzosilovače. Má to zmysel pripojiť na vstup tej veže? Počul som že elektrónky majú úplne iný zvuk (iné skreslenie) ako polovodiče (lampový zvuk) a že je to oveľa príjemnejšie na počúvanie. Keď si to pripojím na vstup tej veže získam tým nejakú výhodu? Alebo načo by som to mohol využiť ešte? Na vianoce plánujem postaviť vlastný audiosystém založený RPI 4 tam by to mohlo mať využitie?

98

Windows a jiné systémy / Re:RIM OS 10

« kdy: 30. 11. 2020, 22:39:04 »

Nic s QNX se ven nedostane, ani kdyby peklo zmrzlo. Ani jsem nevěděl, že to teď vlastní BlackBerry.

QNX v embedded má podobné jméno, jako Oracle v IT. Na prvním místě prachy, NDA, svázat zákazníky, až potom možná nějaká technologie. Používá se to v různých mission critical věcech včetně automotive, i když je to na ústupu (z FOSS je často vidět FreeRTOS, neb má certifikace, a stále víc Linux).

Vďaka za informácie. Hej kúpilo to BB už cca 6-7 rokov dozadu. Urobili tomu vlastnú dotykovú grafickú nadstavbu a predávali to ako BB 10 OS (predchádzajúce verzie BB OS neboli postavené na QNXe) dali sa s tým kúpiť aj telefóny (Blackberry Z10 a Q10 a aj nejaký Blackberry tablet). Ja som mal Z10. Pri ďalšej generácii - BB Passporte už bolo na výber či chcete QNX alebo Android. A pri ďalších modeloch už bol k dispozícii len Android. Takže svoj OS v mobilných zariadeniach postupne pochovali. Ovládanie bolo trošku zvláštne všade sa používali gestá. Teraz keď som si po rokoch nabil a zapol Z10 tak mi chvíľu trvalo kým som si spomenul ako sa to ovláda.

99

Windows a jiné systémy / Re:RIM OS 10

« kdy: 29. 11. 2020, 22:58:39 »

Ahá tak pozerám že nie som prvý koho to napadlo https://forums.crackberry.com/general-blackberry-news-discussion-rumors-f2/make-bb-os-os-10-open-source-1168675/ 
 
Problém je s tým že OS QNX je stále používaný :/ takže môj nápad bol veľmi naivný.

100

Windows a jiné systémy / Re:RIM OS 10

« kdy: 29. 11. 2020, 22:46:12 »

K 31.12.2019 OS 10 asi definitivně zařízli. Poslední telefon na tom OS uvedli na jaře 2015 (BB Leap) a další už jsou na Androidu. Škoda, také mi OS10 vyhovuje a řeším kam se hnout z dodělávajícího BB Classic.

Ďakujem za odpoveď. Škoda mohli ten OS dať k dispozícii aspoň, pre arm dosky, idem napísať do Blackberry že či ten OS nechú dať k dispozícii aspoň pre komunitu nadšencov. Aj keď pochybujem že mi odpíšu Lebo je to naozaj pekný moderný OS s designovo pekným rozhraním.

101

Windows a jiné systémy / Jak dopadl vývoj RIM OS 10?

« kdy: 29. 11. 2020, 21:53:34 »

Ahojte chcem sa opýtať ako dopadol vývoj RIM OS 10. Ešte sa niekde používa, alebo jeho vývoj BB úplne zastavil? Kedysi som mal jedno zariadenie s týmto OS od Blackberry vlastne ho ešte mám niekde odložené aj keď baterka je už asi pokazená, resp polofunkčná.

Ten OS mi prišiel ako zaujímavá alternatíva k Androidu. Užívateľské rozhranie bolo veľmi pekné prívetivé dotykové. A pod kapotou to malo zaujímavý podvozok: Unixový OS QNX mikrojadrom a s rôznymi vymoženosťami, ktoré nemá Linux ani Windows a konkurovať mu z časti môže len Mac OS. Dá sa tento OS niekde stiahnuť. V poslednej dobe sa hrám s rôznymi ARM boardmi dalo by sa niečo také na nich rozbehnúť?

Napríklad teraz mám v pláne urobiť jeden audiosystém s elaktrónkovým zosilovačom chcem tomu spraviť dotykový display a tam by sadol takýto systém s dotykovým ovládaním ako riť na šerbel. Prípadne poradte ešte nejaký iný zaujímavý OS alebo dotykové rozhranie na linux. Linux je síce fajn ale taký Raspbian alebo Armbian sa na ovládanie prstami moc nehodí.

102

Vývoj / Re:Pár otázok na C++

« kdy: 21. 11. 2020, 14:56:04 »

Teda mě přijde, že když vkládáš \n, tak bych očekával platformově závislé chování. A když chci platformově nezávislé, tak budu dávat \x0D, \x0D\x0A, \x0A. A ano, jsem si vědom toho, že to není úplně übr logické, ale skutečně to tak vnímám.

\r = \x0D
\n = \x0A

Či do texťáku vložíš \n alebo \x0A je úplne jedno (je to to isté) STL ti tam (na platforme windows) namiesto \x0A práskne \x0D\x0A (skúšal som to pre istotu). Ono v retazci máš uložené naozaj len \n (resp \x0A) ale wofstream ti pri ukladaní do súboru pridá pred \n aj \r.

...

Ďakujem vyskúšam. Porovnám s mojim riešením.

...

jo tiež sa snažím predalokovať velkosť (ak sa to dá), ale nie vždy sa to dá.

prej to funguje i vobráceně jakože když soubory pak bude ifstream číst v textovým režimu tak zase ty platform specific zakončovadla bude nahrazovat jenom vobyč '\n'

nóó takže jestli jako nějak nestěhuješ ty vyrobený soubory mezi různejma platformama tak by to jako nemuselo vadit moc že si tam ve win bude připisovat ty '\r'

Ale môžu nastať aj situácie kedy chceš mať možnosť voľby medzi \n a \r\n napríklad ak by si programoval editor, alebo konvertor. Preto ma zaujíma či má tento problém nejaké jednoduché riešenie. Neni to pre mňa teraz otázka života a smrti , ale raz možno bude. Robím si totiž takú sadu helperov nad STL a tie chcem mať podľa možnosti čo najuniverzálnejšie.

103

Vývoj / Pár otázok na C++

« kdy: 20. 11. 2020, 23:30:05 »

Ahojte mám pár otázok na STL. Ako donútiť ofstream aby namiesto \n nevkladal platformovo špecifické konce riadkov?

Keď do textového súboru (na platforme windows) ukladám \n, vloží sa automaticky \r\n teda namiesto 1 znaku vloží 2 ASCII znaky (0x0D 0x0A) niekto si povie, že riešim hovadiny, ale ja chcem mať kontrolu nad tým čo ukladám a u tak low level jazyka ako C++ človek očakáva že v základnej knižinici nebude podobná mágia (volitelne nech tam kludne je, ale rád by som mal možnosť to ovplyvniť, chcem aby keď aplikáciu preportujem na linux tak bude mať jednotné na vlas rovnaké chovanie s windows verziou). Viete mi poradiť ako by sa to dalo ovplyvniť? viem že v režime binary to bude ukladať korektne (znak \n ako \n) akurát neviem či mi pri binárnom móde bude fungovať aj ofstream.imbue(znaková sada).

Vopred ďakujem za tipy.

A keď už som založil toto fórum tak sa opýtam aj ďalšiu vec. V C# a Jave existuje trieda StringBuilder určená na spájanie veľkých reťazcov. Mala by ušetriť performance keďže v .NETe sú reťazce immutable a string builder je mutable.

Čo sa používa na spájanie reťazcov v C++? Bude std::string.append dostatočne efektívne aj keď budem spájať dajme tomu 100000 reťazco? Keďže v C++ sú reťazce mutable asi by to nemal byť problém nie? Na stackoverflow programátori odporúčajú na spájanie reťazcov std::stringstream čo je fajn objekt (aj ho občas použijem) ale niekde som čítal že má horší performance. Viem že najlepšie bude alokovať pamať a do pointeru pridať znaky priamo. Ale to je náchylné na chyby hlavne keď sa pracuje s wchar_t alebo inými charmi tak treba prerátavať velkosť a myslieť na znak \0 atď. Takže priamej práci s pamaťou sa chcem podľa možnosti vyhnúť (ak to neni nevyhnutné) a použiť ho len vo výnimočných prípadoch tam kde sa naozaj šetrí každá pikosekunda.

A keď už sme pri tom meraní efektivity čo používate na jej meranie?

1. Používate nejaký vlastný benchmark postavený na std::high_resolution_clock pustené v cykle?

2. alebo profiler?

3. Alebo nejaký špeciálny benchmark?  Ja som našiel toto: https://github.com/chronoxor/CppBenchmark a toto https://github.com/google/benchmark má to cenu kompilovať?

104

Vývoj / Re:Discriminated unions v C++

« kdy: 25. 10. 2020, 15:20:40 »

Konečne som sa zase dostal k C++ idem si teda prejsť aj Vaše odpovede a vyskúšam príklady čo ste sem poslali. Minule tu niekto písal že typ variant môže uložiť aj hodnoty rovnakého typu a mal pravdu (takže to čo som napísal v prvom poste že variant nemôže obsahovať rovnaký typ bol omyl spôsobený mojou nepozornosťou). Takže pomocou typu variant sa dajú nasimulovať aj discriminated unions. Včera v noci som to skúšal. Ako ste tu spomínali pattern matching síce C++ nemá, ale nahradil som ho obyčajným switchom a ten prvý príklad som prepísal takto: https://pastebin.com/CFykWbWQ resp aj nižšie, ale na pastebin je syntax highlighter, takže sa to lepšie číta.

Kód: [Vybrat]

#include <iostream>
#include <variant>
#include <vector>
#include <map>
#include <algorithm>
#include <iterator>

// operator pre vypisani mapy
template <typename K, typename V>
std::ostream& operator<<(std::ostream& out, const std::map<K, V>& vec)
{
	out << "vector<T>[";
	auto delimiter = false;
	for (const auto& item : vec)
	{
		if (delimiter = true)
		{
			out << ", ";
		}
		out << item.first << ": " << item.second;
	}
	out << "]";
	return out;
}

const auto usdEurCourse = 1.19;
const auto usdBtcCourse = 0.000076;

typedef std::tuple<std::string, double> AnotherTuple;

typedef std::variant<
	/*USD*/ double,
	/*EUR*/ double,
	/*BTC*/ double,
	/*Another*/ AnotherTuple
> currency;

enum
{
	USD,
	EUR,
	BTC,
	Another
};

auto comodityMarketsValues = std::map<std::string, currency>{
	{ "Gold", currency{ std::in_place_index<USD>, 5.75 } },
	{ "Platinium DAX", currency{ std::in_place_index<EUR>, 5.23 } },
	//{ "FSTE Oil", currency{ std::in_place_index<Another>, AnotherTuple{ "GBP", 1023.22 } } },
};

double toUSD(currency curr)
{
	switch (curr.index())
	{
	case USD: return std::get<USD>(curr);
	case EUR: return std::get<EUR>(curr) * usdEurCourse;
	case BTC: return std::get<BTC>(curr) * usdBtcCourse;
	default: throw std::runtime_error("Unsupported currency");
	}
}

int main()
{
	std::map<std::string, currency> comodityMarketsValuesInUSD;

	std::transform(
		comodityMarketsValues.begin(),
		comodityMarketsValues.end(),
		std::inserter(comodityMarketsValuesInUSD, comodityMarketsValuesInUSD.begin()),
		[](std::pair<std::string, currency> nameCurrPair) -> std::pair<std::string, currency>
		{
			return std::pair<std::string, currency>(
				nameCurrPair.first,
				currency{ std::in_place_index<USD>, toUSD(nameCurrPair.second) }
			);
		}
	);
}

Niekto ste tu spomínal, že sa tomu nehovorí discriminated unions, ale variant. Mne na až tak nezáleží na názvosloví (v každom jazyku sa to volá trošku inak, C++ má na veľa jazykových prvkov vlastné názvy). Ide o to aby som dosiahol v praxi podobný efekt.

Ale ajtak Discriminated Union mi príde celkom výstižný názov. Lebo v OCAML sa tým tagom hovorí discriminator. A historicky discriminated unions vychádzajú z únií. Ale na githube som videl aj názvy tagged union. V každom prípade sú to algebraické dátové typy. std::variant dokáźe to isté, len má o niečo menej prehľadnú syntax (nevidím na prvý pohľad aký tag je priradený ku ktorému typu) a treba si trošku pomôcť enumeráciami ako vidím aj vo Vašich príkladoch.

Ďakujem aj Baloun echo_zulu, Wrána diskuse a ďalším za príklady, idem si ich teraz prejsť a vyskúšať a som zvedavý akým spôsobom sa líša o môjho príkladu.

105

Vývoj / Re:Discriminated unions v C++

« kdy: 23. 10. 2020, 23:56:58 »

Dobrý deň, ďakujem Vám za odpovede. Zatiaľ som ich preletel len veľmi rýchlo. Zajtra si ich prečítam a poodpisujem. (Doteraz som kôli práci nestíhal).

Len v skratke: viem, že existuje viacero spôsobov, ako niečo podobné docieliť a tiež viem, že sa to dá spraviť aj flexibilnejšie. Bol to len príklad, ktorý ma v rýchlosti napadol pre vysvetlenie aby ste pochopili ako to funguje a čo vlastne v C++ hľadám. Sú veci na, ktoré sa discriminated unions hodia. Už len taký typ option(v haskelli sa mu hovorí maybe) je discriminated union:

Kód: [Vybrat]

type Option<'t> = 
| Some of 't
| None

alebo si môžete nadefinovať typ:

Kód: [Vybrat]

type LoginResult = 
| Auth of {| Uid : int64; Login : string; Password : string; FirstName : string; Roles : Roles; Profile : Profile |}
| InvalidField of int * string * string
| Error of int * string

A vyhnete sa tak používaniu výnimiek

alebo si môžete vytvoriť rekurzívnu discriminated union

Kód: [Vybrat]

type MultiTree<'a> =
| Leaf of 'a
| Node of MultiTree<'a> list

prípadne

Kód: [Vybrat]

type ast =
| Nil
| Unit
| Identifier of string
| IdentifiersPath of string list
| Block of ast list
| ExprList of ast list
| Root of ast list
...

Pointa je, že by som potreboval niečo, čo sa vzdialenie podobá na úniu z Ocaml, dá sa do nej vložiť napríklad aj viacero typov, ale nechcem aby únia rozlišovala hodnoty podľa typu, ale podľa tagu.

S tým zadrátovaním máte pravdu, tento príklad by som v praxi aj ja riešil inak.

Že sa niečo v Ruste dá riešiť elegantnejšie viem. Rust je veľmi pekný jazyk. Ja tiež používam jazyky z rodiny ML, ktoré sú ideálne na rýchly vývoj aplikácií a v ktorých je radosť programovať, ale C++ baví z viacerých dôvodov (je univerzálne, je rozšírené, dá sa tam hrať z detailami a optimalizovať, je to hlavný jazyk pre Unreal Engine, je to jazyk orientovaný na rýchlosť, nič pred programátorom neskrýva atď). Ale máte pravdu, že má aj veľa nedostatkov.