Já nevím, že se vždycky najde nějaký *** který musí přinést nějaký hate.
Windows se v průmyslu používání hodně, spoustu jich najdete třeba i v našich jaderných elektrárnách (většinou UI).
Skutečnost je ale taková, že na kritické věci se silně nehodí ani windows, ani linux, ale systémy jako VxWorks (který jezdí třeba po Marsu)...
Ano, jako UI se používají hodně. Ani ne tak kvůli jejich kvalitám, jako spíš kvůli tomu, že lidé, kteří o tom rozhodují(včetně toho pro kterou platformu se před nasazením software vůbec bude vyvíjet), nic jiného neznají.
A pak se všichni třesou, kdy se tam dostane nějaký úplně běžný malware.
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.
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í.
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?
V MS tyhle veci nepise robot, ale debil. Vzdyt i helpy k aplikacim jsou delane tak, ze kdyz chcete vedet, co dela X, help vam rekne treba, ze nastavuje X. Oni to tam pisi jen kvuli Laelovi, aby tu mohl rikat, ze MS ma nejlepsi dokumentaci (nejlepsi=nejrozsahlejsi), ale zaroven tak, aby tu dokumentaci nikdo nedokazal pouzit.
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.
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++.
Jiste, mohli to napatlat v .Netu, akorat tedy nevim, jak by to pak natlacili na jine platformy, nez Widle. A i kdyby to slo, tak browser, ktery na telefonu startuje ctvrt hodiny, by nikdo nechtel.
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...
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.
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.
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
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!"
Proč by mompiloval jádro? Prostě by se to zbuildovalo a otestovalo na Zemi. U komety by to jenom za 20s nabootovalo (volba v GRUBu se přeskočí) a hotovo. Nová funkcionalita v jádře přece není potřeba. A opatchování + restart o několik řádů rychlejší, než cesta fotky ze sondy. A hlavně, nabootuje.
Tak hlavne dneska nikdo nedokaze udelat moderni CPU (myslim tim obdobu CPU co je v PC) v military provedeni, natoz v low-powered+radiation hardened provedeni, to v principu ani nejde, ledaze by sonda vazila 3x tolik :)
Vsak nad nama lita spousta ruznych RCA1801 (to je starsi nez vetsina ctenaru roota :), 8051, 8080, snad par 80386, nic moc novejsiho vlastne ani neni potreba.
To neni o "modernim" CPU. To je o technologii. Cim mensi rozmery, tim min je to odolny proti radiaci. Proto se pouzivaji tyhle "vykopavky", protoze pri rozmerech technologie, jakou jsou vyrobeny, to proste snese nepomerne vyssi davky, nez to zacne chybovat.
Mimochodem, telefonni ustredny telecumu (cast), obsahuji klientsky desky, po tisicovce pripojek (obslouzi ta deska) ... a .... je na tom 80386.
Duvody? Spolehlivost, chlazeni(netreba), vykonostne bohate dostatecne ... a ... rozsirenost instrukcni sady = snadno a levne se pro to programuje.
Oni by casto konstrukteri nejradsi pouzili elektronky, jenze to uz ponekud hodne nabourava hmotnostni rozpocet.