Matrix class - spravnost kodu

[frca]

Já osobně nikdy nic necpu do dll, pokud to není nutné (licence knihovny atd.). Je to ale spíš takový nějaký můj pocit daný tím, že nevím, co pozitivního by mi taková dll knihovna přinesla.
_________________
www.FRANTICWARE.com

[nou]

usetrenie miesta v pameti. ak kniznicu pouziva viacero processow tak staci aby bola v pameti iba raz.
bezpecnost. ak je v kniznici chyba staci aktualizovat iba ju a nie cely program.

samozrejme ak je to interna kniznica ktora je pouzivane prakticky len danym programom tak nema zmysel davat to naschaval do dll. ak to ale ma byt extrena kniznica vtedy dava pouzitie dll zmysel.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[frca]

Pokud je ten dll soubor nahraný přímo v adresáři u programu, tak systém nepozná, že už třeba někde jinde stejná knihovna nahraná je, ne? (Tzn. z indentického souboru, ale z jiné cesty.) Mluvím například o knihovně SDL, která je typicky přibalená ke hře. Tam je to dll jen proto, že musí z důvodu licence. A kopírovat svoji dll knihovnu do systémového adresáře mi taky nepřipadá nejšťastnější z toho důvodu, že widle nemají žádnou správu závislostí, takže vznikne akorát tak silné dll hell.
_________________
www.FRANTICWARE.com

[if.then]

1. Templates - nechápu, vždyť v renderování grafiky má opodstatnění POUZE float a double (ať už kvůli operacím např. v OpenGL, kvůli binárním souborům nebo kvůli něčemu úplně jinému), podle toho, jak velké chceš objekty se mezi nimi rozhodneš.

2. Je tam moc funkcí. Měl bys začít s pár důležitými funkcemi (součin matic, identity, násobení trojrozměrného vektoru...) a pak - pokud to uznáš za vhodné - přidat další.

3. Public data jsou, ehm... zdržím se výrazů jako prasárna apod., ale prostě je to trošku složitější. Zaprvé je mnohem hezčí, když ta matice vypadá jako pole 16 prvků s "přidanou hodnotou", zadruhé si představ, že budeš chtít checkovat chyby. Třeba u matic bys v debugu chtěl kouknout, zda jim nepřiřazuješ INFINITY nebo NAN (not a number). Pokud v té chvíli budeš mít nadefinovaný operátor [] a budeš přiřazovat pouze přes něj, tak se nebudeš muset uchylovat k šíleným hackům (třeba pole 16 prvků pro debug a třídu s operátorem [] pro release), abys toto chování vzal.

4. Nadefinovat namespace Math je kapánek o hubu, je to tak rozšířené slovo, že bych se nedivil, kdyby ho používaly např. i nějaké knihovny. Pak tam předefinuješ funkci a bum - linker error je na světě. Osobně preferuji prefixovat personální projekty přezdívkou (třeba namespace ifthen).

5. Diskutuje se o tom, co by mělo být struct a co class - v C++ je struct vlastně skoro to samé jako class (snad kromě implicitních přístupových práv), takže je to na každém - já beru structy jako třídy s pár public proměnnými, pár funkcemi a bez konstruktoru a destruktoru, ke kterým se přistupuje jen v nějaké nadřazené třídě a tam jsou private - takže třeba třída pro UV. Pokud to jednu z těchto podmínek nesplňuje, tak píšu class. Ale tohle je docela na tobě, C++ je dost volné a umožňuje ti to psát, jak sám uznáš za vhodné. Ale obyčejně se velké třídy s konstruktorem/destruktorem píšou jenom jako class.
_________________
For guns and glory, go to www.ceske-hry.cz.
For work and worry, execute VC++.

[perry]

Dll jsem myslel z důvodu případného update ... změním jenom knihovnu a ne celý *.exe... ale to už je detail

[Tringi]

[nou]

[Tringi]

Já tak trochu tuším, že tady někteří zaměňují overloading (přetěžování funkcí a operátorů) za overriding (převažování/překrývání virtuálních funkcí u polymorfizmu).

EDIT: Jinak nou máš samozřejmě pravdu, dynamický dispatch přes vtable je volání přes dva pointery, a to o něco pomalejší samozřejmě je. Nicméně na moderních architekturách to může být stále rychlejší než blbě napsaný IF.
_________________
WWW | GitHub | TW

[Vilem Otte]

MSVC říká, že overloading se nevyplácí... btw verze kompiléru:

[igor]

