Názory k článku
Na kometě přistál čtvrt století starý procesor

Spíše kvůli tomu, že je na to jednodušší vývoj.
Nějaký malware nehrozí - jednak nemá jak (je to oddělené) a druhak většinou tyto systémy běží jako Read-Only.

Jednodušší vývoj? Na widle? Moment, tady něco nesedí...

Nesedí leda tak Vaše znalosti vývoje aplikací. Podpora pro vývojáře v Linuxu a ve Windows je naprosto nesrovnatelná a v GUI je to přímo propast, proto se spousta GUI realizuje ve Windows.

Kde je třeba v Qt ta propast při vývoji GUI?

Co se ovladačů týká, člověk si vystačí v podstatě s GCC a tím, co je napsáno třeba na http://www.ucsimply.cz/elnx/uvod-do-vyvoje-ovladacu/ + znalostí té periferky. Na widle musí shánět SDKčko, studovat tuny dokumentace,...

WinApi - znát to Hitchcock, tak se vykašle na opeřence

Najít cokoliv na MSDN dokáže jenom Lael, je tam kolikrát víc mlžení a právnických kliček, než technických faktů.

A kontrolní otázka: Co umí Visual Studio a neumí Eclipse? Kromě proprietálních věcí jako .NET...

A prdnout to do embedded procesoru na 400MHz v nějakým ovládacím panelu se to dost dobře nedá, pokud nepočítám Win CE. Ty jsou ale mnohem, mnohem nenažranější, než tučňák.

Propast je v tom že žádné Qt není vůbec potřeba, GUI stejně tak spousta jiných knihoven je přímo součástí OS, vývojář se nemusí zdržovat banalitami a může se věnovat práci.
Do větší diskuze se nepouštím, nemá to smysl, statistiky hovoří jasně.

Spoléhat na přítomnost Qt v potřebné verzi je čirá naivita, závisí jak se autor distra zrovna vyspal a moc dobře to víte. U konkurence tohle odpadá, prostě na to spoleh je.
Jistě že to nakonec vyřešíte o tom není sporu, můžete si vyhrát dlouhé hodiny se statickým linkováním, s distribucí .so, s kompilací balíčků, ale to potřebuje čas a čas jsou peníze a peníze jsou pro spoustu lidí určující.

Bože můj...

Jop, ve widlich zase na to, jakej patch zvrovna vylez ... podle toho se jaksi tak nejak prubezne meni API.

Ptal jsem se vás na to opakovaně, a bez odpovědi. Takže znovu: jaká konkrétní API Windows se "průběžně mění" s dopadem na zpětnou kompatibilitu? Konkrétní příklady, prosím.

Svatá prostoto...

Qt se docela dost hodí. Je to multiplatformní framework, který zapouzdří a smaže rozdíly. GUI se dělá sejně na Androidu, Linuxu, iOsu a Widlích, jenom se nakonfiguruje kompilátor a použitý kniíhovny. Vypadne nativní binárka pro zvolenou architekturu. V open source světě je toho pro Qt taky docela dost dostupnýho...

Mrkni na YouTube na kanál VoidRealms, třeba budeš příjemně překvapený, co to umí... ;) Historie není moc podstatná, současnost se od ní dost liší.

Qt dneska možná. Před deseti lety?
Spíš něco jako Borland C++ builder - windows only. Programátoři to umí, jsou tam hotové komponenty, nikdo už to předělávat nebude.
Kolik lidí zná Qt? Když už, tak seženete lidi na .NET nebo Javu, ale ta se na desktopové GUI aplikace moc nehodí.

Reagoval jsem na "Podpora pro vývojáře v Linuxu a ve Windows *je* naprosto nesrovnatelná a v GUI *je* ..." Psal o přítomnosti, přítomnost je taková, že Qt se dá hodit kamkoliv. Win, tučňák, Android,... To bych rovnou mohl argumantovat děrnou páskou při výběru architektury pro nový produkt.

Qt existuje i jako .rpm, i jako .deb a pokud autor distra zapomene, není to vůbec tragédie. Dokonce plná instalace z .rpm měla jenom asi 250MB, z toho cca 200M dokumentace + příkllady + dema. VisualStudio? Tam má jenom instalačka pro IDE kolem 400MB. QtCreator jede mimo mezivrstvy jako .NET a Java, přímo jako binárka na procesoru. Takže je to podstatně svižnější.

