Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: anonym 10. 01. 2017, 03:27:38

Název: Automatické uvolňování paměti v c++
Přispěvatel: anonym 10. 01. 2017, 03:27:38
Co brání v C++ tomu, aby byly do kódu vloženy automaticky řádky pro uvolnění již nevyužitelných zdrojů v čase kompilace? Je to pŘece deterministický úkol, až na nějaké speciální případy je známo, kde je potřeba paměť uvolnit. Proč to teda musí programátor psát ručně?

A z jiného soudku, proč má třeba Java ještě pořád GC, když uvolňování zdrojů lze předvídat už v čase kompilace? GC přece zbytečne spotřebovává paměť a čas procesoru, tak nač?

Příklad kde to už existuje: Objective-C a Automatic References Counter.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: anonym2 10. 01. 2017, 04:46:26
Máte na mysli něco jako unique_ptr/shared_ptr rozšíření v C++11?

https://en.wikipedia.org/wiki/Smart_pointer
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Kdo iv 10. 01. 2017, 07:15:04
Co brání v C++ tomu, aby byly do kódu vloženy automaticky řádky pro uvolnění již nevyužitelných zdrojů v čase kompilace? Je to pŘece deterministický úkol, až na nějaké speciální případy je známo, kde je potřeba paměť uvolnit. Proč to teda musí programátor psát ručně?

A z jiného soudku, proč má třeba Java ještě pořád GC, když uvolňování zdrojů lze předvídat už v čase kompilace? GC přece zbytečne spotřebovává paměť a čas procesoru, tak nač?

Příklad kde to už existuje: Objective-C a Automatic References Counter.

Nekde uz tu bylo tema na GC a RC potazmo ARC, doporucuji si to nastudovat a pochopit o co jde nez budete psat tyto ne zcela spravne uvahy.

ARC neni bez rezie (muze mit horsi vliv na vykon jak GC), jedna se porad o normalni reference counting, takze je stale potreba resit smycky atd, takze tam stejne bude potreba nejakeho maleho GC, no a pokud mam byt presny tak ARC je porad forma GC ;).
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Kamil Podlešák 10. 01. 2017, 07:55:39
Jenom taková myšlenka po ránu: existence kompilátoru který obecně dokáže říct kdy se uvolňí paměť na heapu - nedá se to náhodou převést na Halting problem?
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Sten 10. 01. 2017, 08:38:26
Co brání v C++ tomu, aby byly do kódu vloženy automaticky řádky pro uvolnění již nevyužitelných zdrojů v čase kompilace? Je to pŘece deterministický úkol, až na nějaké speciální případy je známo, kde je potřeba paměť uvolnit. Proč to teda musí programátor psát ručně?

Ale vždyť to tam už dávno je. Jmenuje se to RAII.

A z jiného soudku, proč má třeba Java ještě pořád GC, když uvolňování zdrojů lze předvídat už v čase kompilace? GC přece zbytečne spotřebovává paměť a čas procesoru, tak nač?

Protože to lze předvídat jen někdy. I JVM umí uklidit lokální objekty bez GC.

Příklad kde to už existuje: Objective-C a Automatic References Counter.

ARC je reference counting. To se nedokáže uklidit, pokud vytvoříte cyklus.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: nou 10. 01. 2017, 09:40:53
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: noname 10. 01. 2017, 13:39:52
ARC je reference counting. To se nedokáže uklidit, pokud vytvoříte cyklus.
Hej ale toto riesia napriklad v Swifte rozne typy referencii (weak, strong, unowned) a je to jedna z veci, na ktore treba davat pozor, kazdopadne ak si da programator pozor na cykly ARC funguje perfektne.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Kdo iv 10. 01. 2017, 13:49:21
ARC je reference counting. To se nedokáže uklidit, pokud vytvoříte cyklus.
Hej ale toto riesia napriklad v Swifte rozne typy referencii (weak, strong, unowned) a je to jedna z veci, na ktore treba davat pozor, kazdopadne ak si da programator pozor na cykly ARC funguje perfektne.

