Příspěvky

106

Vývoj / Re:Zveřejnit projekt jako open-source?

« kdy: 27. 12. 2015, 20:20:07 »

dej to jako open source, beztak po tom nestekne ani pes... vlastni zkusenost

107

Server / Re:Zakázat stahování souborů ze serveru

« kdy: 25. 12. 2015, 22:40:46 »

K OP.

Není z toho jasné, zda se jedná o vývoj webu, nebo o vývoj nějakého jiného systému, kde třeba programátoři opravdu nesmí  mít přístup k nějakým souborům.

Dále bych rozlišil vývoj a nasazení. Programátoři nechť vyvíjí na vývojových strojích, kde mají k dispozici nezávadná data, na kterých své programy testují. Nasazení ať provádí systémový administrátoři, kteří mají podepsaný patřičný "drž hubu" papír a jejich činností je pouze nakopírovat nový program nebo update na konkrétní stroj a dohlížet na to, aby vše fungovalo jak má (a pokud nefunguje, mají možnost obnovy ze zálohy)

Programátoři tam zpravidla nemají přístup vůbec.

108

Vývoj / Re:Unikátní číslo v JS

« kdy: 21. 12. 2015, 14:27:18 »

vygenerovat 32 náhodných bajtů kryptograficky bezpečným generátorem náhodných čísel a máš pravděpodobnost výbuchu galaxie že vznikne kolize.

109

Windows a jiné systémy / Re:Kdy upgradovat na W10?

« kdy: 17. 12. 2015, 16:52:02 »

Kdy upgradovat na W10?

Až přijdou W11. Tak rovnou na ně. Jednoduše, W10 je sudá verze, MS dobrovolně volil sudou verzi, protože asi zřejmě tušil průser. Takže až si odladí W10 na lidech, vydá W11 a ta bude opět skvělá.

Že tvrdil, že W10 budou poslední? To tvrdí všichni.

110

Odkladiště / Re:Proč bitcoin?

« kdy: 11. 12. 2015, 11:29:29 »

Až mi to dokážeš, budeme pokračovat v konstruktivní debatě a roznesu ty tvé připomínky, protože budu přesvědčen že nediskuji z debilem. Diskuze z DEBILEM je vždy pouze ztráta času.

Myslím, že jakákoliv konstruktivní debata mezi námi je do budoucna zcela (a na vždy) vyloučena

111

Odkladiště / Re:Proč bitcoin?

« kdy: 10. 12. 2015, 23:34:29 »

otazka zni, jestli by neco podobneho neslo udelat i s BT (ciste teorticky) -> proste by byla ze zakona (v CR) udelena sazba/dan na platby BT (pod nejakou !drsnou! pokutou v pripade prokazani platby bez zaplaceni sazby/dane), coz by asi vsechny neodradilo, ale nemalou cast lidi pouzivajici BT mozna jo... sazba/dan by pak "regulovala" BT...
bylo by nebo je vubec neco takoveho mozne? (nemyslim technicky, proste jen "silou zakona" odradit uzivatele od pouzivani BT a "znicit" jeho hodnotu, uzivatelem nemyslim minera)

* nemam eko. vzdelani a nevlastnim zadny BT, spis by me zajimal nazor (urcite nazor O.N.) na tuto ideu... tak a pustte se do me

Jestli mohou státní restrikce zničit hodnotu, to nevím. Může to naopak znamenat, že se tomu hodnota zvýši, protože bude poptávka převyšovat nabídku. Dnes, kdo chce koupit bitcoin, ten jde do bitcoinmatu, nebo si pošle peníze na burzu. Jakákoliv restrikce by znamenala, že budou pokračovat obchody za hotové mezi jednotlivci a tam bude rozhodně těžší sehnat solidního partnera a proto bude nedostatek bitcoinů k prodeji.

