OctaForge - nativní API a ranges v C++ (diskuse)

[Radek Miček]

Hlavní podporované kompilátory budou Clang (verze 3.3 a vyšší), GCC (verze 4.8 a vyšší) a Microsoft Visual C++ (verze 2015 a vyšší)

Z jakého zdroje je informace, že Microsoft Visual C++ verze 2015 a vyšší podporuje C++11? Ještě v listopadu to tak nebylo – viz C++11/14/17 Features In VS 2015 Preview.

Například následující kód tam nefungoval:

#include <vector>

class S { std::vector<int> v{ 1, 2 }; };

A nezdá se, že by to bylo opraveno v CTP 6.

[----]

nikde nepíšu, že podporuje celý standard... podporuje ty featury, které používám, takže to fungovat bude. viz zde

[----]

sorry, nevšiml jsem si, že je to stejný link

[Radek Miček]

Aha, špatně jsem si vyložil větu

Hlavní kompilátory už C++11 nějakou dobu podporují

Sorry.

[----]

je to částečně moje chyba, protože jsem dal dvě nezávislá tvrzení do jednoho odstavce (tzn. o tom, že hlavní kompilátory podporují C++11, a o tom, že MSVC++ bude podporovaným kompilátorem). MSVC++ kompletní standard nepodporuje, ale podporuje dostatečně kompletní subset.

[Jardík]

Tvůj kód obsahuje spoustu chyb. Např. __OctaUnaryCompare, __octa_hs_sift_down, ...

[Jardík]

Další chyba v octaforge: #define ENET_VERSION_MAJOR

[Jardík]

A další chyba jiného typu: struct _ENetHost.

[----]

a to je co za chybu?

[stativ]

První chyba je, že jména obsahující "__" nebo začínající "_" jsou rezervovaná (sekce 17.6.4.3.2 ve standardu C++11). Ten define nejspíš naráží na to, že jména začínající velkým E následovaným velkým písmenem nebo číslicí jsou rezervovaná pro errno.h, ale nejsem si jistý, jestli se to týká i C++.

[----]

já vím že jsou rezervovaná pro implementaci, ale nejedná se o chybu, ale o záměr; cílem je zabránit potenciálním konfliktům jmen s uživatelským kódem. OctaSTD je stejně de facto implementace standardní knihovny v tomto případě, a kompilátorům to vadit nebude. Kromě toho nikdy nepoužívám obecně prefix __, vždycky je to __Octa nebo __octa_, riziko konfliktu je naprosto minimální, resp. žádné. Co se týče enetu, když vynechám to, že to není moje knihovna, tak celkem pochybuju, že by errno.h někdy definoval ENET_VERSION_MAJOR.

[Jardík]

Konfliktům bráníš tím, že je to ve jmenném prostoru octa. Nebo použiješ prefixy (jiné než __). Naopak použitím __ si zaděláváš na problém. Vývojáři glibc jsou známí svou úchylnotí používat různé debilní identifikátory. Ani bych se nedivil, kdyby v příští verzi někdo přidal makro __OctaUnaryCompare, které ze dvou číselných parametrů urobí řetězec a pak je porovná jako 2 čísla v osmičkové soustavě.

[Jardík]

Nakonec je to ale tvoje věc, já jen upozorňuju na možné problémy a navrhuju jejich řešení.

[----]

namespaces tomu nepomůžou, jen vytvoří další potenciální problémy, třeba když vytvořím interní namespace uvnitř octa, pak někdo udělá "using namespace octa" a definuje namespace se stejným jménem... IMHO použití prefixu tak, jak jsem jej použil já, nikdy nebude problém; už jen proto, že octastd funguje na stejné úrovni, jako libc++ nebo libstdc++ (a v podstatě je nahrazuje).

[xkucf03]