No a o tom to prave je, v podstate co se spravy pameti tyce tak je treba si davat pozor, nebo mit jazyk ktery dava pozor za vas a umi vam vynadat.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: anonym 10. 01. 2017, 14:23:15
Ok takže pojďme předpokládat, že dát si pozor není možné. Na větším projektu nikdy nebude aplikace bez chyb. Takže jak na beton vyřešit správu paměti, nebo jak se tomu co nejvíc přiblížit, a to pomocí nějakých sw nástrujů? Dát si pozor moc nestačí.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: lopata 10. 01. 2017, 14:36:15
Takže jak na beton vyřešit správu paměti, nebo jak se tomu co nejvíc přiblížit, a to pomocí nějakých sw nástrujů? Dát si pozor moc nestačí.

Testovat... Valgrind toho chytí hodně, memory leaky i neuvoněnou paměť stále drženou procesem.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: fe 10. 01. 2017, 15:55:02
Ad Swift vod shnilýho a červy prožranýho jabka v teplým županu:
https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memory-management-method-of-garbage-collection-like-in-Java
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: ferren 10. 01. 2017, 16:25:39
osobne myslim ze se obecne automaticke nastroje pro uvolnovani pameti precenuji....a naopak, C se kvuli tomu prehnane kritizuje.
tim nerikam ze to nic neresi, ale z praxe je vetsi problem nekvalitni/nelogicky navrh, ze se zbytecne udrzuji v pameti data zbytecne, bud zbytecne dlouho, nebo prehnane dimenzovane, nevhodne strukturovane, s tim ze je to samozrejme z pohledu jazyka validni,platne tj jakoukoli automatikou neresitelne.
casteji pozoruju stovky MB takto prosustrovane a leaky ve smyslu par kB...
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Ivan 10. 01. 2017, 16:34:57
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.

Jen dodam, ze thread-safe reference counting ma jeste vetsi overhead. A tady uz tezko muze kompilator rozhodnout jak a jestli vubec zamykat.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: zboj 10. 01. 2017, 17:44:41
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.

Jen dodam, ze thread-safe reference counting ma jeste vetsi overhead. A tady uz tezko muze kompilator rozhodnout jak a jestli vubec zamykat.
Ten overhead závisí na konkrétní architektuře, některé to umí hodně rychle. Navíc překladač (resp. optimizér) často pozná, že není nutné RC měnit (obdoba escape analysis).
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: j 10. 01. 2017, 18:04:51
... Je to pŘece deterministický úkol, až na nějaké speciální případy je známo, kde je potřeba paměť uvolnit. ...

Mno ... ty bys radsi nemel zkouset ani hello world ... protoze to, jak uzasne deterministicky a primitivni to je je videt trebas v C# nebo Jave ...

Naopak, pokud nekdo chce aby aplikace fungovala s minimem zdroju, tak musi veskerou spravu zajistit prave v kodu, protoze vyhradne tvurce vi (nebo by vedet aspon mel), kde a kdy muze neco z pameti vyhodit.

A jak zminuje ferren, soudobi patlalove se spolehaj na to ze "ono se to nejak samo" a pak to vypada tak, ze i ten hello world chce 100MB RAM.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Darkhunter 10. 01. 2017, 18:42:00
Záleží, zda-li potřebuješ tolik konektorů pro disky.
Když už, tak bych šel do osmijádrový varianty:
http://www.vmshop.cz/MBD-A1SAM-2750F-O/a1sam-2758f-o-atx-avoton#ok
Nestojí o moc víc...
Samozřejmě je víc edic a modelů s osmijádrem, takže určitě něco bude mít i víc portů.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Darkhunter 10. 01. 2017, 18:48:01
Oops, sorry...Špatnej topic...
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Kdo iv 10. 01. 2017, 20:15:13
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.

Jen dodam, ze thread-safe reference counting ma jeste vetsi overhead. A tady uz tezko muze kompilator rozhodnout jak a jestli vubec zamykat.
Ten overhead závisí na konkrétní architektuře, některé to umí hodně rychle. Navíc překladač (resp. optimizér) často pozná, že není nutné RC měnit (obdoba escape analysis).

Nejaka mereni, kde se da toto overit? Ne ze bych ti neveril spis naopak (take si myslim ze by ta rezie dnes nemusela byt tak silena a ze se toho nekteri jen zbytecne moc boji).