Na druhou stranu ubude míst uplatnění což zase snižuje poptávku. Nicméně Bitcoiny se už nyní dost používají k rychlým a levným převodům peněz z jedné poloviny zeměkoule na druhou. To potvrdí i v Paralelním polisu, kde jeden bitcoinmat mají. V tom je jeho hodnota neoddiskutovatelná a jen tak hned nezmizí. Jet to moderní podoba hawaly. Státní restrikce tohle asi jen tak neutlumí.

Prokazování zaplacení nebo nezaplacení nějaké daně (kam, v čem), se realizuje těžko. Bitcoiny jsou pseudonymní, kdo chce, ten se nedá v blockchainu vysledovat. Stačí jen poslat bitcoiny na libovolnou burzu a za pár hodin je vybrat a jakákoliv stopa se přeruší. Navíc, přímo z blockchainu se nedá prokázat, co je platba a co jen přesun peněz v rámci mé peněženky. Ani to, že vlastně jakékoliv bitcoiny vlastním. Že mám v mobilu veřejné klíče neznamená, že jsou moje (v mobilu běžně mám dva účty, hlavní jen jako monitorování účtu a vedlejši pro drobné útraty. Hlavní účet nemá soukromý klíč, ten je v Trezoru a Trezor je na heslo a navíc sám soukromý klíč nikdy nevydá nikomu)

112

O serveru Root.cz / Re:blog.root je mrtvý?

« kdy: 10. 12. 2015, 14:58:10 »

diky za odpověď

113

O serveru Root.cz / blog.root je mrtvý?

« kdy: 10. 12. 2015, 11:57:59 »

Poslední příspěvek vidím z července. Je ta služba mrtvá, nebo jen jednoduše nikdo od té doby nic nenapsal?

114

Odkladiště / Re:Proč bitcoin?

« kdy: 09. 12. 2015, 10:33:24 »

1) Nemáš potvrzení že bitcoinové burzy všechny transakce logují - pokud ano zveřejni kde se dají zjistit a zkontrolovat transakce provedené na burze, v jiném případě je to pouze o důvěře, která v případě coinů byla zatím vždycky zneužita

Když já ti budu prodávat bitcoiny, tak se při určování ceny budeš řídit tím, že koukneš na tři hlavní burzy a podíváš se na aktuální last cenu na těch burzách. Třeba na nějaký průměr. Pokud to budeš dělat přes směnárnu, tak směnárna je zpravidla spojena s nějakou burzou, které důvěřuje a která ji opatří bitcoiny nebo peníze, aby mohla směnárna fungovat. Nicméně i tam máš šanci si zkontrolovat, že směnárna má zhruba podobné ceny jako burzy. To "že se můžeš podívat na last cenu" neni nic jiného, než že se podíváš na cenu posledního obchodu na té burze. Abys mohl vidět poslední cenu na té burze, musí být ten obchod zalogován = zveřejněn. A protože na burzách je obchod jediná transakce, která se tam provádí, tak je to zároveň to zveřejnění o kterém mluvím. Pokud by náhodou burza prováděla nějaké jiné transakce, které nejsou zalogované, tak se o nich stejně nikdo nedozví a tím nemají manipulativní charakter. Jenže to je proti samotnému smyslu existence burzy. Na provádění tajných transakcích nemusíme chodit na burzu, stačí se domluvit mezi sebou.

Chceš jiný důkaz?

2) Skutečně se domnívám že ti chybí adaptabilní mysl pro podvody, proto trvám na přesném popisu jak bys dělal DPH podvod mezi státy. Ne každý má náturu být zmrd. Sám jsi řekl, že ty jsi vyvíjel něco pro RMS a presto sis backdoor neudělal. Možná proto jsi tu práci dělal neboť ti co ti to zadaly, věděli že jsi naivní trdlo (ve slangu ulice debil,hlupák), které toho nezneužije.

