Vlákno názorů k článku Nástroje pro tvorbu UML diagramů od honza - [...] protože objektově orientovaný návrh každé složitější...

MFC je opravdu hrůza, stačí se podívat do jeho zdrojáků, kde je spousta berliček a různých ne-OO operací (jsou dodávány například s MSDN). V porovnání s relativní čistotou GTK nebo VCL (ale i starším OWL) nemá absolutně šanci a jsem docela rád, že v něm nemusím vytvářet aplikace.

Na druhou stranu je WinAPI pro programování docela příjemné, samozřejmě že se nedá porovnávat s GTK, to je o jednu vrstvu výše. V čistém WinAPI jsem v minulosti udělal docela dost aplikací a jde to docela rychle, prostě si "objekty/widgety" mezi sebou posílají zprávy, takže je stačí obalit do OO kódu a je to :-) Jo a WinAPI má ještě tu výhodu (alespoň co se týče GUI) v tom, že to opravdu funguje podle specifikace (to u MFC ani náhodou).

Doporučuji knížku od Charlese Petzolda "Programming Windows".

Máte pravdu, že jednoduchý program pro zobrazení okna ve WinAPI je poměrně dlouhý (stejně jako v Xlibu) a má to opravdu něco okolo sta řádků (spíš trošku míň, záleží na úpravě zdrojáku). Ale práce s dalšími GUI prvky už je jednodušší, prostě se ten první overhead musí překousnout - to stejné ostatně platí například pro DirectX.

ODBC vs JDBC - opět máte naprostou pravdu, ale já jsem se o WinAPI v předchozích příspěvcích vyjadřoval pouze z hlediska GUI. Tam to opravdu není tak špatné, zvláště když uvážíme, že je to z hlediska OS ta nejnižší úroveň (a také musíme uvážit rok vzniku tohoto API).

Jo, NASM není až tak špatný (i když ty jeho jednoduchá makra...). Použití funkcí s různým typem parametrů se nazývá přetěžování. Při polymorfismu se může (podle daných pravidel) měnit typ objektů, se kterými se pracuje - to v assembleru lze obejít vhodnými makry (makry teď myslím textové zpracování zdrojového textu před vlastním překladem, v některých assemblerech lze dělat makra mnohem mocnější než v C-čkovém preprocesoru).

Jo menit typ objektu ? Ja myslel ze v assembleru se spis musi obchazet ze to zadne typy nema :-). (Resp. assembler zna 3 typy integer a 2 float, ale na vsechny objekty se pouziva ten samy integer).

A dále má každý slušnější assembler podporu pro struktury apod. Samozřejmě, že instrukce pracují pouze s integery (ty jsou mimochodem čtyři, většinou to umí i 64bit integery) a floaty (těch jsou zase na x86 tři typy+poněkud podivný extended). Jde o to, že objekt je ve skutečnosti struktura (struct, record), která obsahuje datové složky a ukazatele na metody/funkce. Pomocí maker jde právě o to vhodně přejmenovávat ty struktury (před překladem) a tím pádem i měnit adresy volaných funkcí.

No mezi assemblery pro i386 (nemluvim ted o AMD64) jsem jeste 64bitovy integer nezahledl ... pokud nepocitas MMX, to snad je integer, ale to ma snad zase 128bitu ... o floatech se ovsem hadat nebudu, ja pouzival vzdycky jen jeden - ten nativni pro i387.

Mel jsem na mysli, ze obvykle se vytvari makra pro simulaci struktury/objektu na zminenem integeru, ale kdyz chces objekt pretypovat, proste pouzijes jine "typove" makro - nenapada me co by delalo makro pro pretypovani. Leda mozna kontrolu, ze je pretypovani korektni.

