[c++] Programmeren voor het symbian OS

[Verwijderd]

Hey

Ik ben al een tijdje rond aan het zoeken op internet voor informatie over programmeren voor het symbian OS.

Naar mijn weten zien hier drie opties voor:

OPL(Hier heb ik wat ervaring mee omdat ik dit ooit gebruikt heb om programmatjes te maken voor me psion)

J2ME

Symbian C++

Persoonlijk denk ik dat OPL niet echt uitgebreid is en een beetje oud.

J2ME lijkt me handig om games mee te schrijven, maar voor normale programma's lijkt mij Symbian c++ het beste.

Als iemand denkt dat dit niet echt klopt of als er meerdere talen mogelijk zijn dan hoor ik dat graag...

Maar mij leek het interresant om me eens te verdiepen in symbian c++, maar ik kan hier erg weinig over vinden, daarom een paar vragen:

Is er een nederlandstalige site met duidelijke informatie voor beginners?

Of is er een engelstalige site duidelijker dan nokia.com?

Hoeveel voorkennis is er nodig om symbian c++ te leren?

Als er kennis nodig is van c++, voordat ik aan symbian c++ begin wat raad je me dan aan om op te orienteren?

Is er iets dat ik zeker moet weten over programmeren voor symbian OS hoor ik dit graag..

Ps. Ik wil me vooral verdiepen in de series 60


Ik hoop dat jullie me verder kunnen helpen(Y)

Niels

[Verwijderd]

Ik raad je aan om eerst met J2ME te beginnen, je kan er meer mee
doen dan games. Zeker als je telefoon MIDP2.0 ondersteunt loop je niet snel tegen de grenzen van J2ME aan, tenzij je speciaal floating point nodig hebt.

Ik kan je ook aanraden om een goed J2ME boek te kopen (tip: ISBN 0-07-222710-9, J2ME: The Complete Reference).

Ik heb wat Symbian C++ boeken gekocht, maar heb het nog niet weten
op te brengen om er mee aan de slag te gaan. Je kan het vergelijken met Visual C++: veel OS specifiek constructies en (relatief) weinig C++. Niet "lekker" te programmeren.

[.oisyn]

Verwijderd schreef op 09 mei 2004 @ 21:26:
J2ME lijkt me handig om games mee te schrijven, maar voor normale programma's lijkt mij Symbian c++ het beste.

Met J2ME kun je ook applicaties maken, en als je echt goed performende games wil maken zul je ook met symbian aan de slag moeten

Of is er een engelstalige site duidelijker dan nokia.com?

[google=symbian programming]
Ik zie zat nuttige sites. Ben je al eens gewoon naar www.symbian.com gegaan?

Hoeveel voorkennis is er nodig om symbian c++ te leren?

Nou het is sowieso wel handig dat je überhaupt kunt programmeren, en kennis van C++ is ook wel essentieel

Als er kennis nodig is van c++, voordat ik aan symbian c++ begin wat raad je me dan aan om op te orienteren?

Volgens mij begrijp je het niet helemaal . Symbian C++ is geen taal, maar een platform. C++ is de taal, en symbian levert gewoon een library die je kunt gebruiken om verder met het apparaat te communiceren.

Verwijderd schreef op 09 mei 2004 @ 22:40:
Je kan het vergelijken met Visual C++: veel OS specifiek constructies en (relatief) weinig C++. Niet "lekker" te programmeren.

Beetje nutteloze vergelijking. Met alleen C++ kun je ook niet veel meer dan een console applicatie schrijven, en je zult dus verder altijd 3rd party libraries nodig hebben om verder te komen. VC++ is in principe alleen een compiler, als je het met BorlandC++, GNU C++, intel C++ of weet ik veel welke compiler compileert, dan heb je altijd nog die libraries nodig. Symbian C++ is in dat opzicht precies gelijk aan het schrijven van een normale applicatie. Een gedegen programma bestaat altijd nog uit veel C++, en dus niet alleen wat aanroepen naar OS functies

[Verwijderd]