Jinak to stim ze to eliminuje pocet incrementaci a dekrementaci je pravda ale opet nevim jak moc jsou dnesni kompilatory uspesne, vim ze je to jeden z cilu jazyka D, zlepsit statickou analyzu aby bylo mozne implementovat rychly RC, ktery zaroven bude memory safe.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: atarist 10. 01. 2017, 23:38:20
Nejaka mereni, kde se da toto overit? Ne ze bych ti neveril spis naopak (take si myslim ze by ta rezie dnes nemusela byt tak silena a ze se toho nekteri jen zbytecne moc boji).

No a nebo to taky muze dopadnou hodne spatne - cim vic jader, tim vetsi problem s tou casti kodu, ktera nepobezi paralelne. Podle me to bez spoluprace s programatorem asi nepujde. Treba Rust to resi tak, ze donuti programatora presne specifikovat, co a jak se pouziva. Potom dokaze vygenerovat efektivni kod.

Nejde ani tak o to, ze rezie jednoho atomickeho ++ nebo -- (a testu na nulu) by byla silena, ale v tom, ze se bude provadet dost casto.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Ondřej Novák 11. 01. 2017, 00:46:06
Co brání v C++ tomu, aby byly do kódu vloženy automaticky řádky pro uvolnění již nevyužitelných zdrojů v čase kompilace? Je to pŘece deterministický úkol, až na nějaké speciální případy je známo, kde je potřeba paměť uvolnit. Proč to teda musí programátor psát ručně?
Nic, tohle C++ dávno má, říká se tomu destruktor a překladač ho tam vkládá automaticky. Programátor jen napíše, jakým způsobem se ty zdroje úvolní

A z jiného soudku, proč má třeba Java ještě pořád GC, když uvolňování zdrojů lze předvídat už v čase kompilace? GC přece zbytečne spotřebovává paměť a čas procesoru, tak nač?
Skutečně? Nejsem si jist.

Příklad kde to už existuje: Objective-C a Automatic References Counter.
ARC fungují jen když sdílíte immutable objekty. Pak mohou být i MT Safe. Jakmile ale můžete dodatečně měnit linky v již vytvořených objektech, pak umíte vytvořit cyklus a ten ARC uvolnit neumí.

Mimochodem, ARC je i v C++. Buď shared_ptr, nebo se dá napsat jednoduché řešení s counterem uvnitř objektu. Oba systémy mají své výhody a nevýhody.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: zboj 11. 01. 2017, 13:17:28
Automatickemu pridanu brani "zero overhead principle" C++ ze ziadna feature nesmie brat vykon pokial ju nepouzivate. Reference counting pridava overhead takze nie je zapnuty by default.

Jen dodam, ze thread-safe reference counting ma jeste vetsi overhead. A tady uz tezko muze kompilator rozhodnout jak a jestli vubec zamykat.
Ten overhead závisí na konkrétní architektuře, některé to umí hodně rychle. Navíc překladač (resp. optimizér) často pozná, že není nutné RC měnit (obdoba escape analysis).

Nejaka mereni, kde se da toto overit? Ne ze bych ti neveril spis naopak (take si myslim ze by ta rezie dnes nemusela byt tak silena a ze se toho nekteri jen zbytecne moc boji).

Jinak to stim ze to eliminuje pocet incrementaci a dekrementaci je pravda ale opet nevim jak moc jsou dnesni kompilatory uspesne, vim ze je to jeden z cilu jazyka D, zlepsit statickou analyzu aby bylo mozne implementovat rychly RC, ktery zaroven bude memory safe.
Podrobně o tom píšou v dokumentaci k Objective-C. V jazycích majících struct pak ten problém prakticky mizí, ve Swiftu se režie neprojeví (aspoň na amd64, na ARM jsem netestoval).
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: čumil 20. 01. 2017, 21:09:24
To je nesmysl, to nejde.
Pouze čast stavu jde odhadnout za kompilace, zbytek ne protože je dán vnějšim stavem za běhu.

ARC je reference counting GC. Kompilator jen přidává reference county, nic vyc. V c++ se o to samé starají construktory a destruktory smart pointeru.

Rozhodně neexistuje GC ktere by proběhlo v compile time. Respektive, existuje.

Muselo by to ale mit schopnost predikovat budoucnost .......
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: čumil 20. 01. 2017, 21:17:15
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Bohužel, problem s cykli a stuckem když se uvolňuje velký subgraph je tam furt.

I tak, pěkná konkurence dnešním generačním tracing monstrum.