Tak koukám, zlatá Java. Tam se jednak používají globálně jedinečné jmenné prostory (com.example.projekt123.…) typicky odvozené od internetové domény autora. A jednak se obvykle neimportuje celý obsah jmenného prostoru (balíčku), ale jen konkrétní třídy nebo konkrétní konstanty či statické metody metody ze třídy.

[kralyk z abclinuxu]

A jednak se obvykle neimportuje celý obsah jmenného prostoru (balíčku), ale jen konkrétní třídy nebo konkrétní konstanty či statické metody metody ze třídy.

V C++ se pochopitelně taky neimportuje celý namespace, tam se includují jednotlivé headery.

[xkucf03]

To je ale něco úplně jiného. a) V javě si můžeš do class path přidat kde co, spoustu JARů (dalo by se přirovnat k tomu includování) a nekoliduje to díky tomu, že se používají globálně jedinečné názvy (tzn. com.example.asdf a ne jen asdf). b) Na úrovni zdrojáku v jedné třídě si importuješ buď celý balíček (com.example.asdf.*), což se moc nepoužívá, nebo konkrétní třídy z něj (com.example.asdf.Třída123), ale dostupné máš úplně všechny třídy z class path (i když je neimportuješ, stále k nim můžeš přistupovat přes plně kvalifikované jméno).

Asi jediné, co chybí k dokonalosti, je možnost si třídy přejmenovat (vytvářet si aliasy pro typy). Např. když se ti sejdou dvě třídy stejného názvu Třída123 v různých balíčcích (může se celkem běžně stát), musíš si vybrat jednu, kterou importuješ a druhou, se kterou budeš pracovat přes plně kvalifikované jméno. Líbilo by se mi, kdyby sis mohl importovat obě a dát jim nějaký alias jedinečný v rámci daného zdrojáku.

[kralyk z abclinuxu]

Jasně, že to je něco úplně jinýho, C++ vůbec nemá moduly. Jen mi šlo o to, že nemusíš naimportovat celý namespace (a bez nějakého headeru includujícího všechny ostatní headery by to ani nešlo). Btw. existoval nějaký návrh pro moduly v C++, ale do C++11 se to nedostalo a od té doby se situace afaik nezměnila.

Javovské moduly celkem znám, globálně nekonflitktní jména jsou dobrý, ale je to zase vykoupeno tím, že jsou děsně dlouhý, což způsobuje děsně dlouhé + zanořené cesty ve filesystému...

Asi jediné, co chybí k dokonalosti, je možnost si třídy přejmenovat (vytvářet si aliasy pro typy). Např. když se ti sejdou dvě třídy stejného názvu Třída123 v různých balíčcích (může se celkem běžně stát), musíš si vybrat jednu, kterou importuješ a druhou, se kterou budeš pracovat přes plně kvalifikované jméno.

Hmm, třeba v Rustu se tohle řeší buď tím aliasem, nebo jde importovat nadřazený modul a používat částečně kvalifikované jméno, tj. Foo::Třída123 a Bar::Třída123 ...

[xkucf03]

ale je to zase vykoupeno tím, že jsou děsně dlouhý, což způsobuje děsně dlouhé + zanořené cesty ve filesystému...

To sice ano (třeba pět úrovní adresářů), ale vadí to něčemu?

BTW: zajímavý by mohl být i jazyk, který by umožňoval zapisovat jednotlivé části třídy do samostatných souborů ve složce – třída by byla složka a v jednom souboru bys měl třeba hlavičky, v jiném konstanty a pak metody v samostatných souborech. Pro navigaci strukturou bys nepotřeboval ani IDE a stačil by ti třeba mc

Hmm, třeba v Rustu se tohle řeší buď tím aliasem, nebo jde importovat nadřazený modul a používat částečně kvalifikované jméno, tj. Foo::Třída123 a Bar::Třída123 ...

Víc se mi líbí ty aliasy – ono ta třída se může jmenovat třeba Provider a balíček bude data – a kolizi máš hned.

[Bystroushaak]

