Vlákno názorů k článku
Oblíbenost jazyka C v TIOBE stále klesá od K> - a koukam ze opet roste visual basic .NET....

Fortran prinasa nespravne programatorske navyky. Bol to de facto prvy vseobecne pouzivany programovaci jazyk a navrhari este celkom dobre nevedeli co robia. Teoria jazykov este bola v plienkach (ak nejaka bola). Rozne chyby v navrhu sa mohli identifikovat az potom, ako vznikol fortran.

Fortran sa oplati vediet ako kuriozitu, podobne ako sa oplati vediet citat staroveku aramejcinu. Na priucenie sa niecomu je bezcenny.

O jakem Fortranu se to bavis? FORTRAN II od IBM, FORTRAN 66, FORTRAN 77 nebo Fortran 90? Tim, ze to pises malymi pismeny, predpokladam Fortran 90, ale ten uz prakticky zadne historicky dane problemy nema.

To hovori kazdy.

A ty FORTRAN umíš? Zjevně ne, protože bys věděl že jeho návrháři věděli velmi dobře co dělají, zkus si pro začátek nastudovat makrojazyky které mu předcházely. Budeš se divit co všechno už před FORTRANem programátoři používali...

Nj, preto som napisal prvy "vseobecne pouzivany" pan Radovan. Ja viem ze pani Ada Lovelace napisala program pre babbageov stroj, no to neratam.

Pokud by to bylo pro nějaký mikrokontrolér bez násobičky, bylo by na facku, pokud by to chtěl dělat jinak než posunem.

Náhodou, když jsem optimalizoval kritické místo v Céčku na Arduinu Uno a nechtěl jsem jít do assembleru, podobná změna udělala docela rozdíl.

Tak tady je spis otazka kde je chyba :). Sice jste neuvedl konkretni pripad operace. Ale od jakehokoliv trochu inteligentniho prekladace, ktery vy pro jaky hw kompiluje bych ocekaval podobne optimalizace automaticky. Pokud se nedeji je chyba v prekladaci a ne v programatorovi.

Osobne jsem zastancem ze kazdy usetreny takt ma cenu, ale ne za cenu prehlednosti kodu (az na vyjmecne pripady). Takze napriklad nasobeni dvema urcite nebudu nahrazovat bitovim posuvem. Operaci modulo budu sice optimalizovat, ale to jen tak aby to davalo smysl, aneb operator modulo pouziji, jen se postaram o to aby ve statisticky nejcastejsich pripadech se jednalo o deleni/modulo konstantou.

Jsem se samozrejme upsal. Na konci jsem chtel zminit ze vyuziji vlastnosti ze pokud kompilator vi jakou hodnotou se provadi modulo, tak se muze vyhnout deleni a kdyz vim ze se nakonec deleni nevyhnu z duvodu nasledujici ci predchazejici operaci tak se podle toho zaridim (a i to lepsi prekladac zvladne)

Narazal som na:

"Spis by kazdej mel vedet, ze ve vysledku je z ty jeho patlanice strojak ... a mel by povine aspon 50 radku svyho kodu do nej rucne prepsat, aby se na vlastni voci presvedcil, jakou prasarnu to vlastne vytvoril."

To ze kompilator vytvori spagetti kod, ktory bezi na konkretnom procesore, rychlo je v tomto kontexte irelevantne.

Skvělé. Takže budu spoléhat na to, že překladač optimalizuje můj rádoby přehledný kód, místo abych si byl jistý a přidal do zdrojáku k tomu bitovému posunu objasňující komentář.
Geniální myšlenka. Zkuste to v USA patentovat - to projde.

Dnešní překladače tam, za běžných podmínek, bitový posun nanejvýš pravděpodobně dají.
Ale o to já se nepřu. Prostě nevidím nic špatného na takové konstrukci, pokud jsem si vědom, že zrovna na tomto místě to má být rychlé(pravdě­podobně to pak trkne i toho, který to někdy po mně bude číst a upravovat). Poznámka v kódu pak odstraní případnou nejasnost.

Udržovatelnost zabíjejí daleko spíš čuňata, která se neobtěžují dodržovat domluvenou nomenklaturu a z identifikátoru proměnné pak na první pohled není vidět, zda jde o argument funkce, lokální či globální proměnnou a také nejde odhadnout co v ní je(jde li třeba o bitové pole, čítač, hodnotu signálu atd...). O tom, že jsou třeba ještě schopni se z funkce vracet na několika místech raději nehovořit...

Jasne, mnohem lepsi je mit mikroptimalizovany kod (coz je pro vetsinu prekladacu vec, ktera spise uskodi nez zlepsi), ktery je navic hure citelny a udrzovatelny, ale co kdyby to tam nahodou prekladac nedal :-D
Nehlede na to, ze o optimalizacnich algoritmech soucasnych prekladacu evidentne nic nevis