No a nebude to něčím jiným než overloadingem? Nevím, jestli jsem ten popis dobře pochopil a nějak nevím, jestli se tady všichni baví o tom samém, ale vec3/OverloadedVec3 se asi líší trochu víc než názvy funkcí/metod? Overloading by (pokud se nějak šeredně nepletu) přece měl fungovat tak, že kompilátor s názvy funkcí provede name mangling tak, aby se každá funkce líšila jménem (přilepí tam další znaky podle typů parametrů apod.) a mělo by být jedno, jestli se původně v kódu různé funkce jmenovaly stejně (s různými typy parametrů) nebo úplně jinak. Je to spíš něco blízko kategorii "syntaktický cukr" a umožňuje jenom použití pohodlnějších názvů v kódu.




EDIT:

No a není to teda spíš tím, že jedna verze má operátory a druhá metody? To by snad taky mělo být stejné, ale nedělal by s tím divné věci kompilátor spíš než jenom s názvy metod (třeba používá specifické optimalizace pro operátory, které mají většinou určitým způsobem podobnou sémantiku?). Dělá to samé, když v obou verzích jsou normální metody, přičemž v jedné se jmenují stejně a ve druhé různě?

[Tringi]

Přesně tak, operátor je jen extra pojmenovaná funkce a syntaktický "cukr"
U GCC se tento rozdíl smaže na GIMPLE úrovni, mnohem dřív než se dostane na generování instrukcí.

Koukám na ten první ASM výstup a nestačím se divit, že tohle leze z MSVC. Nejsem sice expert na x86 instrukce ale zdá se mi, že některé ty MOVy jsou zcela zbytečné, snad jako by to bylo bez některých optimalizací, a další vypadají jako by se ti tam dostal aliasovaný pointer nebo coloringu chyběl registr. Nemůžeš ukázat kód toho vec3/OverloadedVec3?

Btw. ta aproximace sin/cos je pěkná.
_________________
WWW | GitHub | TW

[Vilem Otte]

Operátor by měla být normální funkce s __forceinline, při kompilaci by se mělo překódovávat její jméno (a nakonec u ní by měl být nějaký index - aby se "odlišily různé overloady" - tedy overloading je jenom jinak pojmenovávání funkcí pro uživatele - kompilér je poté vezme jako standardní funkce (problém je, že u nich nemusí zadefinovat __forceinline - to už záleží na délce procedury operátoru a zda se do ní posílá struct - alespoň u MSVC to tak je, ale záleží na kompilátoru).

Samozřejmě Trinigi měl teoreticky pravdu - overloading by neměl mít žádné instrukce navíc, já se na to díval z praktického hlediska (především MSVC, ICC afaik generuje pro overloady mnohem kratší kód než MSVC), a tam mě praxe naučila - dokud není nutné pro přehlednost, nepoužívat overloady (zpomalují v něm). Tedy na kompiléru záleží.

Kód tady pošlu, jak budu doma (teď večer jsem odjel pryč, a nepíši ani z mého PC), i s ukázkovou aplikací (možná zkompilovanou pod GCC i ICC).

Možná by stálo za to, hodit nějaké ty chytré funkce, jako tento sin/cos na wiki - možná to tam napíšu (zkusím ještě nějaké pěkné věci vyhrabat). Dokonce ten sin/cos mám napsaný i v SSE

Jinak skutečně, ty movy tam jsou navíc (a je jich dost) - optimálně by to mělo asi o 4 instrukce navíc (což, pokud neděláš opravdu extrémnosti, neznamená ve výkonu nic navíc - bohužel třeba u mého path traceru to jde poznat (přešel jsem z overloaded funkcí na neoverloaded - a nárust byl cca 0.4 - 1.6 procenta ve výkonu ... jenom bych ale dodal, že to bylo spíše způsobeno tím, že operátory nebyly kompilérem inlinovány a jednalo se o overhead při spoustě volání), pravda to JE extrémnost)
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[perry]

Ta funkce na fast sin/cos je sice pěkná, ovšem v porovnání s klasikou sin/cos

[rezna]

@perry - to co tu pisou Vilem Otte, VladR, eosie, ... muzes klidne pro zatim vyhodit z hlavy a resit normalnejsi veci

az budes ve stavu ze budes potrebovat optimalizovat i uplne capiny, treba kvuli raytraceru, tak se sem vrat a pocti si

jinak tyhle veci aktualne vubec smysl nemaji a vzdy plati radeji hezci kod o malicko pomalejsi nez delat v aktualni fazi premature-optimization - to vede akorat do pekla

[Houp]

Co tu myslím nezaznělo, jestli je třeba mít T jako typ parametru u všech metod. Jestli by někde neměl být nějaký typ natvrdo.

Např. si nejsem jist, jestli u matice, která používá inty, je vhodné mít scale jen na inty (nikdy to scalem nezmenšíš) a takových příkladů by se asi našlo více.

Tedy ode mě malé upozornění, že to, že budeš mít hlavní datovou strukturu typu T, tak jestli musí být i argumenty metod typu T.
_________________