BTW: zajímavý by mohl být i jazyk, který by umožňoval zapisovat jednotlivé části třídy do samostatných souborů ve složce

To pokud vím umí smalltalk.

[Radek Miček]

Nebo C#.

[kralyk z abclinuxu]

Tak C++ to v zásadě umí taky, dalo by se includovat doprostřed třídy, akorát je to imho trochu prasárna

[----]

jo, zvlášť když v c++ si můžeš první deklarovat struct/class jako čistě interface (tzn. bez implementací) a pak implementovat klidně v několika souborech, když chceš...

[xkucf03]

To jo, ale spíš jsem měl měl na mysli to, že ty includy nemusíš psát ručně, ale že to poskládá kompilátor nebo nějaký preprocesor sám – jen na základě konvencí pojmenování adresářů a souborů. Totéž by mohlo být zajímavé pro konfiguraci – složitou stromovou konfiguraci bys mohl rozložit na hromadu adresářů a souborů, poeditovat si to jednoduchým editorem nebo skriptem a pak zase poskládat dohromady, vytvořit z toho jeden konfigurační soubor, nebo to rovnou načíst jako konfiguraci do programu, bez jakéhokoli mezikroku. Podle hesla „všechno je soubor“ (tedy i uzel ve stromu v konfiguráku).

Alternativa je FUSE souborový systém, který by ti poskytl stejné rozhraní a ani by se kvůli tomu nemusely vytvářet fyzické soubory a adresáře na disku.

[kralyk z abclinuxu]

Uff, tak to fakt ne Já třeba osobně nemám problém s dlouhými zdrojáky a když už je situace hodně špatná, IDE typicky umí folding. Co se konfiguráků týče, zkus vyzkoušet něco jinýho než XML (prakticky cokoli), zjistíš, že konfiguráky nemusí nutně být nečitelá džungle :-p

[xkucf03]

Nejde o XML, jde o tu strukturu a množství informací. Kdybys to zapsal v libovolném jiném formátu, nijak si nepomůžeš.

Neříkám, že tohle je nějaká vize, kam by všechno mělo směřovat, ale přijde mi to zajímavé a občas by se to mohlo hodit. Jde o to že využiješ standardní API (souborový systém) pro přístup ke strukturám uvnitř nějakého souboru a díky tomu můžeš používat obecné nástroje pro práci se soubory (find, grep, sed, perl, bash, mc atd.) a abstrahuješ od konkrétního formátu – překlad zajišťuje nějaká mezivrstva, třeba FUSE FS – tzn. můžeš různě kombinovat programy a formáty, aniž by to jejich autoři původně zamýšleli. Můžeš např. nasměrovat standardní výstup nějakého programu na konkrétní místo (uzel) v nějakém souboru. Nebo si pomocí kopírování a přesouvání souborů/adresářů v Midnight commanderu upravit konfiguraci nebo možná i refaktorovat zdroják.

[:::]

BTW: zajímavý by mohl být i jazyk, který by umožňoval zapisovat jednotlivé části třídy do samostatných souborů ve složce – třída by byla složka a v jednom souboru bys měl třeba hlavičky, v jiném konstanty a pak metody v samostatných souborech. Pro navigaci strukturou bys nepotřeboval ani IDE a stačil by ti třeba mc

To teda zni dost hrozne

[----]

javisti...

[Bedňa]

To zanorovanie mi pripomína XML, čo má xkucf03 veľmi rád

[Xerces]

To sice ano (třeba pět úrovní adresářů), ale vadí to něčemu?

To ste všichni Javisti dopr... sfetovaný? Kdo v tom má pak řešit proč nějaká pitomá class přestala fungovat? A k tomu ještě ty úžasný logy, který jak jsou dlouhý, tak jsou na h...o. Sry, ale muselo to ven Ne opravdu Javou tuhle diskuzi nešpiňte.

[xkucf03]

