forum.hwkitchen.cz

Ona ta rezie casto zase neni tak velka, par bytu u objektu samotneho jako odkaz na tabulku virtualnich funkci (spolecnou pro cely typ), pri volani virtualni funkce par asm instrukci navic a tabulka virtualnich funkci spolecna pro cely typ - casto by to clovek musel resit slozitejsima metodama, pokud by se v tom chtel vyznat.

Co je drazsi je dynamicke alokovani objektu, protoze to je prace s heap a volnym prostorem a pak zas jejich dealokovani (a volani konstruktoru a destruktoru pri tom) a prave v mikroprocesorech s malou RAM (kterou to muze fragmentovat) je lepsi to nepouzivat zbytecne (jako v tom prikladu). Na druhou stranu u staticky deklarovanych objektu to neni zas takovy problem.

Drahe to zacne byt az kdyz se to pouziva prehnane ("vsechno je objekt vcetne cisel") a tam, kde to neni potreba. Natoz kdyz se to pouziva za kazdou cenu, "protoze se to tak dela".

No a samozrejme u spatne navrzenych objektu, ale to je problem spatne navrzeneho programu, stejne jako nesmyslne smycky, neefektivni algoritmy a jine.

Stejne jako pro porovnani dvou cisel je blbost pouzit prevedeni na pole, pouziti sofistikovaneho sortovaciho algoritmu a prevedeni zpet, tak je blbost sortovani obrovskeho pole resit serii if-u pro vsechny kombinace.

Takze nasledujici kod je fakt nevhodny pro cela cisla mezi 0 a 255, ale muze byt fakt extremne vhodny, pokud a,b,c,d jsou matice a vektory, nerkuli vicerozmerna zverstva. (A v takovem pripade muze mit i velice dobry smysl pretizit operatory +*- a jim podobne.) Obzvlaste, kdyz se tim dost snizi sance na nejakou chybu a spoustu jich dokaze odchytat uz sam prekladac

Osobně si myslím, že i používání objektů v běžném strukturovaném jazyce, je píše taková móda, než opodstatněná záležitost.

- moda, ktera se vytrvale drzi prez pul stoleti a nejevi snahu opadnout, uz asi neco do sebe ma

Jak tak koukám, tak jestli tohle téma padne na srazu, tak z toho bude hospodská rvačka

Vše má své pro i proti. Být dobrým programátorem znamená znát tyto věci, umět si v hlavě představit co a jak se děje v tom procesoru a zvolit přesně tu zlatou optimální cestu. Ta RAM tam je od toho, aby se použila. Nemá cenu šmudlit pár bajtů, když mi ještě 80% zbývá. Jak si ale zapráská člověk RAMku nesmyslama z 20ti knihoven, tak se pak může divit i ušima, že se mu to kouše, nebo chová nestandartně.

Hele já myslím, že tu nikdo s nikým na kordy není. Ba naopak, po delší době se tu prostě objevilo téma, nad kterým má smysl přemýšlet a není to jen "stáhl jsem si tento example, domotal ho a on se mi rozbil"

Každý má nějaký svůj "rukopis", klade důraz na něco, co mu připadá důležité - a teď tady došlo ke konfrontaci a člověk měl možnost vidět cizí důvody, proč přikládat váhu tomu či onomu. Zároveň má každý tendenci uzavírat se do svých stereotypů, cizí pohled na věc tohle boří.

A to je největší přínos komunity. Sdílet a konfrontovat.
Více takových témat

Nerekl bych rvacka, spis hostinskemu pocmarame vsechny tacky a uctenky grafama, pametovymi schematy a vypocty, ve kterem pripade je dany postup vyhodnejsi a o kolik bytu/taktu a nekdo do toho pritahne par zajimavych myslenek, zatimco pivo bude chladnout a rizky zvetravat, nebo tak nejak

Jo jo, a já rád chmátnu po tom tácku, na kterém nakreslíš, že načtení INTu do registru zabere 4x tolik co BYTE. To mi totiž pořád nějak nesedí. Pokud atmega spálí 2 takty na načtení 8 b (BYTE), čekal bych, že na 16 b (INT) spálí 4 takty. Aha, tys uvažoval 32 bit INT, že? Pak by to sedělo. Já nikdy nepřekročil hranici Ardu UNO, kde je INT 16 bitový...

Ja taky uvazoval 16 bit, jenze pouziti je napriklad pricteni, kde uz musis resit prenos, nerkuli nasobeni, pri porovnavani taky mas mezipodminku na rady ... kdysi jsem koukal, jak se to preklada a proste mi to vyslo asi takhle nejak (jasne nekdy vic, nekdy min, ale malokdy pouhy dvojnasobek) - navic tech registru, ktere pouziva, je omezene mnozstvi a pokud promenna je pouzivana opakovane a neni volatile, tak se snazi ji pouzit z toho registru bez mezinacitani - pri 2x delsich promennych mu ty registry dojdou 2x rychleji a pak holt nemuze cachovat a musi znovu nacitat - cili klidne muze dojit k tomu, ze ta sama funkce s byte a s int v prvnim pripade bude pouzivat pro (znovu)nacteni promenne 0 taktu a v druhem minimalne 2. Obzvlaste to je pak zajimave, jakmile to nejsou "obycejne promenne", ale cosi prez nekolik objektu, ukazatelu, poli, indexu a tak - pak to nacitani je vyrazne delsi a kazde, ktere se podari usetrit muze byt docela znat

A to je avr instrukcni sada jeste zlata proti 8086, nebo z80

(a i na UNO potkas 32bit unsigned long long kdykoli napriklad pocitas s millis(), pokud uz sam nepotrebujes vetsi typ, nez jen 16b)