Minimálně tam jsou konstrukce typu DQ a RESQ, ale je pravda, že zrovna NASM pro ně akceptuje pouze floatové konstanty. Takový ASM86 (http://wolverine.caltech.edu/tools/asm86.htm) ale akceptuje i integery, takže se dá jednoduše pracovat s quad words. MMX je opravdu integer ukládaný do registrů FPU, kde však využívá z původních 80 bitů pouze 64 bitů.

Mas i nemas pravdu. Integer neakceptuje (a dost me to prekvapilo), ale krome float jeste akceptuje string. Co je ale dulezitejsi, promenne typu dq a resq ti jsou k nicemu kdyz s nimi nemuzes intuitivne pracovat (protoze se nevejdou do registru najednou).

No právě, některé assemblery (včetně TASM a NASM) Tě nutí pracovat na strašně nízké úrovni, tj. na úrovni jednotlivých instrukcí. Ale jsou assemblery (a asm86 je na platformě i86 jejich předchůdcem), které dovolují zapisovat "pseudoinstrukce", které toho umí trošku víc a přesto přesně víš, co tyto pseuinstrukce dělají, tj. jak se zapisují do strojového kódu.

Co například takovýto kód:
push eax, edx, ecx (není to jedna instrukce, ale slušný assembler to pro Tebe přeloží do více instrukcí)

nebo:
mov es:[ecx], ds:[ebx+0x00] (jeď nevím přesně, jak je to u nových procesorů, ale u i386 se toto přeložilo pomocí dvou či více instrukcí).

dále:
if ecx>0 jmp blabla (udělá se cmp a jng)

A také:
mov (edx, eax), 64bitová_data (zase se to přeloží na dvě instrukce)

Assembler je tady sice od toho, aby programátor přesně věděl co píše (a to do posleního byte), ale tato zjednodušení jsou jednoznačně dekódovatelná do jednotlivých instrukcí, tak proč je nepoužít.

Někdo může samozřejmě namítnout, že chce mít k dispozici pouze strojové instrukce. Ale i takový NASM se tuším chlubil tím, že dokáže "optimalizovat" (tj. rozeznat) dlouhé a krátké skoky, takže stejně do kódu zasahuje.

No jestli srovnavas s assemblery, ktere (na platformach i386 a x86-64) neexistuji ....
push eax, edx, ecx ... a inverzni je pop ecx,edx,eax nebo pop eax,edx,ecx ?
Dalsi znamy priklad je call funkce, arg1, arg2, coz se prelozi na push arg1 ; push arg2 ; call funkce ... nebo push arg2 ; push arg1 ; call funkce ...
mov es:[ecx],ds:[ebx+0x0] jde prelozit na dve instrukce (vim toho o AMD64 dost a nevim o tom ze by to slo napsat jednou instrukci), ale otazka je JAKE ? Pouzije se registr ? Ktery ? Nebo zasobnik ?
if ecx>0 jmp blabla ... jedine cemu nemam co vytknout.

S nasledujici vetou souhlasim, ale ty to prehanis. Mozna ti vsechny ty konstrukce prijdou zrejme, ale ne kazdemu ... osobne bych preferoval cestu tak silneho makrojazyka, aby bylo mozne prislusne efekty nasimulovat makry (takto NASM implementuje multipush a call s parametry). Pote je mozne se pri pochybnosti nebo z vyukovych duvodu na makro podivat.

I kdyz ... prehanis ... me na druhou stranu napadlo, ze by assembler mohl obsahovat generator vyrazu - tj neco co z expr(eax,ebx+5*ecx+(edx<<3)&33) udela

  mov eax,ebx
  add eax,ecx
  push ecx
  shl ecx,2
  add eax,ecx
  pop ecx
  push edx
  shl edx,3
  and edx,33
  add eax,edx
  pop edx

Pochopitelne s prisnym zakazem modifikovat cokoliv krome ciloveho registru a zasobniku, ale s volitelnym povolenim optimalizaci.

Já sy ty konstrukce nevymýšlím, byly už v nějaké podobě v assembleru a86 (tady se chci omluvit, nazýval jsem to v předchozích příspěvcích asm86 - holt už v ASM nějakou dobu nedělám, což je škoda). Jo mimochodem, a86 je sice za penize, ale jeho verze pouze pro reálný režim 8086 je zadarmo - v dávné minulosti mi to stačilo. A další pěkná featurka - při překladu se chyby zapíšou přímo do zdrojáku, takže stačí dát v editoru reaload a je to :-)

Takže když se mrkneš na stránku http://eji.com/a86/features.htm:

* A86 has language extension features that, once you start using, you'll never want to do without. These include multiple operands to PUSH and POP; conditional returns; MOV from one segment register to another; assembly time assertion checking; based structures; and IF (flag) (statement). (ty PUSHe a POPy jsou udělány přesně tak, jak by se to rozepsalo ručně, na RETurny s podmínkou jsem zapoměl - nechápu, proč je Intel do x86 nedal, když byly už v 8080)

* při MOVech, které ve skutečnosti na této platformě neexistují, se použije zásobník (to nemá v 99% případů na program žádný vliv, snad jen při specielně nastaveném SP)

* A86's macro processor is the best, achieving an optimal balance between ease of use and raw power. Its looping and text concatenation abilities let you define sophisticated macros, whose calls look just like the machine instructions that surround them; without the clumsy invocation syntax required by other macro processors of A86's power. - s těmito makry se právě dá dělat to OOP rozšíření, i když je pravda, že to jde i v NASMu.