Kdo v tom má pak řešit proč nějaká pitomá class přestala fungovat?

Třídy se chovají deterministicky, nepřestávají fungovat samy od sebe. A i když něco nefunguje, zanoření je ten nejmenší problém. Na příkazové řádce máme nástroje jako grep a find, pomocí kterých třídu hned najdeš. A taky (hlavně) se používají IDE, kde tu adresářovou strukturu neřešíš – přes metody/typy se proklikáš, kam potřebuješ. A hlavně mi přijde lepší mít program strukturovaný, než mít nasypané všechno na jedné hromadě.

A k tomu ještě ty úžasný logy, který jak jsou dlouhý…

Logování¹ v Javě je plně konfigurovatelné, takže je jen na tobě, v jakém formátu budeš logovat – příklad – tam je konzolový logovač, který vypisuje jen úroveň a zprávu. A pouhou změnou konfigurace si z toho můžeš udělat ty dlouhé logy, nebo jiné krátké logy (třeba přidat datum a čas), logovat do souboru atd.

_{[1] to výchozí ve standardní knihovně, o různých nadstavbách ani nemluvě}

[Xerces]

Typický komentář vývojáře odtrženého od reality provozu aplikací. Všechny takový pozavírat někam, kde si můžou psát v klidu Javovské romány. Ano v obou případech máte pravdu, bohužel realita je taková, že když člověk řeší nějaký havarijní stav, tak za a) nemá k dispozici nějaké IDE nebo vývojářské nástroje, za b) musí se spolehnout na to, jak logování nastavil nějaký chytrák při instalaci (takže buď nepřehledný default, nebo pro jistotu vypnuto . Sry za off-topic, už mlčím.

[xkucf03]

Nastavit si správně logování je zodpovědnost správce provozujícího danou aplikaci – autor nebo distributor dodávají jen nějaké výchozí nastavení, které sami považují za vhodné – je ale na správci, aby toto nastavení zrevidoval a upravil podle svého, než pustí aplikaci do provozu.

[Xerces]

Suchá je teorie, košatý strom života. Kdyby si Javisti svoje aplikace vždy i provozovali, tak by si tady nikdo netřepil prsty.

[xkucf03]

Proboha, tohle přece není o jazyku (spíš v tom bude nějaká osobní zášť). Když budu provozovat jakoukoli aplikaci, tak si ji mám nastavit podle svých potřeb – od toho přece ten správce je, jinak by nebyli žádní potřeba. Samozřejmě, že je fajn, když stačí dát aptitude install xyz a ono to hned funguje a je to nějak rozumně nastavené, ale v zásadě je to odpovědnost správce si to logování a další věci nastavit.

[Xerces]

Jde o to, že bohužel ve spoustě případů spravce (ten kdo má právo nastavovat logování a instalovat app) <> ten kdo musi vyresit problem.

[Ivan]

To neni zast. Java je proste novejsi a vetsina Java programatoru nezazila stav kdy administraci a programovani delal ten samej clovek. Proto proste Java programtori na spoustu veci nemysli. A logovani byla jedna z "tech" veci. Nejdriv na to nebylo zadny udelatko a par lidi se divilo proc nemuzou hard-codovat "C:/windows/temp". Pak byla doba kdy se kazdej .jar obsahoval v sobe log4j.(xml|conf). A bylo nutne ty jar-ka prebalovat. No a dneska resim class-loader issues, zjistuju jaka verze log4j se vlastne natahla(a odkud) a jaky konfiguracni direktivy muzu vlastne pouzit.

Oproti tomu syslog ma velice omezene moznosti, ktere ale v praxi plne dostacuji. Nejsou s tim problemy. A logovani "kazdeho" C-koveho demona je zdokumentovano.

[deda.jabko]

Typický komentář vývojáře odtrženého od reality provozu aplikací.

Komentar typickeho ignoranata...

musí se spolehnout na to, jak logování nastavil nějaký chytrák při instalaci (takže buď nepřehledný default, nebo pro jistotu vypnuto .

Toto neni problem Javy, ale tvuj, kdyz si neumis nastavit logovani, aby odpovidalo tvym potrebam.

když člověk řeší nějaký havarijní stav, tak za a) nemá k dispozici nějaké IDE nebo vývojářské nástroje

To zavani pripadem pro MacGyvera, protoze jenom ten dokaze s kusem provazku, zvykacky a javac, ktere nasel odlozene na servru, opravit kazdou porouchanou aplikaci.

[Xerces]

Ve spoustě případů máte jenom tu žvýkačku a světe div se, jde to. Jen ta Java je taková nepřátelská.

[tom]

Tak koukám, zlatá Java...

Tak toto rozhodne neni pravda, do C se nepridavaji nova klicova slova tak, aby se rozesral existujici kod. Vzdy se vezme rezervovane slovo (proto jsou rezervovana ta slova zacinajici podtrzitky) a nepodtrzitkova verze se #definuje v hlavicce, takze stary kod se nerozbije. V jave jim je to ukradene a klidne si pridaji nova slova, ktera rozbijou stary kod. Takze validni kod z jedne verze jazyka najednou neni validni v nove verzi. Co je tohle za debilni navrh?

[xkucf03]

Byl to jeden případ za celou dobu a bylo to vyvážené velkým užitkem. A nic to nemění na tom, že Java patří v oblasti kompatibility k těm nejlepším.

[tom]

Ja javu sleduji jen okrajove a pamatuji si to dvakrat. Pridali enum a assert. Je videt, ze se z prvni upravy gramatiky poucili a tu dalsi zvladli bez ztraty zpetne kompatibility, ze?

[xkucf03]

I v nejnovější Javě 8 ten starý zdroják přeložíš a spustíš – příklad:

public class Kompatibilita {

    public static void main(String[] args) {
        enum();
    }

    public static void enum() {
        assert();
    }

    public static void assert() {
        System.out.println("Kompatibilita v Javě není problém");
    }

}

Překlad (vypíše varování):

$ javac -source 1.3 Kompatibilita.java

Spuštění:

$ java Kompatibilita 
Kompatibilita v Javě není problém

Takže jestli chceš provozovat nějaké staré programy z 90. let, můžeš

P.S. asi nikdo není takový jasnovidec, aby už v první verzi jazyka nastřelil všechno tak, aby do budoucna nemusel nic měnit a mohl zachovat 100% kompatibilitu. Ta asi ani není možná – nebo jen na úkor inovací – a pak je otázka, jestli mít raději 100% kompatibilní, ale mrtvý jazyk, nebo něco, co se vyvíjí. Java v tomhle patří k nejlepším jazykům – zachovává kompatibilitu, je to velká priorita, ale zase v tom nejde přes mrtvoly, protože by to bylo kontraproduktivní – průběžně se vyvíjí (generika, anotace, enumy, lambdy…).

[kralyk z abclinuxu]

Ten -source bude, počítám, něco jako -std=... u gcc a clangu...

[pavlix]

Jen blbě nazvaný.

[deda.jabko]

inteligentne nazvany, protoze jeste je tam target, ktery udava pro kterou verzi JVM to ma byt prelozene

[Radek Miček]

do C se nepridavaji nova klicova slova tak, aby se rozesral existujici kod

Co třeba klíčová slova inline a restrict přidaná do C99?

[kralyk z abclinuxu]

namespaces tomu nepomůžou, jen vytvoří další potenciální problémy, třeba když vytvořím interní namespace uvnitř octa, pak někdo udělá "using namespace octa" a definuje namespace se stejným jménem...

To mi přijde vykonstruovaný problém, jednak by šlo ten interní namespace schovat (pimpl et al.), ale to prostě můžeš přidat do dokumentace - když budete používat namespace octa, nedefinujte v něm namespace octainternal, hotovo, nazdar.

[----]

nebo můžu použít prefix a nic do dokumentace přidat nemusím... docela pochybuju, že by použití v tomto prefixu byl reálný problém.

[Bedňa]

Neviem prečo nechceš dodržiavať štandardy jazyka a brániš sa namespaces. Sú veci ktoré boli za nejakým účelom vymyslené a všetci naokolo čakujú že ich budeš dodržiavať aby si tam mohli vjebať svoje podtržítkové prefixy

[xkucf03]

Neslouží k tomuhle právě jmenné prostory?

[Ivorne]

Nikdy jsem moc nepochopil tuhle snahu pořád přepisovat standardní knihovnu z jiného důvodu než jen si to vyzkoušet.

A argumenty jsou vždycky takové jakože 'má to jiný coding style', 'není to dost rychlé pro nějaký případ' atd.

Přitom snad neznám knihovnu, která by byla neutrálnější ke coding stylu než stdc++.

Většinou to dopadá tak, že ten člověk stráví dva týdny přepisováním té samé funkčnosti jen proto, aby se mu to víc líbilo a aby to v nějakém obskurním případě bylo trochu rychlejší (pokud všechno půjde, jak si na začátku představoval).

Navíc docela pochybuji, že ranges budou obecně lepší než třeba jen std::pair<iterator,iterator>. Měl bych obavu, že to bude nutit k časté duplikaci kódu v implementaci (protože máš range.begin a range.end).

[kralyk z abclinuxu]

+bambilion. Imho NIH syndrom.

Navíc stdc++ ja psaná tak, aby byla různě rozšiřitelná, upravitelná atd...

[----]

hm? jaké duplikaci? range.begin a range.end si vůbec nemusíš všímat, protože prostě inheritneš z InputRangeBase (tzn. template<typename T> struct MyRange: InputRangeBase<MyRange<T>, RandomAccessRange, T> { ... })

obecně je implementace vlastních ranges daleko jednodušší, než implementace iterátorů...

[Ivorne]

Jo, neříkám, že tam musí být duplikace, jen prostě kdybych to navrhoval, tak bych z toho měl strach.

Jednodužší než iterátory to asi bude, ale spíš proto, že iterátory z C++ jsou hodně promakané (a ne jen proto, že mají přetížený unární operátor *). Umím si představit značně jednodužší pojetí iterátorů.

Ale spíš mi jde o to, že to je prostě duplikace kódu ze stdc++ a taky bych řekl, že už se jedná o NIH syndrom.

[----]

jenže ranges toho umí v podstatě stejně, jako iterátory; jsou stejně flexibilní, ale mnohem jednodušší na implementaci... složitost iterátorů pochází hlavně z toho, že většinou máš dva, a že musí "emulovat" pointery.

v duplikaci kódu nevidím problém. Ano, občas tam nějaká duplikace bude, ale spousta designových záměrů v mé knihovně je od stdc++ rozdílná (třeba streams budou úplně jiné, kvůli ranges musí být jiné algoritmy - musí s nimi umět pracovat, všechny ostatní kontejnery musí umět pracovat s ranges místo iterátorů apod.) - takže zkoušet to psát jako addony k stdc++ by stejně znamenalo horší výsledek a v podstatě stejné množství práce, a výsledek by byl takový mírně schizofrenní...

mimochodem engine nepoužívá stdc++ ani teď, takže se vlastně nic nemění; jen poskytuju knihovnu, která je napsaná tak, aby s ní mohli jednoduše pracovat i ostatní.

[Radek Miček]

BTW ranges možná budou ve standardní knihovně C++17 – viz What will C++17 be?, případně implementace.

[----]

jo, to už jsem viděl... jejich design je docela rozdílný a spíš takový, aby to mohlo existovat vedle iterátorů/spolupracovat s iterátory, což ve standardní knihovně c++ dává smysl (musí zůstat kompatibilní apod.) - já taková omezení nemám, takže je všechno navrženo "od nuly"...

no uvidím, co C++17 udělá, ale počítám, že tak do roku 2020 (když budu optimistický) to bude pro mé účly nepoužitelné kvůli Visual Studiu :P do teď nemají ani kompletní implementaci C++11.

[tom]

Neda se nahodou ve visual studiu pouzivat i jinej prekladac, treba icc?

[----]

jo, měl by, ale stejně potřebuju podporovat out-of-box visual studio...

[unicode]

Na druhou stranu, pokud někdo nechce exceptions a potřebuje cow kontejnery, tak s stl moc nepochodí. Většina projektů stejně potřebuje jen array a hash table :)