Oke bedankt voor jullie reacties, ik ga er eens mee aan de slag.

Is het ook mogelijk om met j2me bijvoorbeeld de bluetooth/ infrarood of gprs aan te spreken?

[.oisyn]

Daar ben je snel genoeg achter als je de documentatie over J2ME doorleest (kort maar krachtig: nee, met midp kun je heel erg weinig)

[Verwijderd]

.oisyn schreef op 09 mei 2004 @ 23:26:

Beetje nutteloze vergelijking. Met alleen C++ kun je ook niet veel meer dan een console applicatie schrijven, en je zult dus verder altijd 3rd party libraries nodig hebben om verder te komen.

Een tikkeltje offtopic mischien, maar dat is dan ook een nadeel van C++. Aan de ene kant is de standaard library erg sterk, aan de andere kant is ie ook hopeloos incompleet. Zelfs console apps met een menu's enz kun je er niet mee maken, want calls for cursor positioning en screen clearing is ook al platform specificiek.

Bij Java daarentegen kun je bijna alles doen met gewoon de standaard library. XML, graphics, networking, het zit er allemaal in. Er zijn wel alternatiefe libs, zoals het zeer goede SWT.

Terug naar dit embedded verhaal. De J2ME varianten zijn gebasseerd op de standaard java library. Sommige classen missen of zijn minder uitgebreid, terwijl er aan de andere kant een paar packages bij zijn gekomen speciaal voor embedded/mobiel gebruik. De taal zelf is ook iets beperkt en kent geen floating point getallen. In zijn geheel kun je dus de J2ME kennis altijd mee nemen als je 'gewoon' Java wilt programmeren.

Bij C++ is er zoals gezegd altijd, voor bijna elk platform een aparte toolkit, en die is dan ook altijd nodig. Er is geen enkele defacto library. Symbian is dus ook weer zo'n library die waarschijnlijk ook wel weer een eigen set van dingen als strings en collections zal bevatten, alsmede de dingen die echt nodig zijn zoals grafische dingen, geluid, I/O etc.

[.oisyn]

Verwijderd schreef op 10 mei 2004 @ 23:44:

Een tikkeltje offtopic mischien, maar dat is dan ook een nadeel van C++. Aan de ene kant is de standaard library erg sterk, aan de andere kant is ie ook hopeloos incompleet. Zelfs console apps met een menu's enz kun je er niet mee maken, want calls for cursor positioning en screen clearing is ook al platform specificiek.

Gelukkig is dat ook helemaal niet de essentie van C en C++. De essentie is een efficiente en portable programmeertaal dat werkt op een enorm groot scala aan platformen. Dat is voor Java en .Net niet het geval.

Bij Java daarentegen kun je bijna alles doen met gewoon de standaard library. XML, graphics, networking, het zit er allemaal in. Er zijn wel alternatiefe libs, zoals het zeer goede SWT.

Daar komt dan wel weer bij dat Java best wel bagger performt op desktop PC's (misschien ben ik bevooroordeeld, ik werk voornamelijk met graphics ). Plus dat Java niet open is; om java te implementeren heb je toestemming nodig van Sun

Terug naar dit embedded verhaal. De J2ME varianten zijn gebasseerd op de standaard java library. Sommige classen missen of zijn minder uitgebreid, terwijl er aan de andere kant een paar packages bij zijn gekomen speciaal voor embedded/mobiel gebruik. De taal zelf is ook iets beperkt en kent geen floating point getallen. In zijn geheel kun je dus de J2ME kennis altijd mee nemen als je 'gewoon' Java wilt programmeren.

J2ME en J2SE lijken voor geen meter op elkaar, imho. MIDP komt slechts met een zeer geringe klasseaanbod, iets waar je op zich weinig mee kan. Vergelijk J2ME met C++, behalve dan dat je met C++ meer kan dan met J2ME

Bij C++ is er zoals gezegd altijd, voor bijna elk platform een aparte toolkit, en die is dan ook altijd nodig. Er is geen enkele defacto library.