Hezkej příklad síli statické analízi.

Ale není všemocná, to už si taky jednou v intelu mysleli, a pak to radši odpískali...
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Sten 20. 01. 2017, 21:26:31
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: čumil 20. 01. 2017, 22:10:01
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.
Dělal se pokus v Jave s podobnym GC, až 90% countu se odmazalo.

Jinak říkáš nesmysl ... Scope reference, ne objektu :)
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Sten 20. 01. 2017, 22:25:32
Dělal se pokus v Jave s podobnym GC, až 90% countu se odmazalo.

Jinak říkáš nesmysl ... Scope reference, ne objektu :)

Kde [em]se[/em] ten pokus dělal? Protože Java má něco podobného tak od 5ky.

Nikoliv, scope životnosti objektu. Pokud dostaneš referenci na existující objekt, tak ji musíš inkrementovat, jelikož ta předchozí může být z jiného threadu a během tvé práce zmizet
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Sten 20. 01. 2017, 22:28:31
Mimochodem jak optimalizace reference countingu souvisí s Javou, která je nemá?
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: zboj 21. 01. 2017, 03:21:13
Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.
Swift hlavně provádí escape analýzu (podobně jako Go) a co jde, dá na zásobník. U kolekcí je navíc hodnotová sémantika a CoW. U RC se navzájem vyruší release/retain u návratu z funkce a příslušného volání, takže RC se natvrdo mění jen u unikajících referencí, typicky v případě kolekcí.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Jerry 21. 01. 2017, 09:21:45
Jestli hledáš C++, které má GarbageCollector (GC) tak je to verze ECMA C++/CLI a je normálně dostupná v MS VS 2003/5/8/10/13/15/17. Native ANSI C++ pochopitelně (GC) nemá. Takže když potřebuješ C++ s (GC) tak si musíš vybrat tu správnou verzi.  ;) Je nutné dodat, že C++/CLI je momentálně ze strany MS nepodporovaný protože má malou komunitu vývojářů a poslední plně
"funkční" verze je v MS VS 2008 C++/CLI SP2.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: čumil 21. 01. 2017, 09:41:53
Jestli hledáš C++, které má GarbageCollector (GC) tak je to verze ECMA C++/CLI a je normálně dostupná v MS VS 2003/5/8/10/13/15/17. Native ANSI C++ pochopitelně (GC) nemá. Takže když potřebuješ C++ s (GC) tak si musíš vybrat tu správnou verzi.  ;) Je nutné dodat, že C++/CLI je momentálně ze strany MS nepodporovaný protože má malou komunitu vývojářů a poslední plně
"funkční" verze je v MS VS 2008 C++/CLI SP2.
Nepotřebuješ nic od ms, to takhle boehm gc.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: čumil 21. 01. 2017, 09:46:24
Mimochodem jak optimalizace reference countingu souvisí s Javou, která je nemá?
Jdi si dozadeke stene :) přečti si wiki a neser, nechápu proč se hádáš se mnou, jdi a vysvětli tvurci toho optimalizovaneho RC že mu to prostě nemůže fungovat protože mistr sten to prostě ví líp :D

Pro tvoje info, při experimentech s gc se obvykle používá java ... A todlenc byl experiment.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: zboj 21. 01. 2017, 10:59:05
Jestli hledáš C++, které má GarbageCollector (GC) tak je to verze ECMA C++/CLI a je normálně dostupná v MS VS 2003/5/8/10/13/15/17. Native ANSI C++ pochopitelně (GC) nemá. Takže když potřebuješ C++ s (GC) tak si musíš vybrat tu správnou verzi.  ;) Je nutné dodat, že C++/CLI je momentálně ze strany MS nepodporovaný protože má malou komunitu vývojářů a poslední plně
"funkční" verze je v MS VS 2008 C++/CLI SP2.
No jo, to jde ale jen pro řízené objekty (MyOject^) a nejde to přeložit do nativního kódu. A není to multiplatformní, protože implementace je tak zprasená, že Mono nebo VM od MS na Linuxu na tom chcípne.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Jerry 21. 01. 2017, 12:17:37
tady je seznam programovacích jazyků, který podporujou CLI/CLR
https://en.wikipedia.org/wiki/List_of_CLI_languages
nevim jestli existuje seznam jazyků co maj (GC). Samozřejmě s (GC) se dělá líp protože
za tebe vyžehlí mnoho tvých chyb. Nemusíš na tim tak úzkostlivě přemejšlet. To je taky důvod proč je Java oblíbenější než native C a C/C++. Mono má verzi .NET takže je možné jej použít jak v C++/CLI tak i v C# tak i ve VisualBasicu. C++/CLI je dnes mrtvý protože "Java,Java,Java"  ;D
A dělají se v něm hlavně wrappery z native C a C/C++ do .NET pro Host-UWP ve Win10.
Velký problém (GC) je, že jaksi zpomaluje chod výsledného algoritmu. Což je ale normální protože
obecně algoritmy napsané v .NET jsou pomalejší až 4x než v např. native C/C++. Výhodou je ale
pohodlnější kodování. Takže se musíš vybrat odpovídající technologii s ohledem na zadání úlohy.
Jádro úlohy můžeš napsat např. v C nebo C/C++ a GUI pak třeba v C# nebo v Javě.