[Ivorne]

Exceptions se vůbec v stl nemusí používat. Většina volání, která mohou vyhodit výjimku mají ekvivalent bez výjimek.

Jestli z nějakého důvodu opravdu potřebuješ cow kontejnery, tak si to samozřejmě musíš naimplementovat sám. To ale není tento případ.

[unicode]

Exceptions se vůbec v stl nemusí používat. Většina volání, která mohou vyhodit výjimku mají ekvivalent bez výjimek.

Sorry, ale toto je blbost.

[kralyk z abclinuxu]

Jaký výjimky máš na mysli? AFAIK stdlib hází jen bad_alloc, u kterýho je otázka, jestli vůbec má smysl se tím zabývat...

[Bedňa]

Inak C++ píšu posledný zúfalci čo nedokážu ani portovať svoj pojekt na 64bit ktorý je starší ako moja dcéra, alebo môžete použiť U++ a podobné alternatívy ktoré už nepatria do minulého storočia.

[kralyk z abclinuxu]

Co má C++ společného s 64bity?

Jinak ty máš asi pocit, že C++=C++98...

[Bedňa]

Mno taký Steam by mohol rozprávať o prasáckych motoroch v v C++ a tú kritiku na nich prečo sa to nedá portovať na iné platformy.

[Bedňa]