Er zijn wel libraries die trachten portable te zijn tussen de grotere platformen (windows, linux, unix). Zelf ben ik er niet zo'n voorstander van, ik ben windows developer, en portabiliteit heeft voor mij totaal geen enkele meerwaarde

Symbian is dus ook weer zo'n library die waarschijnlijk ook wel weer een eigen set van dingen als strings en collections zal bevatten, alsmede de dingen die echt nodig zijn zoals grafische dingen, geluid, I/O etc.

Deze library zal echter wel vele en vele malen uitgebreider zijn dan het aanbod dat je van MIDP krijgt

[Cavalera125]

Verwijderd schreef op 10 mei 2004 @ 16:55:
Is het ook mogelijk om met j2me bijvoorbeeld de bluetooth/ infrarood of gprs aan te spreken?

Dit is dus wel mogelijk, maar dat moet je apparaat wel ondersteunen. Op de Nokia 6600 zit een bluetooth API voor j2me, dus die kun je gewoon aanspreken.

[Verwijderd]

.oisyn schreef op 11 mei 2004 @ 00:26:
[...]


Gelukkig is dat ook helemaal niet de essentie van C en C++. De essentie is een efficiente en portable programmeertaal dat werkt op een enorm groot scala aan platformen. Dat is voor Java en .Net niet het geval.

'een efficiente en portable programmeertaal dat werkt op een enorm groot scala aan platformen', dat zijn wel bijna de woorden die Sun zelf gebruikt om Java aan te duiden.

Daar komt dan wel weer bij dat Java best wel bagger performt op desktop PC's (misschien ben ik bevooroordeeld, ik werk voornamelijk met graphics ). Plus dat Java niet open is; om java te implementeren heb je toestemming nodig van Sun

De performance van Eclipse op de meeste platformen is toch niet zo heel slecht. Ja, op Mac OS X is het zo langzaam dat je denkt dat je met een emulator werkt, maar dat is een bekend probleem en wordt binnenkort 'ge-fixed'. SWT werkt dan ook veel met native widgets, net zoals AWT. AWT is echter nooit echt upgedate en zal (zoals het er nu naar uitziet) altijd op het niveau blijven van hoe windowing toolkits omstreeks 1995 waren.

J2ME en J2SE lijken voor geen meter op elkaar, imho. MIDP komt slechts met een zeer geringe klasseaanbod, iets waar je op zich weinig mee kan.

Ik quote van Oreilly, J2ME in a nutshell:

[...] the two different configurations that make up the J2ME platform -- the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC) [...]

The CDC and its profiles are actually large subsets of the J2SE API [...]

Ik was zelf overigens een tijdje geleden begonnen met J2ME programmeren, en las oa het begin van dit boek. Echter omdat in mijn phone (Panasonic X60) het oversturen van .jar files geblokkeerd staat voor lokale poorten (IrDA) hield de pret snel op.

Vergelijk J2ME met C++, behalve dan dat je met C++ meer kan dan met J2ME

Dat denk ik ook wel. Tevens is de API van J2ME mischien expres restrictiever om makkelijker apps te distributeren zonder gevaar voor mallware achtige dingen. Bv, een app die stiekum je phone naar een duur nummer laat bellen 's nachts.

Bovendien is de verscheidenheid aan hardware platformen in de embedded wereld groter dan momenteel op de desktop. Ook al is goed C++ absoluut portable, het lijkt met stug dat alle embedded devices een build environment hebben zodat je een source archive er heen kunt sturen die dan automatisch gecompiled wordt.

Een binary geschreven met C++ zal dus niet op een hele reeks van platformen gaan draaien. Met J2ME is dit min of meer wel zo, maar ook niet 100%. De embedded devices verschillen namelijk enorm in capaciteiten, scherm resolutie, input mogelijkheden enz. In de praktijk bak je dus even zo goed nog verschillende binaries.

Het geval Symbian is overigens een uitzondering. Voor zover ik weet draait Symbian exclusief op Arm cpu's.