To jsem neřekl. Programoval jsem demo pro Bitstock, tamní párovací systém. Neříkal jsem, že jsem si neudělal backdoor, říkal jsem, že je prakticky nemožné si takový backdoor udělat. Maximálně, že by burza obchodovala sama se sebou v rámci spreadu. Tím ale cenu neovlivní, protože se nedostane mimo spread, musela by totiž začít uspokojovat objednávky normálních obchodníků a ty by pak musela účetně započítat a tohle je věc, kterou si obchodník umí zkontrolovat. (totiž kromě veřejných dat má každý obchodník v obchodním systému burzy i vlastní historii a vlastní vyúčtování, které může porovnat s tím veřejně dostupným, třeba jako že každý obchod, který provedl, byl vidět ve veřejném tradelogu, nebo že každá objednávka, kterou vypsal, se objeví ve veřejném orderbooku, z něhož se pak páruje)

3) Pořád tvrdím že naprogramovat aby se prováděli virtuální transakce lze a docílíš tím zvýšení/snížení ceny.

Opravdu to není možné. Můžeš si napsat vlastní burzu, která bude obchodovat sama se sebou a nikoho tam nepustí. Ale nikdo ji nebude brát vážně, protože tam nikdo nebude mít své peníze. Já mám peníze na Bitfinexu. Mně se ještě nestalo, že by mi Bitfinex nevykonal příkaz. Takže jsem nakoupil a prodal podle technické analýzy a podle ní jsem udělal patřičný zisk nebo ztrátu. Tak jak to na burzách chodí. Vývoj aktuální ceny bitcoinu lze sledovat krásně v jeho tradelogu, je tam vidět hodně nákupu po stovkách BTC a párují se desítky objednávek. Chceš mi tvrdit, že všechny ty spárované objednávky jsou obchody burzy sama se sebou? Nesmysl. Když tam umístím svojí objednávku, spáruje se, a já následně jsem schopen vyzvednout příjem z obchodu v dolarech a přistane mi na účtu. To jako mi ta burza sama zaplatila?

Jo, takhle to funguje na Forexu. Tam obchoduješ s nějakým obchodníkem. On mi platí, nebo mě odírá, on mi posílá data tak, abych prodělal a on vydělal. Forex je mnohem větší podvod, než nějaký Bitfinex. Cena na Bitfinexu se tvoří z aktuální nabídky a poptávky. Cena na Forexu se tvoří tak, jak obchodníkovi vyhovuje. Proto na Forexu vidíš jen cenu, nevidíš objednávky, nevidíš objem a naopak tam vidíš spoustu trnů, které ničí tvé stoplossy. Jestli svou zkušenost odvozuješ s Forexu, tak se není čemu divit. Ale Bitcoinový trh spíš svým způsobem odpovídá třeba systému RMS (nebo kterékoliv akciové burze ve světě).

4) Dokonce to lze I bez virtuálních transakcí kdy obchoduješ s reálnými coiny sám se sebou ( kdy stačí obchodovat s 0,0001 coinem v ceně 1$ a pokud těch transakcí uděláš velmi mnoho snadno pohneš trhem, a jako správce systému pouze nastavíš že do těchto transakcí systému nevpustíš veřejnost)

Nechápeš! Když do nich nepustíš veřejnost, tak transakce jakoby neproběhly. Když dovolíš přeskočit  LIMITNÍ příkaz (pozor na to slovo, tyhle příkazy mají prioritu danou cenou, ne časem), tak minimálně u toho obchodníka, komu ta objednávka patřila vzbudí burza značné podezření. Když to bude burza dělat trvale, za chvíli odpudí všechny své obchodníky a to si piš, že na internetu se nic neutají. Dřív nebo později se objeví článek na nějakém prestižním portále, třeba Patria, a vsadím se, že ti novináři by zveřejnili i komplet historii svého obchodování, porovnanou s veřejnými daty aby poukázali na to, že někdo podvádí. Novináři...!

5) Taktéž jako správce systému hw a vývojář sw máš k tomu plno možností

