Archief - [PROG] Welke programmeer taal?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Darth-Falcon

Legacy Member
killgore zei:
Volledig akkoord :). Als je kan programmeren komt het er gewoon op aan de juiste taal voor de juiste job te gebruiken.


Als je wat prutst kan je zelfs in c# poorten gaan aanspreken (heb het al gedaan, dus niemand moet da hier komen ontkennen ^^). In c++ gaat het zelfs zonder prutsen. En ook op low-lev niveau (interrupts en zo) kan je nog gaan programmeren in C++ gezien de volledige c standaard lib ook beschikbaar is in c++ :). Enkel wordt C++ op low-lev niveau (kernels e.d.) vaak vermeden, persoonlijk snap ik nog steeds niet volledig waarom.

Het aanspreken van poorten op zich is 2x niets hoor, dat is in vele gevallen gewoon de juiste I/O stroom/file/... aanleggen :).

weet ik wel. moeilijkste was niet om de poorten aan te spreken, maar meer alles errond, data die ingelezen worden enz. rottig in C.

The Crazy Frog

Legacy Member
killgore zei:
Als je wat prutst kan je zelfs in c# poorten gaan aanspreken (heb het al gedaan, dus niemand moet da hier komen ontkennen ^^). In c++ gaat het zelfs zonder prutsen. En ook op low-lev niveau (interrupts en zo) kan je nog gaan programmeren in C++ gezien de volledige c standaard lib ook beschikbaar is in c++ :). Enkel wordt C++ op low-lev niveau (kernels e.d.) vaak vermeden, persoonlijk snap ik nog steeds niet volledig waarom.

Het aanspreken van poorten op zich is 2x niets hoor, dat is in vele gevallen gewoon de juiste I/O stroom/file/... aanleggen :).

Op NT systemen werken die functies niet meer, omdat ze alleen maar door kernel ring programmas mogen worden uitgevoerd. Als ge ze probeert te draaien op XP krijg je een illegal expression error. Der bestaat een workaround dll die een kleine driver installeert om zo je port calls om te leiden.

Darth-Falcon

Legacy Member
jep was de reden waarom wij in win 98 moesten werken :sop:

met die dll veranderd er weinig, alleen naam van commando :) enige commando's die wij mochten gebruiken waren outportb en inportb

het ging trouwens bij dat vak niet alleen om het programmeren ze. ik heb ook de volledige werking, structuur enz van al die poorten uitvoerig gezien. (15/20 me kerstmis :crazy: )

killgore

Legacy Member
The Crazy Frog zei:
Bij games in C++ kan je je messageloop zodanig veranderen dat je een infinite loop hebt, en dus 100% CPU, wat ervoor zorgt dat je gamecode meer aangeroepen wordt, en dus betere framerates krijgt. Bij C# wordt de messageloop verborgen, dus kan je die ook niet tweaken om meer frames te krijgen.
Yes you can, nog nooit van directx en consoorten gehoord, je moet niet noodzakelijk de std msg-handlers gebruiken he. Ik weet nu niet of c# dit ondersteund, maar als jij je input-events als interrupts zou implementeren kan je bv. zelfs dan nog met de pure c#-api werken, maar daar weet ik niet genoeg van tbh (doe niet aan gamedev in c#). Wrsch kan je zelfs in c# net als in C++ uw keys gaan pollen ipv op de events te rekenen hoor.

Vista is ook backwards compatible met Xp, nochtans zijn er veel programmeurs aan het :doh:'en om hun programma's terug aan de praat te krijgen in vista (Visual studio bv, wat door MS zelf geschreven werd). Over COMs, de meeste libraries worden gereleased als DLLs, dus daar kan je niet veel aan veranderen. Het zou stom zijn om heel die library zelf opnieuw te schrijven om er een COM van te maken.
een COM was maar EEN vb waarmee je backwards compability kan oplossen.
En iemand die er niet voor zorgt dat zijn library versie 1.5 niet compatibel is met programmas geschreven voor 1.3 is slecht bezig hoor, ongeacht of het een gewone dll is of com-objecten of whatever.