Er zijn wel libraries die trachten portable te zijn tussen de grotere platformen (windows, linux, unix).

Bv Qt, dat ook op Windows heel aardig draait. Toch worden er (afaik) amper Windows apps geschreven met deze toolkit. De discussie over een standaard C++ toolkit wordt overigens weer aangewaaid door de komende C++/CLI bindings. Vanwege opensource implementaties van de CLI zelf zou dit in feite een defacto VM platform voor C++ in het leven roepen. (bindings zijn ECMA standaard, en zouden ook ISO gaan worden). Echter, zonder een bijbehorende uitgebreide library is deze 'toepassing' van de bindings nogal nutteloos.

Zelf ben ik er niet zo'n voorstander van, ik ben windows developer, en portabiliteit heeft voor mij totaal geen enkele meerwaarde

Heb zelf een flink aantal jaren op Windows gedevelopped (voornamelijk MFC), maar vind het nu toch wel jammer dat mijn code niet onder bv Mac OS X kan draaien.

[.oisyn]

Verwijderd schreef op 11 mei 2004 @ 12:36:
[...]


'een efficiente en portable programmeertaal dat werkt op een enorm groot scala aan platformen', dat zijn wel bijna de woorden die Sun zelf gebruikt om Java aan te duiden.

Behalve dat java niet efficient is en helemaal niet draait op een groot scala aan platformen

Ik quote van Oreilly, J2ME in a nutshell:

[..]

Ik was zelf overigens een tijdje geleden begonnen met J2ME programmeren, en las oa het begin van dit boek. Echter omdat in mijn phone (Panasonic X60) het oversturen van .jar files geblokkeerd staat voor lokale poorten (IrDA) hield de pret snel op.

Oh ja, sorry, mijn fout. Ik heb voornamelijk ervaring met CLDC, CDC draait over het algemeen niet op telefoons. En CLDC (MIDP) is echt enorm gelimiteerd.

Dat denk ik ook wel. Tevens is de API van J2ME mischien expres restrictiever om makkelijker apps te distributeren zonder gevaar voor mallware achtige dingen. Bv, een app die stiekum je phone naar een duur nummer laat bellen 's nachts.

Nou ja, de restrictie is met name om portability zo hoog mogelijk te houden. De hardware van mobiele devices is heel divers, en dus om een applicatie op alle platformen te kunnen laten draaien kun je dus niet zo'n uitgebreide API in elkaar zetten. Datzelfde verhaal gaat ook op voor C/C++

Bovendien is de verscheidenheid aan hardware platformen in de embedded wereld groter dan momenteel op de desktop. Ook al is goed C++ absoluut portable, het lijkt met stug dat alle embedded devices een build environment hebben zodat je een source archive er heen kunt sturen die dan automatisch gecompiled wordt.

Ik snap niet precies wat je bedoelt? Voor bijna elke processor die een bepaalde assembly instructieset uit kan voeren bestaat een C compiler. Van programmable integrated circuits met slechts 512 bytes aan geheugen tot de 64 bits Itanium.

Een binary geschreven met C++ zal dus niet op een hele reeks van platformen gaan draaien.

Dat is ook niet de bedoeling van C++. Neem dat PIC voorbeeld wat ik net gaf, daar is onmogelijk een java app op te draaien, omdat die dan een hele virtual machine nodig heeft. Goed, je moet van tevoren compileren, dat is op zich helemaal niet zo'n probleem. Dat maakt het idd minder geschikt voor bijvoorbeeld een game op een telefoon dat door iedereen gedownload kan worden, maar zoals je al zei, de meeste games zijn specifiek voor een bepaalde telefoon geimplementeerd door de verschillen in capaciteiten, dus aan de andere kant is het niet eens zo'n heel groot probleem. Verder biedt de Java VM natuurlijk wat meer bescherming dan native code zodat je geen vervelende dingen uit kunt halen, aan de andere kant performt native code wel veel en veel sneller, zeker op die devices. Het is dus een bepaalde afweging die je maakt

