killgore zei:
Eenvoudiger zou ik die libs zeker niet noemen, en qua veiligheid: ms heeft in zen laatste vs niet voor niets de helft van de C functies door een *_s (safe) equivalent vervangen (beke ridicuul imho, ma kom ...). Waar ik je wel in kan volgen is dat je meer controle hebt in C tov java bv en daardoor dus de veiligheid kan verhogen, maar ik zie niet direct een voordeel van wat gij zegt van c vs c++.
Wat in godsnaam doet compilatietijd er nu toe? Het is niet alsof je om de 5 mins een volledige rebuild van je project gaat doen he ... .
De veiligheid komt er niet zozeer door meer controle te hebben (dat kan soms zelfs nadelig zijn), maar vooral door een kleiner en meer overzichtelijk systeem te hebben. Waar veiligheid echt kritiek is gebruikt men soms zelfs subsets van C, gewoon om het aantal dingen dat gecontroleerd moet worden te beperken.
Hoe meer dingen de betekenis van code kunnen beïnvloeden (overloading bijvoorbeeld), hoe moeilijker ze te controleren.
Nu kan ek u totaal nie volgen
. Ik steek niet meer code in een wapen als een C-programmeur, enkel is het meer opgesplitst en kan ik veel simpeler een 2e wapen creëren, een derde, een vierde, ... .
Alles via scripts buiten uw programma laten regelen verhoogt wel immens uw laadtijd maar is een mogelijkheid inderdaad. Maar ik zie bv. niet in waarom ik geen klasse ScriptedWeapon zou kunnen afleiden dan die diezelfde functionaliteit aanbiedt. Of versta ik je verkeerd met dat scripted? Je moet het ook als 1 geheel zien he, ik heb hier nu specifiek Weapon->Gun->Winchester gedaan, je kan altijd makkelijk bijmaken bv: Weapon->Gun, Weapon->Knife, Weapon->missile, ..., het gaat hem daarrond.
edit: en zoals vich zei: natuurlijk zit in nog grotere systemen weapon dan nog eens verpakt in iets anders, ma kunt ier moeilijk een ganse game-engine als vb plaatsen <_<.
Wel, wat ik bedoel is dat je soorten gedrag/eigenschappen van wapens in de code zet, maar niet de specifieke wapens zelf. Anders mag je elke keer je de mondingssnelheid van je Winchester wil veranderen je code wel hercompileren
Met script bedoel ik niet de hele wapenlogica in een scripttaal uitvoeren, eerder iets als dit:
wapen Winchester
type geweer
kaliber .30
munitietype FMJ
...en de rest van de eigenschappen.
Dat wordt dan gewoon bij het starten van het spel ingeladen, de engine bevat alles om die eigenschappen dan samen te stellen tot het wapen dat in het spel komt. Liever een ander kaliber? Gewoon een tekstbestand aanpassen, geen code.
Over complexiteit: dat is juist, was ook 1 van de zaken die ik met die php programmeurs bedoelde. Ze gaan overal oop toepassen waar het niet nodig is, dit houdt in alles wrappen wat ze tegenkomen en elk systeem dat ze coden in een klasse te steken hoewel ze het nooit zullen kunnen hergebruiken.
Dat is echter een probleem van de programmeur en niet van OOP, mind the difference.
Zal ook wel voor een deel aan de rare voorbeelden liggen in sommige inleidende boeken. De inleiding tot OOP bij Turbo Pascal 7 (slingert hier nog ergens rond) gebruikte bijvoorbeeld een overerving van insect naar gevleugeld insect naar bij... Ook een manier om de indruk te geven dat je elk object uit de natuur in een klassenhiërarchie moet proppen, terwijl het eigenlijk eerder een manier om code te organiseren is.
Natuurlijk
, al mijn eigen math-functies zijn functioneel geprogrammeerd, 90% van mijn memmanagement functies (string functies), ... . In java/c# zijn dit dan meestal statische variabelen/methoden -> ook functioneel geprogrammeerd.
Maar 1 specifiek voorbeeld weerlegt niet dat OOP op een pak ander vlakken nuttiger kan zijn...
Ik verwerp het gebruik van functioneel programmeren ook niet geheel hoor, ik vind dat een goede samenhang van functioneel programmeren (voor zaken als dit bv) en oop persoonlijk het beste nog. Zoals ek al zei: ik heb lang genoeg functioneel geprogrammeerd in php en c++, is zelfs niet verleden tijd, er zijn nog genoeg kleine projecten in c++ waarvan ek denk: daar ga ek nu toch geen klasse voor maken ... .
Dat lijkt eerder imperatief. Functioneel verwijst gewoonlijk naar (bijna) zuivere functionele talen zoals Haskell of ML.
Tyfius zei:
Echt, ge doet mij elke keer meer lachen. Ik zal u ook eens doen lachen: winapi is log, traag en grote brol. Ze zouden da moeten afschaffen en alle programmeurs verbannen naar een of ander eiland.
Yep, winapi is maar rommelig. Leve POSIX
Direct3D was trouwens ook nogal ongepast. MS moest weer eens speciaal gaan doen, terwijl OpenGL al beschikbaar (en beter) was. OK, uiteindelijk is er wel een min of meer gebruiksvriendelijke Direct3D gekomen, maar die eerste versies...
The Crazy Frog zei:
2D graphics ftw
Nene, ik heb het gewoon niet voor .net (zoals je al gemerkt hebt)... Een 20 mb grote framework voor een notepad clone vind ik zottenwerk, Kvind het een beetje raar dat ze niet gewoon de gebruikte libs in de exe steken, zoals bij C (feel free to explain why).
1. alle programma's samen plus 1 lib neemt minder plaats in dan wanneer elk programma een stuk van de libs bevat.
2. mogelijkheid bugfixes van de libs uit te voeren (voor beveiliging bijvoorbeeld) zonder alle programma's te moeten herlinken.
(al moet ik toegeven dat dat laatste heel wat beter gaat op besturingssystemen met fatsoenlijke versie-ondersteuning dan op Windows, waar velen uit pure wanhoop gewoon een kopie van alle libs in de programmadirectory zetten. DLL hell
)
) maar voor de rest vind ik winapi een zeer goede api.