A kolik lidí zná Qt? Tolik, kolik jich zná C++ a je ochotných se v tom pár hodin vrtat. Tzn, naučit se mechanismus komunikace přes sloty a mailboxy (cca 2 hodiny), zná architekturu MPC a zvládne nastudovat si widgety. Nic víc v tom fakt není. A dokumentace o několik řádů lepší, než u M$... C++, C# i Java mají hodně podobný základ, takže přechod bolí míň, než programátora v Delphi přeškolit na Javu nebo z VBA na C#.

A věděl jsi, že GUI v Qt frameworku se dá vytvořit podobně, jako webovka? Upravený XML (říkají tomu QML) + JavaScript... Takže ani to C++ na některý věci nepotřebuješ...

Prostě si nemůžu pomoct, ale argument o GUI je úplně mimo.

Zřejmě se míjíte s většinovou představou, co znamená podpora pro vývojáře.
A nejde pouze tu samotnou podporu od výrobce. Jde o celý ekosystém, že na windows mám k dispozici velké množství různých hotových komponent od tvůrců třetích stran a různých pomocných nástrojů.

Já osobně bych nepsal, že je to na windows "naprosto nesrovnatelné", použil bych o něco slabší termín "výrazně lepší", ale to by neměla být podstata sporu.

A abych se vrátil v diskuzi zpět. Hlavní důvod, proč hodně HMI systémů jede na windows je setrvačnost a konzervativnost v oboru řídících systémů a automatizace.
Jak fungoval vývoj GUI na windows před 10 - 15 lety? Vývoj v Borland Builderu nebo Delphi se ode dneška zase tak zásadně neliší.
A kde bylo QT před 10 - 15 lety?

Další věc je ta, že jenom málo věcí se programuje z nuly. Běžné HMI systémy se tvoří pomocí specializovaných balíků (kde se kombinuje klikání na komponenty a nějaký skriptovací jazyk). A tyhle vývojové balíky jsou zase především pod windows a produkují runtime běžící windows, protože před 10 - 15 lety fakticky jiná volba nebyla a setrvačnost je značná.

Ad dokumentace [Qt] o několik řádů lepší, než u M$ - řekněme že ve světě Linuxu jde o nadstandardní vysoce dokumentaci. Kvalit MS dokumentace nedosahuje, ale blíží se.

Ad C++, C# i Java mají hodně podobný základ - to sice ano, ale C# i Java jsou o dost pokročilejší jazyky. Pro ilustraci: zkuste v C# nebo Javě způsobit buffer overflow. V C++ se to zjevně daří velmi dobře. Kdo zkusil v C++ napsat kus kódu, tak ví jak je náchylné chyby, ví že ty chyby navíc často nekončí výjimkou, a místo toho aplikace "vyhnije zevnitř". Současný tristní stav SW průmyslu, kdy i hloupé prohlížečky webu interpretující pár stovek tagů mají stovky zranitelností ročně (2013: FF 270 zranitelností, Chrome 245, MSIE 126), je právě důsledkem používání C/C++.

Netrufam si sudit ci dokumentacia Linuxu je lepsia ako dokumnetacia M$. Ale pripadam si ako v inom svete ked citam od Vas aka je dobra. Este sa mi nestalo aby som z dokumntacie M$ nieco pochopil aj ked mi to google da ako prvu moznost. Vzdy treba prejst na stackoverflow a tam sa dozviem ako mam co pouzit. V casoch Borland c++ bol help kde ma F1 dostalo na popis funkcie a pod nou na PRIAKLAD pouzitia. Teraz mi M$ da materaial na viac stran sucheho textu o ktorej mam podozrenie ze ju robil robot a aj ked sa cez to preluskam mudrejsi niesom. Vrchol vsetkeho je ked mi pred precitanim prveho slova v helpe vyskoci okno Pomohol Vam tento help?

Dokumentace od MS obsahuje spoustu příkladů, i když ne úplně ke všemu. Obsahuje také popis konceptů. Help na F1 samozřejmě ve VS funguje.