Tady máš ještě pár hezkých článku:
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memory-management-method-of-garbage-collection-like-in-Java
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: zboj 21. 01. 2017, 15:25:01
tady je seznam programovacích jazyků, který podporujou CLI/CLR
https://en.wikipedia.org/wiki/List_of_CLI_languages
nevim jestli existuje seznam jazyků co maj (GC). Samozřejmě s (GC) se dělá líp protože
za tebe vyžehlí mnoho tvých chyb. Nemusíš na tim tak úzkostlivě přemejšlet. To je taky důvod proč je Java oblíbenější než native C a C/C++. Mono má verzi .NET takže je možné jej použít jak v C++/CLI tak i v C# tak i ve VisualBasicu. C++/CLI je dnes mrtvý protože "Java,Java,Java"  ;D
A dělají se v něm hlavně wrappery z native C a C/C++ do .NET pro Host-UWP ve Win10.
Velký problém (GC) je, že jaksi zpomaluje chod výsledného algoritmu. Což je ale normální protože
obecně algoritmy napsané v .NET jsou pomalejší až 4x než v např. native C/C++. Výhodou je ale
pohodlnější kodování. Takže se musíš vybrat odpovídající technologii s ohledem na zadání úlohy.
Jádro úlohy můžeš napsat např. v C nebo C/C++ a GUI pak třeba v C# nebo v Javě.

Tady máš ještě pár hezkých článku:
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memory-management-method-of-garbage-collection-like-in-Java
Ne, C++/CLI v Monu použít nejde.
Název: Re:Automatické uvolňování paměti v c++
Přispěvatel: Jerry 21. 01. 2017, 15:49:06
tady je seznam programovacích jazyků, který podporujou CLI/CLR
https://en.wikipedia.org/wiki/List_of_CLI_languages
nevim jestli existuje seznam jazyků co maj (GC). Samozřejmě s (GC) se dělá líp protože
za tebe vyžehlí mnoho tvých chyb. Nemusíš na tim tak úzkostlivě přemejšlet. To je taky důvod proč je Java oblíbenější než native C a C/C++. Mono má verzi .NET takže je možné jej použít jak v C++/CLI tak i v C# tak i ve VisualBasicu. C++/CLI je dnes mrtvý protože "Java,Java,Java"  ;D
A dělají se v něm hlavně wrappery z native C a C/C++ do .NET pro Host-UWP ve Win10.
Velký problém (GC) je, že jaksi zpomaluje chod výsledného algoritmu. Což je ale normální protože
obecně algoritmy napsané v .NET jsou pomalejší až 4x než v např. native C/C++. Výhodou je ale
pohodlnější kodování. Takže se musíš vybrat odpovídající technologii s ohledem na zadání úlohy.
Jádro úlohy můžeš napsat např. v C nebo C/C++ a GUI pak třeba v C# nebo v Javě.

Tady máš ještě pár hezkých článku:
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memory-management-method-of-garbage-collection-like-in-Java
Ne, C++/CLI v Monu použít nejde.

samozřejmě že existuje tady si ho můžeš stáhnout:
http://www.mono-project.com/download/#download-win

funguje ok. otázka je k čemu je to dobrý ... asi k ničemu
http://www.mono-project.com/docs/gui/gtksharp/