Heb zelf een flink aantal jaren op Windows gedevelopped (voornamelijk MFC), maar vind het nu toch wel jammer dat mijn code niet onder bv Mac OS X kan draaien.

MFC
Ik ben zelf voornamelijk geinteresseerd in gamedevelopment, dus dan werk je over het algemeen niet eens met GUIs

[ Voor 7% gewijzigd door .oisyn op 11-05-2004 14:23 ]

[Verwijderd]

Ik heb nu gekozen om het toch met c++ te gaan proberen, omdat ik persoonlijk niet echt weg ben van java, op me comp zie je vaak dat de java applicaties langzaam zijn en op me telefoon lopen ze regelmatig vast. Maar nu loop ik al gelijk tegen een probleem aan:

Ik heb de series 60 dsp geinstalleerd en de application wizard in vc ++ gezet. Maar als ik nu een nieuw project wil gaan starten dan werkt bijna alles perfect alleen hij maakt standaard ook een workspace aan die die totaal verkeerd plaatst, en daardoor gaat die de fout in:

D:\Symbian\7.0s\Series60_v20\epoc32\build\hello\group\hello\wins\hello.dsw
The specified project could not be inserted into the current workspaces

Terwijl die hier waarscheinlijk zou moeten komen:
D:\hello\group\hello\wins\hello.dsw of iig zoiets dergelijks


Eigenlijke een heele stomme fout maar wat doe je er aan?
Weet iemand een oplossing voor dit probleempje?

[Verwijderd]

.oisyn schreef op 11 mei 2004 @ 14:23:
Behalve dat java niet efficient is en helemaal niet draait op een groot scala aan platformen

Ach, zo heel inefficient is java nu ook weer niet. Zie bv de Orion webserver (www.orionserver.com). Die is 100% pure java en toch best wel lekker snel. Voorderest draaien er veel sites met J2EE, wat toch ook absoluut geen bagger performance geeft. Een groote denk fout die je mischien vaak maakt bij Java is dat je niet aan memory management hoeft te doen. Dat is maar gedeeltelijk waar. Een blok geheugen waar een vergeten pointer (reference) in Java nog naar wijst is net zo goed een memory leak als in C/C++. Als je daar niet op let wordt het inderdaad kwa memory ook snel inefficient.

Ik heb zelf bv een vector teken programaatje in Java geschreven, met een eigen render engine en AA. In het begin dacht ik dat het echt wel heel erg langzaam zou worden, maar dat viel uiteindelijk best mee. Overigens draaide dit wel op elk platform net iets anders. Bv omdat het ene platform wel events blijft sturen als je met je muis buiten de applicatie window komt en het andere niet.

Ik vind zelf het scala aan platformen wel redelijk groot, hoewel het nog niet op zo veel platformen draaid als waar C code op kan draaien. Voor C++ hoop ik vooral dat de standaard ABI eens doorzet (zoals nu wel gespecificeerd voor de Itanium CPU), om de portabiliteit van object files te vergroten.

Ik snap niet precies wat je bedoelt? Voor bijna elke processor die een bepaalde assembly instructieset uit kan voeren bestaat een C compiler. Van programmable integrated circuits met slechts 512 bytes aan geheugen tot de 64 bits Itanium.

Wat ik precies bedoel is dat pure C code net zo portable kan zijn als Java. Er zijn een aantal valkuilen die je moet vermijden, maar die zijn zo bekend dat ik die niet zal herhalen. Dit betekent dus dat als er een standaard 'user' C compiler op een platform zou zijn, noem het de C-just-in-time-compiler, die .c files zou accepteren, on-the-fly zou compileren en main() zou oproepen, dat je dan in principe het zelfde systeem hebt als met bytecode (.class) files.
Die c compiler ansich is er wel, maar een standaard package formaat en environment voor dit niet. Technisch gezien zijn de verschillen niet eens zo groot.

De enorme verscheidenheid aan platformen (= in deze context grofweg CPU + API) maakt dit voor C/C++ niet haalbaar (en daarbij komt nog dat je dan de source moet weggeven, wat natuurlijk ook niet iedereen wil).