Má a nemá. Zjistit si, jak funguje párování objednávek a zkus vymyslet, jak by se dal obejít, když už o tom pořád spekuluješ. Nemusíš znát programování. Jen prostě navrhni, jak bys dokázal změnit cenu aktiva, aniž by si spároval objednávky běžných obchodníků (kterým následně začneš dlužit peníze). Fakt to nejde. Máš našlapaný orderbook objednávkama, kdy na každých 10 centů máš jednu až tri a v rámci dolarového rozsahu objednaných 1000 BTC nahoru i dolu. Tak a teď mi ukaž, jak přeskočíš nějakou neviditelnou transakcí ten dolar? Jak uspokojíš těch 30 objednávek na 1000 BTC, které ti tam zůstanou viset? Nemůžeš je jen tak smazat. Budeš mít náhle 30 naštvaných zákazníků. 1000 BTC ti přitom jenom na poplatcích přinesou přinesou 120 dolarů. Nevím, ale jen ekonomické hledisko mi vychází, že je jednoduší nechat ty lidi obchodovat a vydělávat na poplatcích, než se snažit ovlivňovat cenu. Navíc takový Bitfinex na Bitcoinech nevydělává. Jemu je šumák, kolik stojí BTC. On nemá ani jeden (vlastní, má uloženy bitcoiny klientů, ale na ně nesmí sahat). Jeho bysnys je na poplatcích.

6) "Kdyby se tak stalo, někdo se určitě ozve" - komu?? Správci? dozorčímu orgánu?

Médiím. To je nejhorší. Správce? Dozorčí orgán? To se přece zamete pod koberec.  Jak můžeš těmhle orgánům vůbec věřit,  když mnohdy stojí na straně té instituce a nějaký zákazník je jim ukradenej?

Snad jedině policie, ale tam to má smysl teprve až se stane něco velkého, třeba jako když krachnul MtGox. Přitom, že jde ke dnu se vědělo dlouho předtím a ti kdo tam zůstali do poslední chvíle, těm by stejně žádná regulace nepomohla. Protože Karpeles jednoduše už v té době dávno utratil jejich peníze. Myslíš, že by nějaký dozorčí orgán tam pomohl? Mimochodem, jeden z lidí, kteří tam měli dohlížet na finance se až po roce přiznal, že dlouho dopředu věděli, že to půjde do kytek a neudělali nic.

7) "Spousta lidí si tam stěžuje, že se jim nezrealizovali příkazy, ačkoliv podle pravidel obchodování měly" jednoznačný důkaz toho co tvrdím = následek falešného obchodování, burza vytváří iluzní dojem obchodování ale reální obchodníci to nemůžou prodat.

Vidíš a přitom šlo jen o krátký časový úsek a pouze o velký pohyb ceny dolu a nahoru - k tomu poklesu by stejně postupně došlo na jiných burzách (ty  na flashcrash Bitfinexu reagovali jen velice líně, běžný trader sleduje několik burz a když se jedna zblázní, tak spíš to bere jako detekci nějakého problému, než reálný vývoj ceny. Dokonce když se zblázní ceny na čínských burzách, tak je evropský trader v klidu. V číně jsou všichni blázni a navíc to je trochu jiný svět)

Nakonec snad CEO Finexu nepřímo přiznal, že by mohlo jít o chybu v jejich obchodní platformě. Nemyslím si, že by na tom vydělali. Naopak si myslím, že jejich chyba v platformě je pořádně zabolela. Spousta obchodníku, kteří tam měli pozice, měly taky páku a u Bitfinexu páku poskytují zase jiní klienti. Bitfinex jim zaručuje jistotu vložených prostředků a díky flashcrashi mohlo spoustu obchodníků uzavřít své pozice nejen pod margin callem, ale i v záporných číslech. V tu chvíli ten rozdíl platí Bitfinex, protože klientům s uloženými prostředky ručí, zároveň ale si je už nevezme z traderů, takže musel sáhnout do své kapsy. O kolik při téhle chybě přišel můžeme spekulovat.

