Diskuze: čtení stringu po slovech
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Neregistrovaný

Zobrazeno 32 zpráv z 82.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
for(int num = 1; num < 11; num++)
Console.WriteLine(num);
A správně:
Uzivatele.Find(u => u.Jmeno == "Karel");
Kouknu a vidím. Napiš mi tohle v ASM.
Tak paráda, možná s tvým frameworkem to je mírně přehlednější ale stejně je to hůře čitelné... tohle asi nemá cenu, vždycky když je diskuze o low a high, každý si brání svoje... já a asi 90% dalších prostě už nevidí v ASM smysl.
Ano kompilátor to stejěn převede do strojové podoby ale to už nás
nemusí zajímat. Chápu že nadáváš na lidi co absolutně nic netuší a
prohlašují se za programátory. Určitě je dobrý vědět jak to funguje pod
pokličkou ale dělat v tom ? V dnešní době se hraje o čas, takže raději šáhnu po něčem s
čím si práci urychlím, je to moderní, přehledné atd atd (však už jsme
to říkali).
A u firem, i kdyby jsi měl super ultra znalosti ASM stejěn vezmou člověka co umí dobře třeba C# + ASP.NET, SQL nebo Javu apod
Nejsem si jistý, jestli hledáš v poli stringů nebo objektů. Každopádně si ty zápisy porovnej a představ si, že je to v metodě, kde se podobná logika řeší pro desítky různých entit.
Takže jsi prostě strávil X hodin nad vytvořením vlastnního frameworku
Netvrdím že to je špatně,
je to dobrý, naučí to spousta ale prostě tvrdit že je lepší dělat v ASM
než moderně je blbost..
Já původně chtěl jen OS... Pak jsem zjistil, že se dá celkem snadno
aplikovat OOP. (Skutečně se mi podařilo odříznout každý objekt.) Ke
každé třídě mám seznam skoků - kterými určím adresy k jednotlivým
funkcím. Netrvalo dlouho a vyrval jsem dokonce srdce OS - kernel. Je to ale
jeden z nečistých objektů - na jiný OS bych ho musel upravit. Ovšem není
divu - když je to sám o sobě OS... Tedy v BootSectoru přerušuji na paměť v NTFS pro kernel.
Aby mi to vůbec fungovalo, musel jsem sepsat několik map se vstupy a
výstupy jednotlivých funkcí. Takže ano - je to kolikrát na hlavu... Ale bez
IDE také nebudete znát vstupy a výstupy... (Já si IDE udělal - takže s
těmi mapami pracuje...) Samozřejmě v tomhle se mohu jít zahrabat...
Ne, chceš nám dokázat jak moc jsi dobrý a já to respektuju a uznávám, ale prostě v dnešní době je blbost dělat v ASM když tne samý program můžu udělat 3x rychleji
3x rychleji je to napsáno, ale program běží 10x pomaleji a sežere 10x
více paměti
Jak již tu bylo milionkrát řečeno, pokud to není OS nebo engine, tak na čase absolutně nezáleží.
Když se bude chtít dosáhnout větší rychlosti šáhne se třeba po C++ ne ? V dnešní době pro většinu běžných aplikací nebudu řešit jestli se mi to zpracovává 5ms nebo 10ms
Napsáno v čem? Jestli myslíš strojový kód/assembly, tak jak jsem napsal - spravovat vyšší funkce lze - stačí používat vyšší registry a sys soubory... Takže pokud myslíš strojový kód/assembly, jsi vedle...
"...pokud to není OS nebo engine, tak na čase absolutně nezáleží"
Za tenhle názor bych dával pěstí, pak nemaj bejt programátoři prasata
Na čase záleží vždy, pokud je to nějaká dlouhotrvající nebo opakující
se akce.
Zákazníkovi/uživateli je fuk, jestli je kód hezký a splňuje všechny
normy, jde mu o rychlost programu a odezvu, vnitřek ho nezajímá.
Dumdych: Vývoj v assembly je pomalejší než třeba v C# (neříkám, že zrovna 3x, to byla jen narážka na Zirka), ale výsledný program (byl-li napsán v asm) je rychlejší a má menší nároky na paměť.
Ne, nezáleží na něm vůbec a dobří programátoři svůj kód ani neoptimalizují. Jelikož používají kvalitní struktury a nástroje co daný jazyk poskytuje, není k tomu žádný důvod. Nenapadá mě kde bych mohl v C# řešit něco jako dobu běhu programu, to patří tak možná do céčka, kde si někdo patlá na koleni quicksort.
Však - to snad vím... Jen
jsem zauvažoval zda nemáš na mysli spravování vyšších funkcí. Bez
optimalizace by to tak nebylo. Viz. DOS. Už jen grafické shelly pro DOS - tam
je krásně vydět echo způsobené zpožďováním, dále nízká grafika a
vůbec celkově celý OS působí rozbitě... Proto jak jsem psal - chráněný
režim a vyšší funkce obecně lze v assembly/strojovém kódu používat - a
tím tedy pekelně optimalizovat... Takže lze využívat i moderní rozměry
HDD...
Tak to zase nesouhlasím .
Někdy je rychlost důležitá a občas je třeba nutné (te´d to vezmu řpímo
příklad z WinRT pro Win8) udělat aplikaci tak aby nevyapadla že něco
dělá, berte to tak že dělá složitý výpočet a uživateli nesmí
zamrznout, musí vidět efekt přejetí tlačítka apod.
Ano, ale to řešíš až v případě, když je to pomalé.
Tebe by neštval třeba program, ve kterém při každé běžné akci, kterou denně provedeš třeba 100x, musíš třeba 20 vteřin čekat, když bys věděl, že se ta funkce dala napsat tak, aby trvala třeba jen vteřinu a jen se to programátorovi nechtělo optimalizovat?
Můžeš mi dát nějaký reálný příklad takového problému? Jinak řešíme běžné úkony programů, na těch časově opravdu nezáleží. Když je program v něčem pomalý, až tehdy se optimalizuje a jen ten jeden úsek.
Když uvážím na jakých frekvencích jsou dnešní procesory
taktovány,
tak je každá činnost programu, kterou mohu zaznamenat pouhým okem,
vlastně neskutečně pomalá. Ale většina uživatelů je zvyklá na svoje
kafíčko po každém druhém myšokliku.
Zatím naštěstí většině programátorů jde i o rychlost programu a u
těch pomalých jsem zdroják nezkoumal, tak nevím, jestli by šly ty akce
zrychlit, takže o takové situaci nevím
"Když je program v něčem pomalý, až tehdy se optimalizuje a jen ten
jeden úsek."
S tím už souhlasím.
Zatím se vždy snažím psát ty programy rychlé, ale v algoritmizaci
nejsem nijak extra třída .
Zatím mě vždy běželi rychle a občas jsem je testoval i na pomalejších
PC... no já se tu pánové klidím, už budu jenom přihlížet
Tohle už je extra mimo mě...
časem vám do tooh začnu kecat taky
A souhlasím s oba názory. Jak sdraca tak tvým. Programátor by to neměl
flákat, stejěn jednou dojde k tomu že ot nějak vylepší, proč to nenapsat
alespoň slušněji než normálně ?
Kompilátory vyšších programovacích jazyků většinou mívají zabudovánu optimalizaci výstupního kódu. Nejúčinnější bývá zejména když programátor používá obvyklé konstrukce a na optimalizace se vykašle.
Ovšem zbývá definovat, co jsou to "obvyklé konstrukce". Ty nejvhodnější bývají nazývány "Design patterns".
Pro assemblery samozřejmě platí jiná pravidla než pro OO nebo funkcionální jazyky.
To by mě zajímalo, proč si kdekdo pojmenovává svůj framework názvem Framework. To je stejné, jako kdyby se můj pes jmenoval Pes.
"Kompilátory vyšších programovacích jazyků většinou mívají zabudovánu optimalizaci výstupního kódu."
Ano, ale ta optimalizace jen do určité míry, spoustu optimalizací musí
člověk stejně dělat ručně.
Kompilátory obvykle dělají jen takové ty úplně základní věci jako
unrolling cyklů, vyházení nepotřebného kódu, inlinování krátkých
funkcí, ale složitější konstrukce musí většinou optimalizovat
programátor.
Právě že programátoři často zbytečně dělají složité (rádoby optimalizující) konstrukce, které se kompilátoru špatně optimalizují.
Některé optimalizace umí i samotné procesory, ale to se už kódu netýká.
Zobrazeno 32 zpráv z 82.