Diskuze: Malý test programování.
Tvůrce
Zobrazeno 7 zpráv z 7.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
Popis řešení dodám, pokud bude mít několik účastníků zájem. Pro
praktické použití to nemá význam, jde mi jen o to zda někdo najde
řešení.
Jak to udělat nepředepisuji, je to myšleno jako zadání pro procvičení,
takový malý test.
Pokud někdo přijímá zakázku, tak zadavatel neříká jak zadaný problém
bude dotyčný řešit.
PZ
Ty mi neorzumíš.. Uvědom si jak si to podal - upnul si exečko a napsal si k tomu že je to test programování a zadání úplně k ničemu.
To je popis jak kdybys tam napsal "hele čumte na to, stahujte je to
hustýýý".
Nevíme v jakém jazyce, nevíme co to je, co se má s tim dělat, jediná
instrukce je že to máme stáhnout a spustit a to ti nikdo rozumnej
neudělá.
Navíc těch EXE souborů je tam víc, takže člověk si ani (bez návodu) není jistý, který z nich se předpokládá, že spustí (nebylo nic řečeno, takže možná jeden bude za účelem implementace nějaké své funkce pouštět druhý atd.).
Pokud mám soudit z velikosti EXE souborů a za About boxu u color pickeru, psal jsi to v MASM (pokud jsi samozřejmě při volání funkce ShellAboutA zadal správný řetězec). Takže není divu, že budeš mít výhodu. Také je vidět, že jsi to psal v čistém Windows API (minimálně ten color picker), takže bych se nidivil, kdybys, co se týče spotřeby paměti a velikosti souborů, neměl problém vyhrát.
Nikdy jsem moc nechápal, proč v Assembleru psát GUI. Ano, je to malé a rychlé, ale dá to dost práce,, kterou je dle mě obvykle lepší investovat do vylepšení toho, co má aplikace reálně dělat. Pokud použiješ nějakou nativní GUI nadstavbu (VCLv Delphi, Qt), její rychlost je dostatečná, aby si uživatel nestěžoval (u Windows Forms (.NET) jsem si občas všiml, že je pomalé, ale a) už se asi dnes moc nepoužívá oproti WPF, b) nmoc se v tom nevyznám).
P.S.
Co se týče color pickeru, dnešní assemblery obvykle seberou i
hexadecimální čísla začínející prefixem 0x, nemusí
končit písmenem h.
P.P.S.
Úplně si tím MASM nejsem jistý, protože IDA HexRays Decompiler (testováno
na color pickeru) neměl problémy s "překladem" kódu do C/C++. Což by mohlo
naznačovat, že pokud jsi psal opravdu v Assembleru, zas tak moc jsi
neoptimalizoval, jinak by to decompiler nezvládl (na druhou stranu se ti
nedivím, když se optimalizuje, nedá se to pak číst).
Odpovídám na Richarda a na Vrtule.
1) je to psáno v MASM 32.
2) Po přeinstalování na Windows 10 jsem si položil otázku zda program v
MASM bude chodit na 10.Stáří
tohoto programu je myslím několik desítek let.
3) Proto jsem zkusil 4 různé objekty, jako důchodce jsem neměl co na
práci.
4) V žádném případě jsem neměl za cíl něco vyhrát, trochu mi štvalo u
některých jak se vychvalují znalostí
assembleru. (Znalost assembleru .....). Co asi dělali v dnešní době v
assembleru?
5) Na začátku jsem napsal, že praktický význam to nemá, v tomto směru
souhlasím s Martinem.
6) Možná chyba byla, že jsem neřekl, že je to napsané v assembleru.
7) Optimalisace nebyla žádná, ani překlad do C/C++ jsem nezkoušel.
Jako cíl jsem požadoval
libovolný podobný program.
Tolik na vysvětlení.
Zobrazeno 7 zpráv z 7.