MFC

Tsja, op dat moment waren er niet zoveel alternatieven. Ik heb wel begrepen dat de .NET libraries een stuk doordachter in elkaar zitten. Met de .NET api ben ik echter nooit bezig geweest. Kwam net voordat ik op een ander groot project ben overgestapt wat dus voornamelijk met J2EE en Eclipse werkt

Ik ben zelf voornamelijk geinteresseerd in gamedevelopment, dus dan werk je over het algemeen niet eens met GUIs

Nja, met andere soorten GUI's, tenzij je natuurlijk alleen op de engine en AI focussed.

[ Voor 9% gewijzigd door Verwijderd op 11-05-2004 16:29 ]

[.oisyn]

Verwijderd schreef op 11 mei 2004 @ 16:25:

Een groote denk fout die je mischien vaak maakt bij Java is dat je niet aan memory management hoeft te doen.

Had idd gekunt, maar is niet zo . Ik doelde trouwens met name op die embedded platformen. Op platformen als de PC zit er meestal wel een goede JIT compiler achter, op de embedded platformen heb je (als er al ruimte is voor een VM) simpelweg niet de resources om een hele uitgebreide en optimaliserende JIT compiler te gebruiken.

Overigens heeft een memleak niet snel invloed op snelheid, dat is pas als het een enorme leak is waardoor je honderden MB's aan het verliezen bent, maar dat komt maar sporadisch voor

Ik heb zelf bv een vector teken programaatje in Java geschreven, met een eigen render engine en AA. In het begin dacht ik dat het echt wel heel erg langzaam zou worden, maar dat viel uiteindelijk best mee. Overigens draaide dit wel op elk platform net iets anders. Bv omdat het ene platform wel events blijft sturen als je met je muis buiten de applicatie window komt en het andere niet.

http://www.oisyn.nl/homeboxx/
Array en member-variabele accesses zijn vrij traag, is mijn ervaring. Zo haalde ik bijvoorbeeld al een 20% winst door alle vars van een ander object lokaal te cachen door ze gewoon in lokale functie-variabelen te stoppen (let wel, dit was in de inner rendering loop). Dit is een probleem dat je bij native talen over het algemeen niet hebt.

Wat ik precies bedoel is dat pure C code net zo portable kan zijn als Java.

Natuurlijk, maar dat zou geen enkel voordeel geven tov java. En bovendien zijn zowel java als .net er al, dus waarom zou je dat willen doen? Het is vooral het native aspect van C/C++ wat het zo populair maakt op die platformen, als je per se een standaard bytecode compilatie wil hebben dan kun je beter kijken naar een ander developplatform zoals Java en .Net.

Leuk feitje overigens, Quake3 plugins worden gecompileerd met de LCC-win compiler die er portable byte-code van maakt

Tsja, op dat moment waren er niet zoveel alternatieven.

native win32, ATL, WTL?
Ik gebruik zelf overigens een zelf-geschreven dunne wrapper om de win32 api, geinspireerd door ATL.

Nja, met andere soorten GUI's, tenzij je natuurlijk alleen op de engine en AI focussed.

Nou ja natuurlijk wel met GUI's, maar ik bedoel niet het gebruik van een OS-implementatie ervan. Als je zelf een GUI systeem maakt die geheel op de onderliggende 3d engine draait, dan is dat in principe ook portable (je bent natuurlijk wel afhankelijk van de portabiliteit van de interface met de 3d hardware zelf)

[Verwijderd]

.oisyn schreef op 11 mei 2004 @ 17:03:
[...]

Overigens heeft een memleak niet snel invloed op snelheid, dat is pas als het een enorme leak is waardoor je honderden MB's aan het verliezen bent, maar dat komt maar sporadisch voor

Das waar. In een wat grotere context heb je ook nog resource management, wat ook door sommige java programmeurs onterecht in het memory management wordt mee genomen. Bv, sluiten van DB connectie in dispose() method van een object. Dit geeft dezelfde soort problemen, plus dat je natuurlijk nooit weet wanneer de GC gaat draaien in java.