S tím přeháněním máš asi pravdu, na druhou stranu si myslím, že assembler je tu dnes pouze pro speciální případy, takže s ním stejně pracuje odborník. btw: stejně je každý assembler na i86 jiný, stačí se podívat na syntaxe MASMu, TASMu, NASMu, GASu a A86. Nejčistší je určitě NASM, naopak TASM se svými dvěma režimy (které ještě jdou kombinovat) a spoustou direktiv je při zkoumání cizího zdrojáku docela hrůza.

Sorry, v tom odkazu neměla být ta dvojtečka (Root to špatně pochopil, jde o interpunkční znaménko). Správně je to pouze takto http://eji.com/a86/features.htm

Reklama dobra, ale mimo.
1) Je to placeny. Realny mod mi nestaci a pokud to znamena, ze navic nemam 386+ instrukce, tak mi nestacil nikdy.
2) Zda se, ze je to Win/DOS only. To me taky nestaci.
3) A dneska uz mi nestaci ani kdyz to neni open-source ...

Ano, souhlasim, TASM s NASM muzu srovnavat a NASM je mnohem lepsi z mnoha hledisek vcetne prehlednosti. Treba takove assume je PRISERNY zabijak prehlednosti.

No, já z prodeje A86 (resp. A386) nic nemám :-))) Jen jsem chtěl ukázat, že i některé assemblery pro platformu i86 mohou obsahovat různé zajímavé fíčurky. A86 mám doma už dlouho (a taky ho už dlouho nepoužívám, přesně z těch důvodů, že volná verze nemá instrukce 386+), ale ve své době to bylo lepší než TASM, zejména na mé pomalé mašině.

NASM samozřejmě v té době neexistoval, ten se rozšířil až po rozšíření GCC na i86. A musím říct, že mě příjemně překvapil, ze začátku to vypadalo na další marný pokus o vytvoření slušného assembleru, ale teď je na dost vysoké úrovni. Jen mi chybí linker, někdy člověk nemá k dispozici celé prostředí pro GCC (v minulosti jsem tahal TASM a TLINK spolu s VC a zdojáky na jedné disketě a nic jiného jsem nepotřeboval, to byly časy).

Jo mimochodem, nevím jak je to s MASM, ale TASM je stále v nabídce Borlandů :-) Samozřejmě, že ne na reklamách, ale na jejich site se dá najít :-)

Jasne ... ale obavam se, ze po open-source assembleru s podobnymi features opravdu neni dost velky zajem ... i ja bych ted spis nez features potreboval NASM pro x86_64 ...

Jiste. To je duvod, proc jsem zacinal na TASM a proc v nem porad mam vic radek kodu nez v NASM ...
Jak, chybi linker ? Kdyz chces ELFa, tak na kazdem linuxu gcc (a ld) je, a kdyz chces aplikaci pro DOS, pouzijes bin a slinkuje ti to rovnou NASM ... i kdyz, ja pro DOS taky pouzivam spis obj a TLINK ...

MASM je hrozne. Ten jeho makrojazyk je totalne necitelny a je hlavni pricinou, proc jsem nikdy nenapsal ovladac zarizeni do Windows - vsechny navody byly v MASM.

Ano, s prvním bodem souhlasím. Když jsem se tak různě díval na věci i assembleru, všichni tvrdili: "máš GAS, tak co pořád otravuješ". Až na to, že GAS má (alespoň pro mě) dost šílenou syntaxi, žádné kontroly atd. Prostě je to "pouze" filtr pro výstup z GCC.

Linker všude nemám, například když nabootuji Danix, Slax apod. Ale chybí mi to hlavně pro DOS a Windows. V DOSu to umí pouze .comy, nebo se pletu a vyšší verze již zvládají něco lepšího, tj. exáče (mám verzi 0.98)?

Já jsem jeden složitější ovladač pro Windows (95 a NT, tj. ve skutečnosti dva zdrojáky) odlaďoval, ale to bylo napsané v C++ (!) a s pomocí DDK. Fakt je, že na toto se Borlandi nikdy nechytali, takže se muselo použít něco od Microsoftu.

GAS ma syntaxi silenou, ale alespon uz umi intel verzi - tj. registry jsou porad s %, ale v "normalnim" poradi.

Nejsem si jisty, ale myslim ze knoppix linker ma ...

Pletes se, na EXE neni nic lepsiho :-). Ano, umi jen .comy, ale v holem DOSu ti to uplne staci. Uspesne jsem pouzival .com s 3mi segmenty - jeden aktualni, jeden v UMB a jeden v chranenem modu. Pochopitelne, PE uz je jina zalezitost.