Mám asi selektivní poruchu učení. Nedokážu pochopit psaný text, pokud tento pochází z dílny Microsoftu. Má to ještě někdo?

Já to mám taky. Dokumentace od MS a od IBM mě nutí neustále někam klikat a nakonec to najdu jinde, vetšinou od nějakého guru v podobě příkladu.

C++ je v pohodě, jako jakákoliv technologie, kterou člověk zvládne. Musí si ale uvědomovat její slabiny.

Tobě vadí pointery, OK, asi jsi ze skupiny osob, který nemají centrum pro práci s pointery (viz blog Joela Spolskyho). Takže ti vyhovuje něco, co pointery nemá.

Já jsem si low level operace s pointery ošetřil, (možností je plno, od maker po šablony) a otestoval. Používám knihovny, který prostě nedovolí nezadat výchozí parametr, přetečení bufferu, neuvolnění paměti. A v debug módu asserci. Je po problému.

Já zase na C/C++ oceňuju pevně daný typy a upozornění na fakt, že do času cpu den v týdnu. To je u jazyka, kde se do kontejnerů dá nacpat objekt a objekt je cokoliv, docela omezující. A protože dělám embeďáka, navíc v oddělení automatizace, tak jakákoliv mezivrstva typu JRE nebo .NET jenom spotřebuje drahou FLASH, vynutí rychlejší (a dražčí) procesor, zvýší riziko chyb třetí strany, zkomplikuje odezvu na přístup k hardwaru,... Takže M$ nemá na řadu věcí ani adekvátní řešení. Naštěstí.

Asi tak, je to lepčí, než nic. Pomalu se to zlepšuje, třeba v poslední specifikaci už jde vypnout implicitní typecast enumu na int :)

Blbluvzdorný není nic. Na programování jsou vždycky potřeba znalosti a jsou jedinci, kteří nezvládnou vytvořit program ani tak, že si na to najmou někoho dalšího. Prakticky ověřeno, ale nebudu sem psát konkrétní jména... Sebelepší framework jim v tom nepomůže.

Blbuvzdorné není nic, souhlas. Zároveň jsou programátoři lidé, a lidé dělají chyby (a to zatraceně často). Proto je velmi praktické při vývoji používat co nejblbuvzdornější prostředí. Jak jsem už psal, používání C/C++ je primárním důvodem dnešního tristního stavu SW průmyslu, kde mají ročně stovky bugů i prohlížečky webu zpracovávající par set tagů.

Chyby dělají a je potřeba s tím počítat. Proto existuje debug, testování,.. atd. Jenomže ladění a testování stojí čas a pníze. Dneska jde o to, být s funkcí první na trhu a testování/oprava chyb se jaksi nenosí. Když manažer roshodne, že to bude v dubnu na trhu, je to v dubnu na trhu a jede se na dluh. Pak to stopne, protože se prostě už prodává a je potřeba dělat na dalším projektu... http://www.zdrojak.cz/clanky/technicky-dluh/ Sebelepší vývojář se sebelepším prostředím je tam pak na dvě věci.

A jenom tak mimochodem, když je toho ve widlích většina v C#, proč jsou tak zabugovaný...

Proč tedy, přes všechnu snahu, mají projekty psané v C/C++ pořád problémy například s buffer overflow? Proč browsery, Flash, Adobe Reader a podobné hračky mají stovky zranitelností ročně?

Ad když je toho ve widlích většina v C#, proč jsou tak zabugovaný - Windows jako takové jsou z velké části psané v C++. Toho .NETu je tam pomálu. Vývojáři jsou konzervativní i v MS, a mezi zastánci C# a C++ se vede mnohaletá interní bitva. Momentálně to vypadá na smír, kdy WinRT umožňuje bezešvým způsobem kombinovat kód psaný v C++ a C#. Do budoucna by to mělo umožnit běh aplikací na něčem typu Singularity, nad čím se bude dát provést model checking v rozsahu, který C++ prostě neumožňuje. Tím bychom měli dostat OS řádově spolehlivější, než dnešní Unixy a Windows, s formálními důkazy bezchybnosti.