Ale i tady je vidět, že Bitfinex nemá v zájmu, aby se cena moc hýbala. Právě kvůli pákám. Zvlášť, pokud pohyby jsou větší, než by mohl pokrýt margin.

PS. už mě to fakt nebaví, myslím si že zazněly zajímavé argumenty, pozorný čtenář ať si závěr vytvoří sám. Dokud Ondřej podrobně nenapíše jak se dělají podvody s DPH mezi státy, tak to je pro mě důkaz že pořád nechápe jak to myslím, neboť se svým myšlením chodí stále okolo. Dle mě ti Ondro uniká pointa.

Nevím, co řešíš DPH? Bavíme se o burze, ne o DPH. DPH je povinnost subjektu platit daně státu, nejde o žádný trh. Každý se snaží obcházet tuto povinnost, to je snad jasné. Naopak na burzy chodí lidi nakupovat a prodávat, protože prostě chtějí koupit nebo prodat bitcoiny. Pokud si budeš chtít opatřit bitcoiny, kam půjdeš? Můžeš jít do bankomatu, do směnárny, nebo na burzu.Ač či tak, nakonec tvůj požadavek se stejně vyřídí na nějaké burze, protože jinde se bitcoiny v zásadě sehnat nedají. Maximálně od kamaráda a ten... pokud zrovna doma nemá těžební farmu ... je nejspíš má taky z burzy.

A ještě k osobním invektivám. Mě zase přijde, že jsi jen viděl nějaký film o burzovním prostředí, třeba Vlka z Wallstreet, nebo něco podobného a hned máš pocit, že tomu rozumíš. Ale třeba právě na světových burzách je krásně vidět, že je to skvělé místo pro podvody, právě díky těm regulacím. Třeba falešní brokerům, falešným tvůrcům trhu, banky, které mají zájem prodat lidem bezcenné akcie formou pump-dump ... né, že bychom to neznali z kryptoměn, kde stovky jich vzniklo právě k tomuto účelu a kde těmi pumpaři byli samotní tvůrci nové kryptoměny... Ale ty podvody se zpravdla dějí bez účasti provozovatele burzy a burza je prostředkem. Samotný obchodní institituce, ať již soukromá nebo státní, nemá zájem na ovlivňování ceny, protože prostě žije z poplatků, které jsou na ceně nezávislé.

115

Odkladiště / Re:Proč bitcoin?

« kdy: 08. 12. 2015, 13:47:17 »

http://www.investopedia.com/terms/m/marketmaker.asp

Aktuálně na bitcoinovém trhu nevidím žádné oficiálně registrované market makery. Je možné, že mají smlouvy s burzami neveřejné. Nebo je tohle možná důvod velkých výkyvů cen.

Jinak to video krásně ukazuje, že market maker má šanci obchodovat pouze ve spreadu, kde udělá zisk, ale při větších výkyvech vlastně tratí. Pro market makera je lepší stabilní cena

116

Odkladiště / Re:Proč bitcoin?

« kdy: 07. 12. 2015, 17:04:56 »

Tak ještě jednou a pomaleji = Obchodování sám se sebou můžeš ovlivňovat cenu(index). Pokud jsi to nepochopil přečti si ty mé postupy i vícekrát, většinou to pomůže. Opakovat se fakt nebudu.

To fakt nemá cenu, ty to prostě nechceš  nebo nemůžeš chápat. Jako správce hw a správce,vývojář sw burzy můžeš dělat imaginární obchody(transakce) a které nemusí být nikde zalogovany a uloženy. Nikdo z venku si totiž dané transakce skutečně nemůže ověřit.

Ne, nemůže! Cena je informace. Dokud ji nezveřejníš, nemá žádnou cenu. Neexistuje. Nikde. Jen ve tvé hlavě. Zvěřejnit = zalogovat. Nemusím ověřovat žádný obchod, ale pokud cena přeskočí můj příkaz, mám jasně ověřeno, že něco s burzou není v pořádku.