Ik heb 2 programma's staan die .net gebruiken (VS en WLM), en 1 dat java gebruikt (freemind).
Het gaat over grote applicaties in het algemeen, de hoeveelheid, je kan toch niet verwachten dat alle applicaties van dag 1 op 2 ineens in c# gemaakt zijn?

De forms in .net zijn toch een soort .net wrapper (alsk het zo mag uitdrukken) rond winapi? Of hebben ze het in vista omgedraait: heel de windowing in .net gemaakt en daarna een winapi wrapper gemaakt?
Geen van de 2. De winapi wordt nog ondersteund, maar zoals ik zei puur omwille van backwardscompability redenen, die staat vrij los van .net afaik (mssch hebben ze zaken toegevoegd zodat .net makkelijker kan communiceren met deze apps, maar dat is het ook).
En .net forms zijn geen winapi wrappers, mfc was dat (en wat voor een gedrocht was het). De forms zijn een nieuw systeem.

The Crazy Frog

Legacy Member
killgore zei:
Yes you can, nog nooit van directx en consoorten gehoord, je moet niet noodzakelijk de std msg-handlers gebruiken he. Ik weet nu niet of c# dit ondersteund, maar als jij je input-events als interrupts zou implementeren kan je bv. zelfs dan nog met de pure c#-api werken, maar daar weet ik niet genoeg van tbh (doe niet aan gamedev in c#). Wrsch kan je zelfs in c# net als in C++ uw keys gaan pollen ipv op de events te rekenen hoor.
Directx heeft nog altijd een messageloop. Kijk maar eens naar het volgende voorbeeldje: http://www.directxtutorial.com/Tutorial9/B-Direct3DBasics/dx9B1.aspx

killgore zei:
een COM was maar EEN vb waarmee je backwards compability kan oplossen.
En iemand die er niet voor zorgt dat zijn library versie 1.5 niet compatibel is met programmas geschreven voor 1.3 is slecht bezig hoor, ongeacht of het een gewone dll is of com-objecten of whatever.
Akkoord, maar in de practijk gebeurt dat wel vaak, meestal zijn dat dan hele kleine veranderingen, of een functie die eruit gegooit wordt.

killgore zei:
Het gaat over grote applicaties in het algemeen, de hoeveelheid, je kan toch niet verwachten dat alle applicaties van dag 1 op 2 ineens in c# gemaakt zijn?
Voorlopig zijn zulke frameworks nog overkill, maar het kan zijn dat dit in de toekomst verandert. Is het trouwens niet mogelijk om gewoon de .net DLLs die je gebruikt in je exe dir te zetten?

killgore zei:
Geen van de 2. De winapi wordt nog ondersteund, maar zoals ik zei puur omwille van backwardscompability redenen, die staat vrij los van .net afaik (mssch hebben ze zaken toegevoegd zodat .net makkelijker kan communiceren met deze apps, maar dat is het ook).
En .net forms zijn geen winapi wrappers, mfc was dat (en wat voor een gedrocht was het). De forms zijn een nieuw systeem.
Ja, maar als .net niet voor de windowing zorgt, dan heeft .net nog altijd winapi nodig om voor vensters te zorgen.

killgore

Legacy Member
The Crazy Frog zei:
Directx heeft nog altijd een messageloop. Kijk maar eens naar het volgende voorbeeldje: http://www.directxtutorial.com/Tutorial9/B-Direct3DBasics/dx9B1.aspx
Dat was like mijn punt: ge kunt die messageloop ook rechtstreeks in c# gaan steken ipv die achter de schermen te gebruiken. Bedankt om me gelijk te geven ^^.

Akkoord, maar in de practijk gebeurt dat wel vaak, meestal zijn dat dan hele kleine veranderingen, of een functie die eruit gegooit wordt.
Dat is spijtig genoeg fout, wat beter is is in je docs de functie als deprecated op te nemen en het gebruik dmv de juiste preprocessor statements een warning te laten genereren!

Voorlopig zijn zulke frameworks nog overkill, maar het kan zijn dat dit in de toekomst verandert. Is het trouwens niet mogelijk om gewoon de .net DLLs die je gebruikt in je exe dir te zetten?
Van die dlls weet ik niet. Maar zulke frameworks zijn zeker geen overkill. Men moet ze gewoon meer gaan gebruiken, het is door die conservatieve meningen als die van jezelf dat ze ongebruikt blijven liggen.

