https://blog.root.cz/inkvizitor/ https://i.iinfo.cz/r/rss-88x31.gif 88 31 https://blog.root.cz/inkvizitor/ Poslední přidané názory v blogu inkvizitor cs Tue, 21 Apr 2009 19:14:34 GMT https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832165?utm_source=rss&utm_medium=text&utm_campaign=rss [31] "..., vývoj typu napíšu jednu metodu, otestuju, přidám řádek, otestuju, je trochu jiný přístup." Nevím, je otázkou na kolik takový přístup je užitečný... To by taky vývoj jedné třídy mohl trvat půl roku a než by jste byl hotový, tak by jste možná zapoměl proč tu třídu vlastně píšete. :-) D.A.Tiger Tue, 21 Apr 2009 19:14:34 GMT blog.root.cz-blogComment-832165 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832164?utm_source=rss&utm_medium=text&utm_campaign=rss [30] Já jsem nepsal o tom, že z kontraktů vzejde TDD, to je samozřejmě úplně jiný přístup k vývoji SW. Nemyslím si, že by bylo nutné spouštět analyzátor tak často, aby bylo nutné řešit, zda bude trvat 2 sekundy nebo půl minuty. Kromě toho i syntaktickou analýzu lze dělat inkrementálně, ale jak říkám, vývoj typu napíšu jednu metodu, otestuju, přidám řádek, otestuju, je trochu jiný přístup. Mimochodem, ten dokument, který jsem vzpomínal, je i volně přístupný, jak jsem zjistil. Takže pokud by měl někdo zájem, může se podívat sem: http://dev.eiffel.com/CddBranch inkvizitor Tue, 21 Apr 2009 18:43:08 GMT blog.root.cz-blogComment-832164 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832163?utm_source=rss&utm_medium=text&utm_campaign=rss [28] - nemyslim si ze by rozbite STL diky novejsi verzi kompilatoru byl az tak ojedinely stav, specialne kdyz ta verze STL je starsiho data. - u TDD nejde vyuzit kontrakty uvedene v kodu ke generovani testu z principu (pokud myslite primo Unit testy): u TDD nejdriv vznika test, pak kod, takze v dobe kdyz je kod(+kontrakty) napsany, uz neni co generovat. To by mozna slo spis naopak, z unit testu vytahnout kontrakty. Ale cele to nedava moc smysl, protoze unit testy samotne muzou pokryt i veskery prostor ktery ma k dispozici staticka analyza, jedina nevyhoda je v tom ze potrebuji prelozit a spustit, staticka analyza muze probihat bez prekladu. (ale musi byt o dost rychlejsi nez build + unit test run, co nemusi byt az tak trivialni pri slozitosti syntaxe C++) Vzhledem k tomu ze u TDD se doporucuje mit dobu buildu + behu testu pod 2sec ... to klade na tu statickou analyzu hodne extremni pozadavky. Leda ze by jste myslel generovani dodatecnych QA testu (z pohledu TDD duplicitnich), to jiz urcitou logiku ma, ale podle mne to kvalitni lidskou ruku urcite nenahradi, a nejspis ani nedoplni, nebo jen ve stastnych pripadech nahodou. Ale nemam s tim zadnou praktickou zkusenost, soudim tak jen z obecne zkusenosti s elektronikou a SW, kde plati ze nic nefunguje tak jak ma a co se NEmuze pokazit, to se pokazi v nejmene vhodne chvili. O tom co se muze pokazit nema smysl ani diskutovat, to je pokazene non stop. :) Ped Tue, 21 Apr 2009 10:04:43 GMT blog.root.cz-blogComment-832163 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832162?utm_source=rss&utm_medium=text&utm_campaign=rss [24] To totiž nedělá knihovna, ale překladač. Na této úrovni je to už trochu něco mezi nebem a zemí ( :D ). Všimněte si, že tyto seznamy typů (typelist) jsou schopny (a to je hlavní důvod proč byli v Loki vytvořeny) vygenerovat v době překladu celou a kompletní hierarchii tříd. Tyhle seznamy manipulují přímo s jednotlivými datovými typy (ne s jejich hodnotami). Toho využívá kupříkladu abstraktní továrna na objekty (tamtéž). Domnívám se, že pokud bych postavil operace s konkrétními hodnotami položek seznamu jako typy, pak by to šlo. Upřímně, ten nápad nepochází z mí hlavy, ale od Alexandrescua, a s takovými věcmi jako je funkce eval, bych se asi už nepopral, ale principiálně by to podle mého názoru fungovat mohlo. (Je už otázkou zda by to k něčemu bylo užitečné...) Nechci nikam výše :-) . Když už, tak jsem si oblíbil TCL (a to pouze na jednoúčelové skripty - asi tak jak jiní využívají BASH), a díky panu Tišnovskému, začínám pomalu koketovat s jazykem LUA, ale zase v kontextu programů psaných v C++ (tedy žádné bindingi a pod.). C++ je pro mě prostě "ten pravý" :-D D.A.Tiger Mon, 20 Apr 2009 23:11:01 GMT blog.root.cz-blogComment-832162 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832161?utm_source=rss&utm_medium=text&utm_campaign=rss [15] "Moje" makro assert() je to klasické z jazyka C, byl to jenom jednoduchý příklad. Ale samozřejmě není problém nadefinovat si makro vlastní, které vyhodí třeba právě tu výjimku. Jestli je lepší nechat program natvrdo sletět, nebo se raději snažit z toho nějak vybruslit, je určitě otázka konkrétní aplikace. Pamatuji si na předlouhý thread v konferenci cz.comp.linux před lety na toto téma. Byl to docela slušný flamewar. [16] Kompilátor samozřejmě má vliv také, ale to už je vcelku extrémní příklad, podle mě. TDD je zajímavý z několika důvodů. Třeba tím, že přímo vybízí k tomu, aby programátor dodržoval v článku uvedené principy nebo tím, že často nabourává politiku přístupových práv v některých jazycích (Java). V dokumentu, který je, žel, k dispozici pouze po zaplacení předplatného (já jsem si ho zaplatil a myslím, že nebudu litovat, protože v knihovně jsou k dispozici zajímavé materiály právě z hlediska statické analýzy a podobných disciplín) tvrdí skupina, v níž je i Bertrand Meyer, že ke generování jednotkových testů lze využít právě kontrakty uvedené v kódu (použitý nástroj je EiffelStudio: http://portal.acm.org/citation.cfm?doid=1287624.1287685 [20] Vytvoření tabulky faktoriálů při kompilaci je jistě teoreticky možné, ale je to dobrý nápad? Pokud tu funkci volám často a input je omezen shora poměrně malým číslem, pak možná ano (ale i tak lze tu tabulku budovat dynamicky za běhu, ikdyž v tom případě porušíme uvedené principy), ale pokud tomu tak není, bude asi lepší líný přístup. C takový typ definovat neumožňuje, jinak by ta legrace s assertem byla koneckonců zbytečná, ale v C++ by to implementovat šlo. Podle mě to úsilí při použití C++ není zbytečné - jednak v C++ existuje obrovské množství programů a další pořád přibývají a jednak se s podobnými potížemi jako v C++ setkáme i v jiných imperativních nebo hybridních jazycích. Třeba taková Java mi přijde v něčem i horší než C++, protože nutí programátory používat třídy i tam, kde se moc nehodí a svádí je tím k porušování referenční integrity a ke kódu plnému vedlejších efektů. Děkuji všem za reakce. inkvizitor Mon, 20 Apr 2009 22:56:01 GMT blog.root.cz-blogComment-832161 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832160?utm_source=rss&utm_medium=text&utm_campaign=rss [25] ano to myslim naprosto vazne. JavaScript (aniz bych se ho chtel nejak zvlast zastavat) je jeden z nejvice nepochopenych programovacich jazyku dneska. Asi nejvic mu uskodila spatna implementace v browserech, takyprogramatori vyvijejici metodou copy&paste bez hlubsiho porozumeni problemu a taky literatura, kterou snad psali lide, co JavaScriptu neporozumeli (no par vyjimek je, ale dost malo). Ale jde o vysokourovnovy jazyk s funkcionalnimi rysy, plnou podporou funkci (funkce je datovy typ se vsim vsudy), uzavery atd. Navic s celkem nenapadnou syntaxi, ktere se lidi tak neleknou, narozdil od Lispu (ale ten za to nemuze, prave diky jeho syntaxi je to tak mocny jazyk :-) hyperion Mon, 20 Apr 2009 21:08:10 GMT blog.root.cz-blogComment-832160 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832159?utm_source=rss&utm_medium=text&utm_campaign=rss "naopak kvalitni QA vyzaduje od testu nejenom 100% code coverage, ale i redundantni testy ktere dukladne otestuji funkce jestli opravdu pocitaji to co maji." Alternativou je ještě Knuthův přístup - "Beware of bugs in the above code; I have only proved it correct, not tried it". :-) Ksl Mon, 20 Apr 2009 18:37:54 GMT blog.root.cz-blogComment-832159 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832158?utm_source=rss&utm_medium=text&utm_campaign=rss 24: od nízkopodlažního C++ výše k JavaScriptu? arnolt Mon, 20 Apr 2009 16:21:10 GMT blog.root.cz-blogComment-832158 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832157?utm_source=rss&utm_medium=text&utm_campaign=rss [20] - C ani C++ s vetsimi cisly nez je long long pracovat bez obezlicek neumi, sice to v C++ jde zabalit do objektu, ale hoodne velkou ciselnou konstantu nedas :-), stejne jako se budou muset prepsat vsechny metody pro iostream, konverze atd., docela dost prace... - integer 0 10 a podobne deklarace se musi v C++ obchazet pomoci objektu a pretezovani operatoru (operatory - to je takove celkem zbytecne syntakticke cukratko), preteceni opet nutno imperativne napsat do kodu k onomu objektu. Dtto pro pole - runtime checking na prekroceni mezi ve standardu nenajdes. [21] - skutecne jsou ty seznamy ekvivalentni s Lispovymi? Ja se tedy Lispu nechci nijak zastavat, jen podotykam, ze i samotny kod je v Lispu zapisovan do seznamu - tj. lze napriklad s kodem ruzne manipulovat (skolni priklad-symbolicka derivace vyrazu), zavolat eval atd. Nevim nevim, ale to zadna knihovna nad kompilovanym jazykem asi neda :-) Jestli chcete jit od techto nizkopodlaznich jazyku nekam "vyse", zkuste Lisp (Scheme), Python ci Lua, popripade i ten JavaScript ujde. hyperion Mon, 20 Apr 2009 15:29:17 GMT blog.root.cz-blogComment-832157 https://blog.root.cz/inkvizitor/bezpecne-programovani-v-c-iii/#o832156?utm_source=rss&utm_medium=text&utm_campaign=rss [22] To je pravda. Nicméně, to jsou jeho uživatelé, ne jeho tvůrci, či jazyk sám.... Pokud vím, tak sám Straustroup někde ve své knize "C++ programovací jazyk" říká, že C++ je založeno na datových typech a strukturách a ne objektech. Jenže (alespoň z mých zkušeností a soudě podle toho jak je podobný jiným jazykům) k tomu musí asi každý dojít sám... Jinými slovy, podle mě to vychází z toho, že C++ nebylo pochopeno, nebo z falešného pocitu, že když C++ není plně objektový jazyk, tak je méně cenný. Nebo prostě z obavy, že by náhodou mohl mýt pravdu někdo jiný... D.A.Tiger Mon, 20 Apr 2009 13:00:40 GMT blog.root.cz-blogComment-832156