Ad asi jsi ze skupiny osob, který nemají centrum pro práci s pointery - o mě nejde. Spíš zamrzí, že do té skupiny zjevně patří autoři Firefoxu, Google Chrome, MSIE, Flashe, Adobe Readeru, a prakticky každého dalšího SW psaného v C/C++.

Ad dělám embeďáka - tam má použití C/C++ lepší smysl. Kód je poměrně malý, typicky "nezáludný", a nejspíš vám nikdo neťuká na vrátka věčnými pokusy o exploit. Samozřejmě embdedded vývoj lze dělat na Windows CE (ať už v .NETu nebo C++), ale u menších projektů to asi nemá smysl. Navíc ty WinCE nejsou zdarma, což může být ve spoustě případů dost zásadní argument.
Na druhé straně na příkladu různých domácích krabiček můžete vidět, že Linux je plný chyb (jako cokoliv jiného), "ťukání na vrátka" je pravidlem, a o firmware se výrobci přestanou starat jakmile ukončí výrobu zařízení. Navíc uživatelé neaplikují nový firmware ani když je k dispozici. V důsledku toho máme dnes domácnosti prolezlé krabičkami, které jsou děravé jako řešeto.

Rychlost aplikací psaných v C# může být velmi dobrá. Zkuste si stáhnout třeba Paint.NET.

Tak možná nezkoušejte betu :). U mě Paint.NET fungoval zatím vždycky na 100%, i když jsem nezkoušel každou verzi.

Malý, nezáludný? Ehm... Právě kompiluju projekt, kde je 1763 souborů s příponou .c, .h a .cpp a to, co jsem měnil, je v souboru s 7350 řádkama... + v zařízení je druhej procesor s komunikací a WiFi stackem. Je to dost malý?

Svádět neschopnost na jazyk je nesmysl. Pila taky nemůže za to, že si tesař uřízne prsty. Vždycky existuje možnost, jak se chybám vyhnout - aserce, unit testy, review,... A hlavně, musí se myslet a aktivně se chybám bránit.

To je fakt takov problém mít seznam testů pro každý paket (délka, rozsah datové položky 1,..., rozsah datové položky N, u každýho podstřelení, přestřelení, korektní chování, zakázaný hodnoty) ve formě tabulky a zkontrolovat, že všechny testy jsou přítomný a zelený? Kdyby takovouhle prkotinu kdysi někdo udělal, tak žádný Heartbleed nikdy nebyl.

Ad v souboru s 7350 řádkama... - pro srovnání Firefox má 12.6M řádek kódu, a MS Office pár desítek. Oboje je primárně v C/C++. Takže ano, váš projekt je relativně malý a nezáludný.

Ad Svádět neschopnost na jazyk je nesmysl - ve větším projektu je nutně spousta chyb, protože kód píší lidé. Jaké dopady ty chyby mají na bezpečnost a spolehlivost SW? V případě C/C++ často zcela zásadní. Další věcí je možnost formálně ověřit správnost kódu, což je u C/C++ prakticky nemožné.

Ad je fakt takov problém mít seznam testů pro každý paket - zkuste si přečíst všechna RFC týkající se IP stacku, pokud máte dost času. A pak napsat důkladné testy - na to asi do konce života dost času mít nebudete :)

Pokud je ta dokumentace ve strojově čitelné formě (např. XML), tak není problém napsat generátor testů. Doručení paketu do parseru nebo jeho odeslání je vždycky stejný, to se napíše jednou. A pak stačí automaticky generovat data a posílat, sledovat reporty a odpovědi a předávání dat.

Ručně ověřit 100 paketů po 10 položkách na chybu každé (pod, v rozsahu a nad rozsahem) by bylo samozřejmě trochu mimo - s CRC na konci a ověřením délky by to bylo 3400 testů a psát je ručně jak v microsoftu by byla sebevražda. Generátor to má pod 10 minut a při update spacifikace stačí upravit popis protokolu. Build, run, komplet test komunikace za půl hodiny...

Myslím že hrubě podceňujete velikost stavového stromu IP stacku. On to není sériový port :), ten protokol je vrstvený, a TLS není dvakrát jednoduché.