http://www.oisyn.nl/homeboxx/

Kewl! Even meegespeeld. Kunnen de deuren nog open?
Anyway, ik weet nog ik lange tijd terug (1997) ook van die java applets zag uit de demo-scene. Die deden dan op een 486 een kwartier om op te starten en lieten vervolgens de meest ongelooflijke graphics zien

Array en member-variabele accesses zijn vrij traag, is mijn ervaring. Zo haalde ik bijvoorbeeld al een 20% winst door alle vars van een ander object lokaal te cachen door ze gewoon in lokale functie-variabelen te stoppen (let wel, dit was in de inner rendering loop). Dit is een probleem dat je bij native talen over het algemeen niet hebt.

Interesant. Wat ook een snel over het hoofd gezien nadeel van Java is, is dat een object geen 'embedded objects' kan hebben. Sommige doen graag voorkomen alsof Java geen pointers kent, maar de realiteit is dat Java alleen maar pointers kent, behalve dan voor primitive types.

Het gevolg is dat je bij een willekeurige class met veel class data members volgens mij een nogal grote 'scattering' van objecten krijgt. Voor members die alleen private gebruikt worden door een class, lijkt me dat het C++ model toch efficienter is.

Natuurlijk, maar dat zou geen enkel voordeel geven tov java. En bovendien zijn zowel java als .net er al, dus waarom zou je dat willen doen? Het is vooral het native aspect van C/C++ wat het zo populair maakt op die platformen, als je per se een standaard bytecode compilatie wil hebben dan kun je beter kijken naar een ander developplatform zoals Java en .Net.

Ik bedoel niet dat je C eerst naar een alternatieve bytecode actige taal compiled, maar dat je gewoon een C source-file shipped. Deze C file wordt dan vlak voor executie gecompiled aan de kant van de client.
Dit heeft het voordeel dat je als developper niet voor elke mogelijke CPU een binary hoeft te compilen, en dat de client toch 100% native code draait.

native win32, ATL, WTL?

Win32 en MFC gebruik je dikwijls door elkaar. In veel gevallen is MFC maar een -erug- dunne wrapper. Omdat de Win32 API vaker een update kreeg (krijgt) als MFC ontkwam ik er niet aan om telkens Win32 calls te gebruiken omdat een bepaald MFC class weer net niet die functie had die ik nodig had. ATL is overigens voor een groot gedeelte samen gegaan met MFC, en dat gebruik je ook redelijk door elkaar heen. Bv, de reguliere expressies uit ATL in een MFC project.

Ik gebruik zelf overigens een zelf-geschreven dunne wrapper om de win32 api, geinspireerd door ATL.

Gaaf. Ken overigens ook zat mensen die hun 'eigen' MFC implementatie gebruiken. Ik dacht dat dat nog best wel vaak gebeurde ook, met als gevolg dat het shared library concept (dll) niet altijd super werkt voor MFC als elke app zijn eigen versie gebruikt.

Nou ja natuurlijk wel met GUI's, maar ik bedoel niet het gebruik van een OS-implementatie ervan. Als je zelf een GUI systeem maakt die geheel op de onderliggende 3d engine draait, dan is dat in principe ook portable (je bent natuurlijk wel afhankelijk van de portabiliteit van de interface met de 3d hardware zelf)

Was er niet een (serieuze) widget set op OpenGL gebasseerd?

[.oisyn]

We gaan wel heel erg offtopic

Verwijderd schreef op 11 mei 2004 @ 18:57:
Das waar. In een wat grotere context heb je ook nog resource management, wat ook door sommige java programmeurs onterecht in het memory management wordt mee genomen. Bv, sluiten van DB connectie in dispose() method van een object. Dit geeft dezelfde soort problemen, plus dat je natuurlijk nooit weet wanneer de GC gaat draaien in java.