FYI - ten graf, který se kreslí na každý burze není nic jiného, než seznam všech obchodů (zalogovaných). Každý obchod má dvě strany. Cena přitom nesmí přeskočit jediný příkaz kohokoliv na burze. Nesmí. A na burzách obchoduje statisíce a milióny obchodníků. Kdyby se tak stalo, někdo se určitě ozve. Jde o prachy! Konečně přečti na redditu pár příspěvků kolem nedávného flashcrashe na Bitfinexu. Spousta lidí si tam stěžuje, že se jim nezrealizovali příkazy, ačkoliv podle pravidel obchodování měly. Od té doby Bitfinex horko těžko napravuje svou reputaci. Nicméně evidentně tohle byla spíš počítačová chyba, než záměr, protože aktuálně je cena někde úplně jinde, než by tehdy  mohl někdo chtít.

117

Vývoj / Re:Pro C++ experty.

« kdy: 05. 12. 2015, 00:15:09 »

Taková poznámka. Mezi interfaci není uplně od věci provádět virtuální dědění. Je třeba si pouze uvědomit, že tím se přidává komplexita, takže si je třeba to rozmyslet. A pak že virtuální dědění je "nakažlivé". Jakmile to někde člověk použije, zpravidla pak musí všechno od toho místa dědit virtuálně, jinak se mu stane, že ho překladač častuje chybama nebo warningama o ambignuitě tříd a o jejich vzáhemném překrývání (expert je na tohle gcc při levelu -wextra)

Virtuální dědění ovšem dělá trošku jiný layout mezi potomkem a předkem.

Normální dědění jen rozšiřuje tabulku virtuálních metod na dalších indexech. Takže pokud má předek 5 metod a potomek 6, pak předek obsadí indexy 0 - 4 a potomek 5 - 10.

Virtuální dědění ale znamená, že předek bude mít svojí tabulky virtuálních adres.  Potomek má pak v tabulce na nultém odkazu offset na předka a následují virtuální metody na indexech 1 - 6.

Když se z pointeru na potomka volá metoda předka, musí se nejprve vyzvednout offset na indexu 0, ten se přičte (odečte) od pointeru a tím se získá adresa tabulky předka a tam se metoda vyhledá. Je tam určitě dvojitá dereference, což může být další zdržení.

Výhodou virtuálního dědění interfaců je, že každý interface je v objektu jen jednou a k přetypování není nutné komplikovaným způsobem postupovat po hierachii jako u normálního dědění, pokud je treba přetypovat na předka, který se v interfacu nachází dvakrát, nebo i vícekrát (protože pak překladač hlásí, že neví, na kterého předka vlastně má ukázat).

Virtuální dědění interfaců je menší zádrhel, než virtuální dědění celých objektů, kde i přístup k member proměnným se děje přes offsety a to i v rámci implementace metod. Navíc do toho vstupují konstruktory, které u virtuálního dědění vyžadují jiný způsob kontrukce než je člověk zvyklej (interfacy by konstruktory mít neměly)

118

Vývoj / Re:Pro C++ experty.

« kdy: 04. 12. 2015, 16:33:50 »

A kdyz ted  v moji aplikaci bude IFoo interface k nejake implementaci FooImpl, ktera bude dedit ze tridy BarImpl, k niz bude to rozhrani IBar, tak by to rozhrani IFoo melo dedit z rozhrani IBar, jenze to uz jsem zase v situaci, kdy pak nemuzu do rozhrani IBar pridat nejakou virtualni metodu. aniz bych nerozbil kod co pouziva IFoo (co jsem pochopil, tak leaf classam muzu virtualni metody pridavat na konec - krome windows, ten to pry nejak muze preorganizovat). Resenim by bylo zkopirovat ty metody z rozhrani IBar do IFoo, ale jako tohle fakt delat nechci. Chapu to spravne?