Tak ja som fakt mimo herného priemyslu, ale keď som skúšal Steam, tak to všetko ťahalo only 32bit library.

[bezprízorný]

Dosť hráčov má v dnešnej dobe 32-bit Widle (je to blbé, ale je to tak), preto je steam klient iba 32-bit, valve to stačí a hráči to moc neriešia.

Steam rozlišuje systém (32-bit/64-bit) až pri spúšťaní app nie pri jej inštalácii, preto sťahuje aj 32-bit. Hry, ktoré majú 64-bit build sa na 64-bit systéme spustia ako 64-bit. Ten 32-bit build máš potom na svojej mašine ako "bonus" ;).

[pavlix]

Inak C++ píšu posledný zúfalci

Urážky místo argumentů? Sám nemám rád C++, ale tohle nechápu.

čo nedokážu ani portovať svoj pojekt na 64bit

Souvislost?

[Bedňa]

Závislosti na only 32bit knižniciach, U++ má vúčšinu knižníc prepísanú multiplaformne, tak len toľko.

[Bedňa]

V 64bit som zabudol podoknúť.

[kralyk z abclinuxu]

Souvislost?

Multiplatformnost vůbec nezáleží na tom, jestli použiješ nějaké U++. Klidně můžeš mít multiplatformní program v čistém C++ a nemultiplatformní program v U++...

Mimochodem, neznám žádnou aplikaci napsanou v U++.

[:::]

U++ je knihovna pro C++, ne?

[bezprízorný]

Oficiálne stránky tvrdia, že je to framework.

[:::]

Pointa je, ze pokud U++ pouziva c++, tak dedi vsechny jeho problemy. Tak nevim co se tady krabica tak rozciluje

[bezprízorný]

Ja som pointu pochopil. Šlo mi o to, že je to tak mocný framework, že je od tých problémov odtienený ;).

[KS]

Pointa je, že ten člověk vůbec neví, o čem mluví.