Jop, a vysledek je, ze binarka toho hello world ma 10MB a nez to vubec pujde spustit, je treba nainstalovat par GB .NET.

Mno jiste, ono se nic instalovat nemusi, proto kazdej mesic prijde 500MB patch (to kdyz malo). A proto je .NET jako volitelna instalace na M$ update.

Ad Kde je třeba v Qt ta propast při vývoji GUI - Qt je poměrně pěkné, ale bohužel je primárně určené pro C++, což pro tvorbu aplikací není dvakrát praktické. Dále pro Windows máte k dispozici hromady komponent třetích stran. Chcete medicínský imaging, OCR, rozeznávání barcodů nebo cokoliv jiného? Vytáhnete kreditku, koupíte komponentu, a máte hotovo. U Qt máte smůlu.

U Qt je také problémem licence. Základní Qt je sice zdarma, ale jen pokud uvolníte aplikaci pod GPL, což většina autorů pochopitelně nechce. Navíc pokud chcete Qt Charts, Data Visualization, Enterprise Controls a další, tak v ty Community Edition nenajdete. Jinými slovy nakonec zaplatíte spoustu peněz za Qt, a pořád budete psát v C++, takže i vývoj bude dražší a pomalejší než v .NETu.

Ad WinApi, znát to Hitchcock, tak se vykašle na opeřence - znát autoři zombie horrorů X11, jistě by točili právě o tom :). Nicméně aplikace se většinou nepíšou pro Win32 ani X11. V případě Windows se píše většinou v .NETu.

Ad najít cokoliv na MSDN dokáže jenom Lael - s Visual Studiem máte lokální dokumentaci. Na webu MSDN se hledá celkem mizerně, protože je to web.

No, pokud dáš v dokumentaci vyhledat "DoTydlidum" a napíše ti to "Funkce DoTydlidum dělá tydlidum. Podporováno od verze 1-2-3. Parametry wzx, qgy, oba DWORD. Poznámka: Je nutné mít korektně nakonfigurovaný tydlidumátor. Byla tato informace užitečná?" a tlačítka Ano-Ne. Je fakt super, když nevíš, co ty parametry znamenají, jakou sekvencí funkcí volání funkcí se tydlidumátor konfiguruje a jestli je ta konfigurace dočasná pro jednu operaci a nemusí se updatovat po každým použití, nebo stačí jendou nastavit v initu a jestli je potřeba na konci ten tydlidumátor nějak deaktivovat. A příklad nikde není, protože je to closed code...

P.S: Zkoušel jsi někdy v C# přistupovat ne sériák? Zkus to, ale je to jenom pro hodně silný povahy.

Parametry jsou samozřejmě popsané. Vezměme si namátkou vytvoření procesu. Ve světě Win32 je to funkce CreateProcess(), v .NETu Process.Create(). Obě funkce mají i příklad použití. V případě .NETu jsem vybral overload s parametrem ProcessStartInfo, v popisu parametru je link který obsahuje jeho popis i příklad použití.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/0w4h05yb(v=vs.110).aspx

Ad Zkoušel jsi někdy v C# přistupovat ne sériák - v .NETu tuším 1.1 to byl problém, protože neexistovalo managed API. Od .NETu 2.0 existuje, a s jeho použitím nevidím problém.
http://msdn.microsoft.com/en-us/library/system.io.ports.serialport(v=vs.110).aspx

Já taky ne, pokud pakety mají stejnou délku. V okamžiku, kdy komuniikační protokol obsahuje délku zprávy uprostřed, je potřeba se rozhodnout z následujících možností:
- Přijmu část zprávy po délku a podle ní pak zbytek. Ztratím ale 3-5B (při rychosti 115200).
- Budu to chytat po jednom bytu, přijmu na přeskýčku 15-25% zprávy podle počasí a osvětlení (stejná příčina jako výše).
- Nastavím maximální délku paketu a čekám. Pokud přijde kratší paket, port neupozorní na existenci dat, neodešlu potvrzení a komunikace se zařízením visí.

A teď, Laeli, poraď. My to tady řešíme timerem a po jeho expiraci vyčtením dat.

