Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Kit

Stran: 1 ... 17 18 [19] 20 21 ... 47
271
Pokud chcete lepší notebook, tak doporučuji nějaký repas od HP, Lenovo, DELL.
Od nějakých cca 7000,- koupíte určitě něco, co má mnohem větší smysl než nové notebooky v nejnižší cennové hladině.

Bohužel ty repasy nevydrží 12 hodin na jedno nabití jako nový netbook. Pokud nepotřebuje extra výkon (já ho tedy nepotřebuji, kompiluji na serveru), tak i ten levný kousek poslouží.

272
Osobně bych šel do
https://m.heureka.cz/notebooky/asus-e203na-fd021ts/
protože mám dobrou zkušenost s předchozím modelem.

273
Vývoj / Re:Preferovaný zápis jména pole jako ukazatele
« kdy: 12. 07. 2020, 11:39:04 »
Ten první zápis je jen syntaktickým cukrem pro druhý zápis. Který z nich používat? Přece ten, který je přehlednější v daném místě programu. Zpravidla ten první, ale dá se najít mnoho situací, ve kterých je lepší ten druhý.

274
Studium a uplatnění / Re:Elektro nebo IT VŠ?
« kdy: 04. 07. 2020, 15:31:17 »
Podle popisu spíš IT, elektroechnika se tam v potřebné míře učí také.

276
Hardware / Re:Výběr NAS: QNAP nebo Synology
« kdy: 17. 06. 2020, 19:55:47 »
Odroid

277
Vývoj / Re:Kreslení složitého objektu do HTML5 canvas
« kdy: 15. 06. 2020, 00:07:42 »
Pokud uvažuješ o DOM, tak to rovnou udělej v SVG. Vykreslí se to samo.

278
Vývoj / Re:Abstrakce u OOP
« kdy: 13. 06. 2020, 23:05:05 »
musíš tam uviesť typ návratovej hodnoty (čo je tiež riadna otrava) moderné jazyky, ktoré používajú Hindley-Milner typový systém si vedia v 99% typ odvodiť automaticky (a tam kde si nevedia sa použije typová anotácia)

Nemůžeš porovnávat C s moderními jazyky. Tenkrát byla potřebná efektivní nadstavba nad assemblerem tak, aby se nemusel pro každý procesor psát program znovu, což bylo splněno. Tehdejší výkon procesorů by na dnešní jazyky asi nestačil.

Škoda jen, že na Fortran se tak nějak pozapomnělo. Už tenkrát měl mnohé, čím se holedbají moderní jazyky.

279
Vývoj / Re:Abstrakce u OOP
« kdy: 13. 06. 2020, 19:30:27 »
Tak ideálně by krátký měly být věci, který používáš nejčastěji. Ne zhovadilý "function", ale radši "func" a úplně ideálně "fn" :)

Jazyk C šel se zkracováním ještě dál a nedává tam nic.

280
Vývoj / Re:Abstrakce u OOP
« kdy: 13. 06. 2020, 17:57:53 »
IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.

Lokální symboly mají být krátké, ideálně jednoslovní. U globálních symbolů s tím nevystačíme, proto používáme slepence podle různých notací (např. v C) nebo v moderních jazycích s pomocí namespace. Zásadou je nepoužívat zkráceniny, ale pro řídicí proměnné cyklu se názvy i, j, k tak zažily, že je zbytečné proti nim bojovat.

281
Vývoj / Re:Abstrakce u OOP
« kdy: 13. 06. 2020, 16:35:00 »
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
Bavíme se o situaci bez komentářů. Několik vrstev abstrakce bez komentářů, proč tam která vrstva je a jakou má zodpovědnost, je naprostá tragédie.
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
Kód: [Vybrat]
for (i=1;i<61 && feof(h);i++) {...}
Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

Klíčové slovo for, závorky, && a další symboly jsou jazykovými konstrukty, které znát musíš, pokud chceš pracovat s C. Jediným neznámým prvkem by mohla být funkce feof(), která není součástí jazyka, ale jeho knihovny stdio.

282
Vývoj / Re:Abstrakce u OOP
« kdy: 13. 06. 2020, 00:02:08 »

Nemuze to byt tim, ze C je prilis low level a postrada expresivitu vyssich jazyku?
Od skoly sem v nem nic nepsal ani necet a to uz je davno takze tady se nemuzu moc vyjadrovat.

To není tím. Ať mi někdo vysvětlí, proč tohle nejde napsat slušněji i v tom C:
Kód: [Vybrat]
printk(KERN_INFO "%s: dev %s: flags=%llx\n", msg,
rq->rq_disk ? rq->rq_disk->disk_name : "?",
(unsigned long long) rq->cmd_flags);

Jen takový pokus:
Kód: [Vybrat]
device = rq->rq_disk ? rq->rq_disk->disk_name : "?";
flags = (unsigned long long) rq->cmd_flags;
printk(KERN_INFO "%s: dev %s: flags=%llx\n", msg, device, flags);

Kompilací vznikne shodný kód, ale přidáním názvů proměnných se zvýší čitelnost pro lidi.

283
Vývoj / Re:Abstrakce u OOP
« kdy: 12. 06. 2020, 23:09:05 »
Když někdo neumí pojmenovat proměnou, tak je to fakt blbě a v takových případech zpravidla nepomohou ani komentáře.
Pošli tam pull request s opravou. A poštou trochu CDS. Good luck.

Proč bych to dělal? Nejsem vývojářem linuxového jádra. K čemu CDS? Linus ujíždí na savu?

284
Vývoj / Re:Abstrakce u OOP
« kdy: 12. 06. 2020, 22:54:04 »
... Například proto, že nevím, co je v poli blk_op_name uložené. Takže kdyby tam nebyl ten komentář, musím skočit na jeho definici a z ní na definici makra REQ_OP_NAME, pak si budu muset vzpomenout, jak se vlastně nahrazují ty # a ##. A až mi docvakne, jak je to vlastně triviální, musím odskákat zase zpátky. Jasně, klidně mi někdo může tvrdit, že si to z kódu přečte líp než z těch pár řádků komentáře. Nebo že CDS bezvadně léčí rakovinu... Ok, good luck.

Když někdo neumí pojmenovat proměnou, tak je to fakt blbě a v takových případech zpravidla nepomohou ani komentáře.

285
Vývoj / Re:Abstrakce u OOP
« kdy: 12. 06. 2020, 22:20:07 »
Základ jsou docstringy k metodám a třídám.

K čemu jsou docstringy, když mám parametry i návratové hodnoty řádně otypovány?
Ke zdokumentování kódu.

O zdokumentování kódu se přece postarají typy a testy.

Stran: 1 ... 17 18 [19] 20 21 ... 47