Můžeš použít moje řešení IInterface (viz výše) ale samozřejmě musíš na to myslet úplně na začátku, kdy každé rozhraní dědí IInterface. To pak každé rozhraní poskytuje funkci getIfc<typ> a každý ten BarImpl nebo FooImpl může na základě požadavku vrátit pointer na rozhraní, které požaduješ. Je to hodně podobné tomu, co dělá ve windows QueryInterface. Akorát QueryInterface vyžaduje transitivitu a reflexivitu, což moje řešení ne. QueryInterface je blíže spíš dynamic_castu, zatímco mé řešení spíš připomíná funkci QueryService, které zahrnuji i QueryInterface.

Pak můžeš napsat

Kód: [Vybrat]

IFoo *foo = main->createFoo();
IBar *p = foo->getIfc<IBar>()

Je v2c9 FooImpl, aby si zařídilo převod z IFoo na IBar. Třeba tak, že bude třída FooBar, která dědí BarImpl a FooImpl

119

Vývoj / Re:Pro C++ experty.

« kdy: 04. 12. 2015, 16:28:49 »

Člověče máš to nějaký složitý, a je v tom mnoho věcí naráz. Nicméně k čemu se umím vyjádřit je pomalost dynamic_castu. Ano, ten je pomalý, ale ne proto, že by ti programátoři to neuměli napsat, ale ono to prostě líp nejde. dynamic_cast musí na základě dosti omezených dat o objektu a požadované třídě najít adresu patřičného potomka a to s ohledem na různá vícenásobná a hlavně virtuální dědění (což je samozřejmě chuťovka). Navíc třeba ve Windows to řeší i přes různé knihovny, kdy každá knihovna může být přeložena jiným překladačem, takže neexistuje jedný způsob, jak identifikovat třídu, takže se používá zamanglované jméno a k porovnávání se používá funkce strcmp.

Tohle jsem řešil taky s ruznými způsoby a stupni úspěchu a neúspěchu. A nakonec jsem skončil u řešení, které nazývám "IInterface". Je to třída, která poskytuje funkci getInterface (zkráceně getIfc) a zapisuje se

Kód: [Vybrat]

Potomek &p = predek.getIfc<Potomek>()

nebo

Kód: [Vybrat]

Potomek *p = predek.getIfcPtr<Potomek>()

Ten vztah tak nemusí být jen potomek předek, ale lze takhle získat pointer na libovolné rozhraní, které objekt může přímo implementovat nebo i nepřímo. Třeba mám rozhranní IHttpRequest, který také poskytuje ITCPConnection a dokonce IJobManager právě prostřednictvím getIfcPtr. Přestože IJobManager nemá nic společného s requestem, přesto to funguje jako service, kterou request nabízí svému handleru (handler si může spustit job)

Implementace tohoto prostředku mám ve své knihovně lightspeed

https://github.com/ondra-novak/lightspeed/blob/master/src/lightspeed/base/interface.h
https://github.com/ondra-novak/lightspeed/blob/master/src/lightspeed/base/interface.tcc

Soubor *.tcc se inkluduje do každého *.cpp, kde se to používá, je to implementační část šablony.

Kupodivu to nefunguje automaticky tak jak by sis představoval. Když totiž nic neuděláš, rozhraní vše realizuje přes dynamic_cast, takže žádná věda. Ale ušetří to spoustu práce, tam, kde rychlost nepotřebuješ řešit. Pokud chceš ale nabízet nějaké zkratky, nebo extrabuřty, stačí, když potomek implementuje funkci

virtual void *proxyInterface(IInterfaceRequest &p)

Funkce si z p vyzvedne typ třídy (jako typeid) kterou chce volající získat a pokud ji umí, pak vrátí buď sebe přes static_cast na požadovanou třídu nebo interface - musí ho pak přetypovat na void *, nebo přímo vrátí pointer na službu, která požadovanou třídu implementuje. Je akorát třeba pamatovat na to, že pointer musí být před vrácením nejprve přetypován na požadovaný typ přes static_cast, než je převeden na void *, jelikož šablona si to na druhé straně zase přetypuje zpět na požadovanou třídu.