Na prvním místě má sériový port FIFO buffer, ze kterého vybírá data OS do sekundárního bufferu, který má velikost minimálně 4kB (můžete si nastavit větší). Na druhém místě existuje RTS/CTS signalizace, kterou můžete dát druhé straně vědět, že nemá posílat víc dat, protože nejste ready. Bez flow control vám samozřejmě mohou data utéct.

Aha, takže bez RTS/CTS to nejde bez rizika... Už jsi viděl debug port na jednočipu, kde by byl hardwarový handshake? Nebo takovou RS485?

A proč to riziko existuje jenom v .NET? V C++ to chodilo, v Delphi s AsyncFree nikdy ztráta dat, na Linuxu standard bez problémů,... Jenom to C# je trochu mrzák na obě nohy.

Ad takovou RS485 - ale jistě. RS485 není RS232 :)

Ad proč to riziko existuje jenom v .NET - .NET používá garbage collector, a jeho načasování je z hlediska aplikace nedeterministické. Aplikace se tedy může na nějakou dobu "seknout", podobně jako v Javě. Bez flow control je ale riziko stejné i v C++, protože se provádění aplikace může seknout z různých jiných důvodů.

Ovšem pokud vám utíká víc dat (ne jednou za půl hodiny pár bytů), tipnu si že nemáte v obsluze události DataReceived zamykání. Buď bych tam použil lock, nebo implementoval thread který čte z com portu v loopu a čeká v něm na event, který mu pošlete z handleru události DataReceived. Obojí mi to přijde jako celkem základní techniky.

http://msdn.microsoft.com/en-us/library/ms838511%28v=winembedded.5%29.aspx

Ne, na Windowsech JE opravdu neběží. :D Nejsou realtimové. :)

Ona je kupodivu jaderka technologicky zarizeni z 50tych let. Funguje to, i se to ridi, prakticky uplne stejne, jako parni lokomotiva.

Z Windows se dá udělat RTOS bez změny jediné řádky kódu, například pomocí RTX64. JE ale asi opravdu neřídí.

Jde o Royal Navy of the United Kingdom, a pokud vím, tak SMCS-NG založený na Windows používají na jaderných ponorkách nadále. Američané používají Windows na lodích. V roce 1988 proběhla tiskem pěkná aférka, když se na lodi USS Yorktown při testování složil nový systém. Podle FUDu za to mohly Windows, ve skutečnosti šlo o chybu aplikace. Pokud jsem si všiml, US Navy používá Windows nadále. Vyjma toho můžete najít Windows (a .NET) třeba v izraelském protiraketovém systému Iron Dome, systémech Boomerang pro detekci střelby atd.

Vizualizace a UI ano. Samozřejmě, že vlastní řízení je na nějakých průmyslových automatech.

Hele, o manažery se neotírej, ti jsou náhodou vysoce igelitentní a genitální. Zrovna včra jeden manažer připravil školení o elektrice pro elektrikáře, kde dokázal na jednom slidu jednou větou s pomocí Ohmova zákona popřít Maxwellovy rovnice. A to při tom vůbec Ohmův zákon nezná...

Na takový borce prostě nemáme. Takhle jsem se nezasmál od čtení Laelovy argumentace v diskusi Jak jsem vracel licenci k Windows – Acer 2014

"Elektrické napětí vzniká pohybem elektronů" nebo tak něco, přesně si to nepamatuju. Sváděl jsem vnitřní boj s vyprsknutím smíchem.

Když tomu nerozumím, tak z toho snad nikoho neškolím, ne? Jak se slušně říká tomu, když si někdo, kdo elektrice nerozumí, pozve 60 lidí (z 90% absolventů FEKT VUT) a začne je poučovat o elektrice jenom proto, aby se vytáhl před svým šéfem?

Na vojně svého času docházelo k podobným absurditám:

"Soudruhu majore, dovoluji si vás upozornit, že to vypadá, jako by v tom vzorci yperitu, co jste namaloval na tabuli, byly ty uhlíky pětivazné."
- "Ano, výborně - a právě v tom spočívá ta jeho jedovatost!"

K absolventovi FJFI:
"A co je mezi atomovým jádrem a elektronovým obalem, ha?"
- "Elektrické pole?"
"Vysokoškolák a přitom tak blbej. No přece vzduch!"