Ja, maar als .net niet voor de windowing zorgt, dan heeft .net nog altijd winapi nodig om voor vensters te zorgen.
Rofl, nee. Achter winapi zitten ook systemen die voor uw UI zorgen hoor, en achter die UI nog andere systemen en achter die systemen nog andere.
Het is zeker niet waar dat achter .net forms rechtstreeks de winapi zit.

Schietschijf

Legacy Member
The Crazy Frog zei:
Vista is ook backwards compatible met Xp, nochtans zijn er veel programmeurs aan het :doh:'en om hun programma's terug aan de praat te krijgen in vista (Visual studio bv, wat door MS zelf geschreven werd).

Ik heb woensdag visual studio 2005 geinstalleerd op vista en het werkte toch ze, kweet niet welke versie van vs of vista gij gebruikt, maar problemen van een grootte dat vs niet meer te runnen zijn helaas voor u onbestaande.

Je zou ervan verschieten hoeveel programma's er met C# worden gemaakt, en niet enkel eenvoudige programma's.

Als ik moest kiezen tussen C# en C dan toch liever C#.

Je zou anders eens kunnen zien naar Visual C++.NET
[edit]
Met visual C++.net kan je kiezen of je managed of unmanaged gaat en of je je gui gaan maken met mfc of .net forms
Je mag zeggen wat je wil maar c++ gaan gebruiken voor windowsapplicaties is tijdverspilling die niet echt opweegt tegen die 2 microseconden tijdswinst die het oplevert tov C#...
[/edit]

The Crazy Frog

Legacy Member
killgore zei:
Dat was like mijn punt: ge kunt die messageloop ook rechtstreeks in c# gaan steken ipv die achter de schermen te gebruiken. Bedankt om me gelijk te geven ^^.
in C# kan je niets veranderen aan de messageloop van je programma, da's nu net mijn punt...

killgore zei:
Dat is spijtig genoeg fout, wat beter is is in je docs de functie als deprecated op te nemen en het gebruik dmv de juiste preprocessor statements een warning te laten genereren!
Kzal maar een voorbeeldje geven zeker:
In de lua versies voor 5.0 kon je luaopen_math(L); rechtstreeks doen uit C++, in 5.0 en verder moet luaopen_math aangeroepen worden vanuit de VM.

killgore zei:
Van die dlls weet ik niet. Maar zulke frameworks zijn zeker geen overkill. Men moet ze gewoon meer gaan gebruiken, het is door die conservatieve meningen als die van jezelf dat ze ongebruikt blijven liggen.
Als ze gebundeld zitten met OSen is dat geen probleem, maar appart downloaden vormt wel een probleem bij sommige gebruikers, not to mention de goeie installer van .net

killgore zei:
Rofl, nee. Achter winapi zitten ook systemen die voor uw UI zorgen hoor, en achter die UI nog andere systemen en achter die systemen nog andere.
Het is zeker niet waar dat achter .net forms rechtstreeks de winapi zit.
Winapi is een groep van verschillende api's voor de verschillende subsystemen in windows (gdi, user, commctrl, ...), de functies van winapi zijn gewoon functies die in windows zitten, en die ook door het systeem gebruikt worden.

Schietschijf zei:
Ik heb woensdag visual studio 2005 geinstalleerd op vista en het werkte toch ze, kweet niet welke versie van vs of vista gij gebruikt, maar problemen van een grootte dat vs niet meer te runnen zijn helaas voor u onbestaande.

Je zou ervan verschieten hoeveel programma's er met C# worden gemaakt, en niet enkel eenvoudige programma's.

Als ik moest kiezen tussen C# en C dan toch liever C#.

Je zou anders eens kunnen zien naar Visual C++.NET
[edit]
Met visual C++.net kan je kiezen of je managed of unmanaged gaat en of je je gui gaan maken met mfc of .net forms
Je mag zeggen wat je wil maar c++ gaan gebruiken voor windowsapplicaties is tijdverspilling die niet echt opweegt tegen die 2 microseconden tijdswinst die het oplevert tov C#...
[/edit]
Het draait wel, maar er zijn een hele hoop bugs: http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx

Darth-Falcon

Legacy Member
toch grappig hoe threads zoals deze altijd uitdraaien op een fanboy thread.

@ threadstarter, begin gewoon met met c++

Bubbling Zombie

Legacy Member
Darth-Falcon zei:
toch grappig hoe threads met crazy frog in altijd uitdraaien in flamewars
@ threadstarter, begin gewoon met met c++

fixed that

en threadstarter, ga me uw tijd mee en pakt iets da nen deftige free IDE heeft op windows. Want ge kunt er van zeggen wat ge wilt, sharpdevelop is winrar.

Darth-Falcon

Legacy Member
Bubbling Zombie zei:
fixed that

en threadstarter, ga me uw tijd mee en pakt iets da nen deftige free IDE heeft op windows. Want ge kunt er van zeggen wat ge wilt, sharpdevelop is winrar.

ff voor de duidelijkheid: zijn woorden, niet de mijne

The Crazy Frog

Legacy Member
Bubbling Zombie zei:
fixed that

en threadstarter, ga me uw tijd mee en pakt iets da nen deftige free IDE heeft op windows. Want ge kunt er van zeggen wat ge wilt, sharpdevelop is winrar.

Wie is er hier fanboy?

En @falcon: tis (nog) nie echt een flamewar, tis gewoon een discussie :)

Bubbling Zombie

Legacy Member
The Crazy Frog zei:
Wie is er hier fanboy?

En @falcon: tis (nog) nie echt een flamewar, tis gewoon een discussie :)

nja, geef zelf toe dat uw argument van "omg lol, ik krijg da ding nie geinstalleerd op mijn pc en dus is da teh suck dus ik ga wel een oudere dll collectie gebruiken want das minder download" op weinig tot niets slaat.

The Crazy Frog

Legacy Member
Bubbling Zombie zei:
nja, geef zelf toe dat uw argument van "omg lol, ik krijg da ding nie geinstalleerd op mijn pc en dus is da teh suck dus ik ga wel een oudere dll collectie gebruiken want das minder download" op weinig tot niets slaat.

Geef gewoon toe dat die .net installer op nie veel trekt, kan best zijn dat ge .net vree goed vindt, maar die installer kan stukken beter. Trouwens, mijn oudere dll collectie wordt wel vaker geupdate dan uw .net framework.

dJeez

Legacy Member
Om de TS toch wat verder te helpen : ondanks alle zever in dit draadje is toekomstgericht C# de beste keuze van de 3 talen die je aanhaalt (je Java kennis verdiepen als je er enkel de basis van kent is uiteraard ook geen slechte optie).

killgore

Legacy Member
The Crazy Frog zei:
in C# kan je niets veranderen aan de messageloop van je programma, da's nu net mijn punt...

Ik geef hierboven juist 1 vb (directx api gebruiken) om de messageloop te ontwijken, ge kunt trouwens bij mijn weten ze sinds 2.0 wel handmatig gaan opstarten, tis gewoon niet de doorsnee easy c# code. En als je echt wilt kan je natuurlijk nog altijd teruggrijpen naar de goede oude "gewone" windows libs waaruit je bv. peekmessage import.


Kzal maar een voorbeeldje geven zeker:
In de lua versies voor 5.0 kon je luaopen_math(L); rechtstreeks doen uit C++, in 5.0 en verder moet luaopen_math aangeroepen worden vanuit de VM.
Wat doet het voorbeeld er toe, als 2 public releases van een lib niet backwards compatible zijn is er op SE vlak iets mis met die libraries, of dit nu een mega-lib als lua is of de mini-libjes die ik zelf maak :ironic:.


Als ze gebundeld zitten met OSen is dat geen probleem, maar appart downloaden vormt wel een probleem bij sommige gebruikers, not to mention de goeie installer van .net
.net is bedoeld voor de interactieve toekomst, wat ook inhoudt dat het bedoeld is te werken onder een breedband verbinding. Als jij een distribution aan iemand levert voor je c# programma zal deze automatisch de nodige .net componenten voor jouw programma downloaden. De enige overload hierin is dat de gebruiker bij zijn allereerste .net programma mssch 5 mins gaat moeten wachten en die kans zit er dan nog eens enkel in voor win xp (of oudere) gebruikers. Wow, dat is natuurlijk nogal een ramp he, hiervoor gaan gebruikers zeker afhaken van dergelijke programmas!