No fuj ovladac v C++ a jeste pres DDK ...

No, já jsem ten ovladač převzal, abych v něm opravil chyby, takže jsem ho nijak dalece neupravoval. Je fakt, že z C++ tam bylo pouze předávání parametrů pomocí referencí, inline funkce a takové spíš neobjektové rozšíření C-čka. Po kompilaci to mělo pár kilo (DDK k tomu ovladači prakticky nepřibaluje žádné další funkce ani knihovny).

Osobně bych chtěl vyzkoušet v čistém ASM prográmky pod Win32. Problém je právě v tom linkeru a hlavičkových souborech pro assembler. On teda není problém ty hlavičkové soubory sehnat, ale pouze pro MASM :-(

Myslis ve skutecne napsanem kodu, nebo komplet vcetne po rozbaleni maker ?

Ehm ... ja jsem psal v cistem assembleru (tasm a pozdeji nasm) programky pod Win32. Teda, u tasm si nejsem jisty jestli to bylo Win32, ale u nasm ano protoze to uz byly PE. Jako linker jsem pouzival alink (ALINK v1.6 is copyright 1998/9 Anthony A.J. Williams.). Hlavickovy soubor ma na zacatku "Win32.inc for NASM 1999 version 0.06 by Tamas Kaproncai [tomcat@szif.hu]", nicmene pozdeji jsem neco doplnoval rucne. Oboji jsem sehnal jako casti neceho zvaneho "The Win32 NASM coding Toolkit v0.2" od gij <at> iname.com, adresu nevim, v readme chybi.

Tím myslím vygenerované .vxd-čko nebo .sys-ko.

Díky za ten odkaz na Win32.inc, zkusím ho najít (Google už něco vychrlil). Předpokládám, že to je pouze pro Win32 a ne pro Directy, OpenGL apod? Teda, ne že bych to opravdu potřeboval, jen jsem si s tím chtěl ve volném čase (až někdy bude) pohrát.

Jak uz jsem rikal, neni tam ani cele win32 ... stringy "directx" a "opengl" se v celem souboru nevyskytuji. Na druhou stranu ... v baliku je i soubor "DDraw.inc for NASM 1999 version 0.01 by Tamas Kaproncai [tomcat@szif.hu]" ... a to nemluvim o tom, ze pravdepodobne budu mit zastaralou verzi.

Jo, taky si rikam ze si nekdy zkusim pohrat s OpenGL (ovsem normalne v C a pod linuxem). Mozna, ze v duchodu se k tomu dostanu ... porad to ma vetsi prioritu nez zkusit hrat na ISA soundblaster primo pres porty a DMA. Na vrcholu seznamu pohrani si je zrovna x86_64 - pocitac uz mam a myslim, ze prekladac budu mit driv nez cas :-).

Nějak se nám ty odstavce na Rootu zužují, jestlipak to půjde až do nulové šířky :-)

Pokud je tam pouze DDraw.inc, tak to by bohatě stačilo (stejně chci pouze blitovat pixmapy). S ISovým SB jsem si hrál, dokonce jsme si s bráchou koupili originál SB 16 (ten byl zajímavý tím, že na sobě měl IDE port pro CD-ROM, který nešel vypnout, takže pořád obsazoval jedno IRQ). Je to celkem fajn, akorát mě vadilo to časování při přístupu k portům - nechápu, proč tam nedali nějaké latche.

Ad čas - tak to ho asi moc nemáš :-)

Uvidime :-).

To ja mam CMI8330 nebo tak neco. V dobe, kdy jsem ji mel novou jsem planoval napsat neco jako vlastni operacni system nebo alespon vrstvu driveru pro operacni system (jeste jsem nevedel o linuxu) a nedostal jsem se k tomu - mel jsem ovladac pro IDE (vcetne UDMA33) a chystal se na graficky mod SVGA, ale linux prisel driv.

Nemam. Jsem zamestnany a mam dlouhe seznamy dulezitejsich veci, jako treba sledovani roota :-).

Dalsi polozka na seznamu: napsat php script, ktery vytvori "verzi pro tisk" (tj. verzi neobsahujici zbytecne sloupecky po stranach, vhodnou pro prohlizeni na PDA, pro grepovani a pro setreni mista na CD) ze soucasne verze stranek roota. Respektive mozna na to bude stacit XSLT sablona, uvidime.

Jiste, kdyby tu verzi pridali primo na rootovi, fungovala by lepe a bylo by to snazsi (protoze root ma k dispozici data PRED pridanim sablon), o tom ze bych s tim mel mnohem mene prace ja osobne nemluve. Ale zda se, ze ani oni nemaji cas.