Dat is idd iets dat Java erg mist, deterministic finalization. Het komt wel in .Net 2.0. Feitelijk komt het erop neer dat je C++-style destructors hebt die aangeroepen worden zodra een object, dat op de stack staat, uit scope gaat. In die destructors kun je dan je opruimcode kwijt, en omdat de stack unwinded wordt bij een exception is je opruimcode ook nog eens exception-safe (momenteel moet je dat in een finally-block stoppen)

Kewl! Even meegespeeld. Kunnen de deuren nog open?

nee, de wereld is vrij statisch

Ik bedoel niet dat je C eerst naar een alternatieve bytecode actige taal compiled, maar dat je gewoon een C source-file shipped. Deze C file wordt dan vlak voor executie gecompiled aan de kant van de client.
Dit heeft het voordeel dat je als developper niet voor elke mogelijke CPU een binary hoeft te compilen, en dat de client toch 100% native code draait.

Ah op die fiets. Dat zou op zich nog wel kunnen met een soort bytecode dat vrijwel een 1:1 vertaling is van de C-code. Ik denk dat dat makkelijker te compileren is dan een hele source file, omdat je geen headers meer nodig hebt en geen syntactische en semantische controle meer hoeft te doen.

Win32 en MFC gebruik je dikwijls door elkaar. In veel gevallen is MFC maar een -erug- dunne wrapper. Omdat de Win32 API vaker een update kreeg (krijgt) als MFC ontkwam ik er niet aan om telkens Win32 calls te gebruiken omdat een bepaald MFC class weer net niet die functie had die ik nodig had. ATL is overigens voor een groot gedeelte samen gegaan met MFC, en dat gebruik je ook redelijk door elkaar heen. Bv, de reguliere expressies uit ATL in een MFC project.

Idd, ik denk ook niet dat je alle functies moet gaan wrappen. Zowel het windowing gedeelte van ATL en mijn eigen library spitsen zich voornamelijk op het OO maken van windows. In plaats van een windowproc te implementeren met een gigantische switch voor alle window messages, laat je het onderliggende systeem dat doen, en geef je aan welke functies aangeroepen moeten worden bij welke messages. En het geeft een mogelijkheid om al aangemaakte windows waarvan je een HWND hebt, te koppelen aan je eigen implementatie (window subclassing dus)

De reden waarom ik MFC niets vind is omdat het zo bloated is. Het heeft een eigen kernel waarin je applicatie draait, een programma is niet simpelweg een sourcefile aanmaken en daar een WinMain () in zetten. ATL is wat dat betreft veel vriendelijker, maar je zit nog altijd met allerlei macro's om message maps te definieren. Ikzelf gebruik daarvoor gewoon een std::map<UINT, LRESULT (T::*) (...)>, waarbij de T staat voor het type van je klasse. Een member-function pointer dus, gekoppeld aan een UINT voor de message.

Een window instantieren is dan zo simpel als:

C++:

#include <oisyn/winlib/window.h>
using namespace oisyn::winlib;

class MainWindow : public WindowImpl<MainWindow>
{
public:
    MainWindow ()
    {
        msgMap.messages[WM_LBUTTONDOWN] = onClick;
        msgMap.messages[WM_CLOSE] = onClose;

        create (WS_EX_OVERLAPPEDWINDOW, 0, "Blaat", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
            100, 100, 600, 500);
    }

    LRESULT onClose (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam, bool & handled)
    {
        handled = true;
        PostQuitMessage (0);
        return 0;
    }


    LRESULT onClick (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam, bool & handled)
    {
        handled = true;
        MessageBox (*this, "Click!", "...", MB_OK);
        return 0;
    }
};


int WINAPI WinMain (HINSTANCE hInst, HINSTANCE, LPSTR, int)
{
    MainWindow wnd;

    MSG msg;
    while (GetMessage (&msg, 0, 0, 0))
    {
        TranslateMessage (&msg);
        DispatchMessage (&msg);
    }

    return (int)msg.wParam;
}

Was er niet een (serieuze) widget set op OpenGL gebasseerd?

Geen idee