> De azt sokféleképpen valósíthatja meg; a valódi kötöttség annyi, hogy a kódnak ugyanazt kell csinálnia, de az nincs megkötve, hogy ugyanúgy.
A C++ szabvány eléggé megköti a fordító kezét. Nem lehet nagyobb módosításokat csinálni. Haskellben azt csinál a fordító mondjuk azzal a quicksort-tal, amit akar, csak a végeredmény legyen jó.
> Haskellnél meg van egy feltételhalmazod, amiből neki nem csak a hogyant, de a mit is ki kell találnia.
Pont ez az egyik lényege. Kitalálja ő neked, neked nem kell vele foglalkoznod. Most az, hogyha bug van a fordítóban, akkor mi van, azt inkább hagyjuk, szerintem nem annyira érv :)
> éppen ezért van ötvenezer féle forgatásra vonatkozó kapcsolója a compilereknek, hogy megtaláld az optimálisat.
Ja, csak az egyik kódrészre egyik fajta kapcsoló kell, a másikra meg másik. Ez így nem igazán használható.
> De most akkor azt az egész algoritmust nulláról újraírtad assemblyben a leforgatott kódban, vagy csak belejavítottál?
Szerintem ez nem számít. Az a lényeg, hogy amit a compiler generál, lehet jobbat csinálni. De egyébként nyilván az ember először megnézi, mit csinált a fordító, és ha majdnem jó, akkor inkább azt javítja ki, mint nulláról írja meg. De sokszor van olyan, hogy sajnos nulláról kell megírni.
> Meg a goto kérdését. Szerintem nonszensz, hogy evil lenne.
Félreértettél. Pont arra próbáltam meg felhívni a figyelmet, hogy a goto-ról azt mondják, hogy evil, és az exceptionról, pedig hogy jó (jó, vannak ellenvélemények, de messze nem olyan a megítélése, mint a goto-nak). Pedig az exception sokkal durvább ugrásokat csinál, mint egy goto. Nekem semmi bajom a goto-val, ha épp azzal lehet megoldani valamit a legjobban, simán leírom.
Update: OK :)
> Jó volna a kódot is látni, meg a fordítási opciókat, meg az azokra adott assemblyt. Persze nem vitatom, hogy néha eléggé hulladék a végeredmény, amit ki tudnak dobni magukból a fordítók, de elég sok múlik a "bemeneten", meg a különféle beállításokon.
Nem volt benne semmi komoly amúgy. De amúgy, miért is elfogadott az, hogy beállítások kellenek? Egy dolgot mondok meg neki, hogy milyen CPU-ra optimalizáljon. Miért is kéne neki segíteni mindenféle beállítással, ha jó kódot tud generálni? A CPU adott, szeretném a leggyorsabb kódot, ennyi. És miért is múlik a bemeneten bármi is? Leírom egy absztrakt nyelven az algoritmust. Szeretném, hogy ez az algoritmus a lehető leggyorsabban fusson le. Azt nem várom el tőle, hogy egy buborék rendezésből quicksortot csináljon. De egy csomó mást elvárhatnék tőle. Ezért mondom, hogy a mostani fordítók még nagyon nincsenek ott, hogy bármilyen szinten is versenyre keljenek egy tapasztalt asm programozóval.
> Nekem ennél jobb tapasztalataim vannak a C fordítókkal...
Pont ezt mondom :) Ha régi architektúrára dolgozol, akkor ott nagy általánosságban jó kódot csinálnak. A mostani CPU-kra csinálnak szinte mindig suboptimális kódot, és esetenként pedig nagyon rosszat. Ami egy egyszerűbb CPU-nál nem igazán (volt) megszokott. Régi CPU-ra tudsz jobb kódot írni kézzel, mint amit a compiler csinál, de általánosságban nem lesz sokkal jobb. Az új, bonyolultabb CPU-knál meg egy apróságot elront a fordító, és hopsz, 30%-kal lassabb lesz a kód.