Funguje to v celku dobře, pokud mám někde místo, které dost často dělá přetypování a chci se vyhnout dynamic_castu, tak v potomkovi definuju přímo onu zkratku a tím se vyhnu pomalému dynamic_cast. Je to opravdu rychlejší, protože ve výsledku to je jen jedno volání virtuální funkce, jedna operace porovnávání a static_cast nic nestojí.

Samozřejmě, jakmile se mi těch tříd co nabízím začne množit víc, začne být ten rozhodovací mechanismus složitejší a pak je třeba si spočítat, jestli náhodou ten dynamic_cast nevyjde rychlejší. Potom stačí pouze zavolat výchozí implementaci IInterface a on už to zařídí sám.

120

Vývoj / Re:Pro C++ experty.

« kdy: 04. 12. 2015, 09:00:59 »

Tohle je úplně uhozený způsob udržení binární kompatibility, nebude to fungovat. Všichni se to snaží tazateli říct, ale on to nechce pochopit. Pak přijde "odborník" a doporučí podobnou blbost.

Nebude to fungovat třeba z toho důvodu, že default constructor je inline, takže se nevykoná v dynamické libce, ale u klienta. Správná velikost na správnou inicializaci objektu nestačí, musí být splněna celá řada další podmínek.

Já jsem taky neříkal, že odpovím tazateli, diskuze se zvrhla mezi účastníky, kteří netuší, k čemu se přetížený new používá.

No budiž.

Tedy pokud jde o binární kompatibilitu, tam se to takhle vůbec nemůže dělat. Ať zapomene na new, ať vůbec zapomene na to, že by do hlavičkových souborů dával finální třídy. Z knihovny může exportovat jen rozhraní, tedy třídy obsahující __pouze__ abstraktní funkce. A i tady bude mít problém, pokud bude do takového rozhraní přidávat funkce, musí nutně ta rozhraní verzovat.

Úplně první co z knihovny vypadne je nějaké základní rozhraní, které zpravidla obsahuje továrnu pro všechny objekty, které knihovna umí vytvořit.

Kód: [Vybrat]

class IMain {
public:
   virtual IFoo *createFoo() = 0;
   virtual IBar *createBar(...) = 0;
   virtual ~IMain() {}
}

Pokud je třeba, aby knihovna volala nějaké věci z hlavního programu, je jí to třeba dodat také přes rozhraní. Komunikace mezi knihovnou a hlavním program nelze zajistit lépe, než právě takhle. To je jediný čistý způsob jak to udělat.

Navázání komunikace s knihovnou se zpravidla děje přes C-čkovskou funkci (extern "C"). Tohle dobře funguje ve Windows.

Ve Windows je ještě jedna potíž a to s oddělenými heapy knihovny a hlavního programu. Proto není možné objekt vytvořený knihovnou zničit v hlavním programu a naopak. Rozhodně nezapomínat na virtuální destruktor, který tohle řeší.

(Pokud se ve windows použijí DLL runtime knihovny, pak je to trochu lepší, protože všechny alokace patří knihovně MSVCRT.DLL - stačí ale aby jeden modul měl statické linkování a pak jeho alokace patří pouze jemu. - V linuxu je jeden heap, tam to problém není)

Takže shrnutí. Binární kompatibilita jen přes interfacy (a to ještě verzované). Jinak lze využít dynamické knihovny i bez této nutnosti, za předpokladu, že s každou změnou hlavičkových souborů vydám novou verzi dynamické knihovny a budu je verzovat. Ale to není binární kompatibilita. Navíc člověka umlátí zejména v linuxu dependency-hell (ve Windows to řeší DLL-hell a winsxs-hell)


PS: teď mě napadlo, že pokud používá výjimky, taky si užije legrace, až bude výjimku z knihovny chytat v hlavním kódu. Třeba ve windows, když propadá výjimka z hlavního programu do knihovny přes callback a zpět do hlavního programu, stávalo se, že se neodchytla a spadla až do unexpected()