Ik heb daarstrx gezegd dat de installer van .net beter kan, maar ik vraag me nu wel af wat er bij jou zo erg misliep dat het totaal niet werkte of zo :x?


Winapi is een groep van verschillende api's voor de verschillende subsystemen in windows (gdi, user, commctrl, ...), de functies van winapi zijn gewoon functies die in windows zitten, en die ook door het systeem gebruikt worden.
Hier kom je weer, je gaat me het evidente wijsmaken en doen alsof jij zo een geniaal man bent die alle mooie informatica-definities kan opzeggen, maar een punt zit hier totaal niet in, laat staan dat het enige van mijn argumenten weerlegt.

@djeez: welke zever?

The Crazy Frog

Legacy Member
killgore zei:
Wat doet het voorbeeld er toe, als 2 public releases van een lib niet backwards compatible zijn is er op SE vlak iets mis met die libraries, of dit nu een mega-lib als lua is of de mini-libjes die ik zelf maak :ironic:.
Kan wel waar zijn, maar mijn punt is dat dit wel degelijk voorkomt. Ge moogt al zeggen wa ge wilt, SE fout hier, blabla daar, het komt voor, punt.

killgore zei:
Ik heb daarstrx gezegd dat de installer van .net beter kan, maar ik vraag me nu wel af wat er bij jou zo erg misliep dat het totaal niet werkte of zo :x?
Door VS SP1 te installeren werkte mijn resource viewer niet meer, kheb geprobeerd om VS te repairen (volgens instructies op de KB van MS), en het ging van kwaad naar erger. Uiteindelijk werkte .net ook nie meer, en telkens ik het wou installeren kreeg ik een error op het einde van de install.

killgore zei:
Hier kom je weer, je gaat me het evidente wijsmaken en doen alsof jij zo een geniaal man bent die alle mooie informatica-definities kan opzeggen, maar een punt zit hier totaal niet in, laat staan dat het enige van mijn argumenten weerlegt.
Het punt is dat het zeer onwaarschijnlijk is dat ze alle ingewanden van windows vervangen hebben door managed code om gewoon .net te integreren in de OS. .Net is gebouwd op een api, kan gewoon niet anders. En over da schoolboy gedoe, proggen is een hobby voor mij, en kplan zeker niet om later daar mijnen boterham mee te verdienen.

killgore

Legacy Member
The Crazy Frog zei:
Kan wel waar zijn, maar mijn punt is dat dit wel degelijk voorkomt. Ge moogt al zeggen wa ge wilt, SE fout hier, blabla daar, het komt voor, punt.
Ja het komt voor. Slechte code komt ook voor, ga naar dailywtf kijken, het staat er vol van. Maar dit is geen argument voor gelijk wat. Ik snap eigenlijk zelfs niet wat je hiermee bedoelt. Het punt was dat backwards compability altijd moet ingebouwd worden in libs als je een goede lib wilt. Hiertegen begin jij te discussiëren. Dat het voorkomt is geen argument om te zeggen dat het goed/slecht is he :x.

met alle respect: blijf hier weg, je weet echt nog steeds niet waarover je praat en meer dan de helft van je argument slaan gewoonweg op niets :x.
Het punt is dat het zeer onwaarschijnlijk is dat ze alle ingewanden van windows vervangen hebben door managed code om gewoon .net te integreren in de OS. .Net is gebouwd op een api, kan gewoon niet anders. En over da schoolboy gedoe, proggen is een hobby voor mij, en kplan zeker niet om later daar mijnen boterham mee te verdienen.
Ze hebben juist wel een groot deel van de core vervangen voor geoptimaliseerd toekomstgebruik. .net is nu min of meer een kern van vista & niet een toevoegsel zoals in xp.

Waarom heeft de ontwikkeling zolang geduurd denk je?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan