Když vyšlo na podzim první dev preview Windows 8, docela mě bavilo „hrabat“ se ve WinRT, jelikož to bylo něco nového. Podobnost C++/CX s ObjC a Cocoa (jistě „čistě náhodná“) sváděla k porovnání různých koceptů. Protože ve WinRT má Microsoft kvůli návaznosti na jiné jazyky (a zejména .NET, tedy CLR) tzv. „projekce“, nelze lambda výrazy používat přímo, ale zabalují se do „delegátů“. Takový delegát se chová stejně jako C++/CX komponenta, tedy zejména má čítač referencí. Na druhou stranu zabalená lambda je nativní C++ objekt a správa paměti (např. při přesunu ze zásobníku na haldu) se řeší kopírováním (nebo novým move). Člověk by čekal, že použití instance komponenty v lambda výrazu jí zvýší čítač referencí a po zániku lambda výrazu jej opět sníží. Tak to i funguje, než ovšem předáte lambda výraz delegátu, kde správa paměti selže a máte memory leak jak vyšitý.
Připomeňme, že Apple, ať už s ARC nebo bez, automaticky zvyšuje čítač referencí (pokud se nepoužije __block, __weak nebo podobný modifikátor), přičemž bloky (obdoba lambda výrazů podle normy) včetně kontextu (closure) kopíruje ze zásobníku na haldu automaticky. Dokud nevytvoříte referenční cyklus (což je u bloků poměrně časté, aniž by si toho člověk všimnul, vzhledem k implicitnímu self u instančních proměnných), vše šlape hladce (blok samotný se chová jako ObjC objekt a má svůj čítač referencí).
V říjnu jsem na tento problém ve WinRT upozornil (na fóru a následně v bug trackingu), reakce byla (po řadě) skepse („to je tak jednoduchý koncept, tam nemůže být bug“), údiv, uznání a nakonec slíbení nápravy v beta verzi. Schválně si to zkuste teď, co myslíte, došlo k opravě?
Co byste chtel? V MS Utlouku stale jeste asi je bug, tedy to bude snad uz 15 ci vice let, kdy Utlouk nekvotuje na USENETu a asi i v mailu, kdyz vam prijde neco v quoted-printable. Treba podle tohoto to v r. 2007 stale jeste nefungovalo: http://www.pcreview.co.uk/forums/quoting-original-text-doesnt-work-if-original-mail-utf-8-a-t3250367.html
Cili vyckejte 20 let a mozna to opravi.
Keď to trochu nafúknem, tak Microsoft funkčné bugy neopravuje. Opravuje len bezpečnostné bugy.
Pekne to vidno na IE. Vždy vydá novú verziu, ktorá je plná bugov. Nikdy ich neopraví, namiesto toho vydá za 2 roky ďalšiu novú verziu plnú bugov. Výsledok je ten, že vývoj je utrpenie. Nie je možné používať nové technológie, pretože sú v nich často chyby.
Takto Microsoft výrazne spomaľuje nástup nových technológií, dovolím si tvrdiť že až násobne. Keď si porovnáme, kam sa posunul vývoj za pár rokov odkedy sa presadil Apple, tak až neverím očiam. Za 5 rokov dokázali vyvinúť nový systém iOS vrátane hw a ekosystému, napr. app storu. Všetko v špičkovej kvalite. Microsoft 20 rokov pytlikuje systém, ktorý ukradol, a to nevyvíja ani hw, a nemá ani app store. To so vybral len námatkovo.
Z tohto hľadiska vidím dominanciu Microsoftu ako historický omyl. Svet počítačov mohol byť úplne inde, keby sa vtedy presadil Apple ale iná "kvalitná" firma.
@11 V tomto případě jde o nástroj pro vývojáře, navíc se svým async Microsoft dost prosazuje právě lambda výrazy. Neopravení by zavedlo memory leaky do téměř každé aplikace. V tomto případě je problém v tom, že bug zřejmě opravili (není důvod nevěřit informaci v bug trackingu), ale oprava se nedostala do beta verze vydané o několik měsíců později.
Win 8 máme nainstalované v práci v jednom síťovém virtualu. Ještě jsem je neviděl ... možná bych měl :) .
Do vývoje systémů moc nedělám, mně stačí, že jsem "full time" .Neťák. Nedávno jsem narazil na bug v .Netu (konkrétně v XmlSerializeru) nahlášený v únoru 2002. Na podzim 2003 byl nahlášen jako opravený. Na jaře 2004 opět otevřen jako neopravený (= nic se nezměnilo). Od té doby tam visí.
Přidalo mi to spoustu práce. Fuck you Microsoft. I use your shits only because I really need to.
Autor se zabývá vývojem kompilátorů a knihoven pro objektově-orientované programovací jazyky.
Přečteno 36 207×
Přečteno 25 364×
Přečteno 23 797×
Přečteno 20 179×
Přečteno 17 876×