[C(++)] voor dummies - Deel 1

quote:

Op vrijdag 6 augustus 2010 18:39 schreef progje het volgende:
Echt schijtziek word ik er van, totaal geen computer kennis meer...
Wat maakt het nou uit hoe het geheugen werkt, je propt er toch gewoon een extra bankje bij als het te traag wordt

quote:

Op vrijdag 6 augustus 2010 18:46 schreef thabit het volgende:

[..]

Da's een kwestie van economie: goede hardware is tegenwoordig goedkoper dan een goede programmeur.

quote:

Op vrijdag 6 augustus 2010 18:49 schreef progje het volgende:

[..]

Nou, als de salaris-eis nou ook eens in overeenstemming was met het gewenste niveau..
Maar dat laat helaas ook nog vaak te wensen over.

En allemaal zo heerlijk groot ego, ze vinden zichzelf allemaal de beste en overleggen ho maar

verder ben ik niet gefrustreerd hoor.

Nu werk ik zelf in een omgeving waar ook veel in .Net en C# wordt geprogrammeerd, misschien hoort het ook wel bij dat wereldje ik weet het niet..

quote:

Op vrijdag 6 augustus 2010 18:10 schreef Cruise.Elroy het volgende:
Euh? Nee want met #include wordt de file direct in je parser geramd. Dus dat later weer undo-en is niet te doen.

#include zet de inhoud van de file direct tussen je code, het is niet zoals in Java e.d.
Je kan dus een losse regel code in een file zetten, en deze dan includen midden in een functie bijvoorbeeld

quote:

Op vrijdag 6 augustus 2010 21:16 schreef TeringHenkie het volgende:
Grappig is trouwens wel dat de Assemblies van Microsoft gewoon wrappers om Win32 zijn. Bijvoorbeeld Messagebox.Show roept uiteindelijk gewoon MessageBox aan in user32.dll. Als iets niet kan in C#, is er nog geen developer daar die er een wrapper voor heeft geschreven.

Conclusie: C# voor de GUI, en de snelle/geavanceerde code stop je in een c++ DLL die je dan DllImport

quote:

Op zondag 8 augustus 2010 21:38 schreef Trollface. het volgende:
Handgeschreven ASM daar kan geen compiler tegenop

quote:

Op zondag 8 augustus 2010 21:24 schreef Cruise.Elroy het volgende:

[..]

Uiteindelijk is elk programma in elke taal op het Windows platform uiteindelijk een wrapper voor de Win32 api, er is geen andere logische manier om Windows "te gebruiken". Hoe hoger het niveau, hoe beter (voor de user) maar (mogelijk) trager.
Dat het anders kan laten Linux ports en Java apps zien, maar daar wordt je echt niet blij van, al is het alleen al het gebruikersgemak, al custom dialogs en lelijke L&F.

Verder kan C# zeker wel sneller zijn dan C++, zelfs sneller dan compiled ASM dat komt omdat je stukken (byte)code real-time opnieuw kan compilen naar ASM als de omstandigheden daar toe zijn.

quote:

Op zondag 8 augustus 2010 22:16 schreef TeringHenkie het volgende:

[..]

Dat C# sneller kan zijn dan C++ snap ik wel, maar dan is dat (neem ik aan) alleen maar omdat OF je code brakker is, OF omdat je compiler niet kan optimaliseren. Het probleem met C# is alleen dat je voor de eenvoudigste dingen meteen 3 objecten aan moet gaan maken, wat je waarschijnlijk veel geheugen en cpu-tijd kost.
Hoe zit dat nou met de machinecode die uitgevoerd wordt? Ik heb begrepen dat moderne OSen een HAL om je hardware heen bouwen. Mag ik dan ook aannemen dat machinecode wel direct op je processor draait, en dat er alleen interrupts aangeroepen mogen worden die opgevangen worden door je HAL?

quote:

Op zondag 8 augustus 2010 22:19 schreef Cruise.Elroy het volgende:

[..]

Je code draait gewoon op je CPU, waar anders op Alleen kan je met Protected Mode etc. heel veel dingen afschermen, zoals interrupts, geheugenadressen etc. Een HAL is een low-level variant van een API.

quote:

Op zondag 8 augustus 2010 22:29 schreef Trollface. het volgende:

[..]

Dat ik bij FOK! dev wil niet zeggen dat ik alleen aan webdevving doe

quote:

Op zondag 8 augustus 2010 22:30 schreef Cruise.Elroy het volgende:
Afaik wordt dat idd met interrupts en dergelijke geregeld. Sowieso heb je je eigenlijk geheugen-ruimtes waardoor je niet meer bij iedereen kan rondkijken.
Details o.a. hier:

Dit is de processor-side info: http://en.wikipedia.org/wiki/Protected_mode
En hier heb je de verschillende permissie-"rings": http://en.wikipedia.org/wiki/Ring_(computer_security)

quote:

Op zondag 8 augustus 2010 22:36 schreef TeringHenkie het volgende:

[..]

Dat bedoel ik dus. Wat ik eerst niet snapte, was dat ALLE code op je PC uiteindelijk ook op de CPU stacks zit te pushen en weet ik veel. Hoe zorg je dat dat allemaal niet in de weg zit? Ik neem aan dat als een ander proces CPU-tijd krijgt, jouw registertjes ergens worden opgeslagen, en die andere code z'n waardes weer in de registertjes wordt gestopt

quote:

Op zondag 8 augustus 2010 22:38 schreef Cruise.Elroy het volgende:

[..]

Multi-threading en multi-tasking doet zogenaamde context-switching die alles dus idd keurig weg zet. Interrupts e.d. ook natuurlijk:

http://en.wikipedia.org/wiki/Context_switch

quote:

Op zondag 8 augustus 2010 22:46 schreef TeringHenkie het volgende:

[..]

HA! Dus eigenlijk was DOS wel een systeem wat multitasking aankon. Immers zouden drivers hun werk nooit kunnen doen

quote:

Op zondag 8 augustus 2010 23:00 schreef Cruise.Elroy het volgende:

[..]

Waarom zou je multi-tasking nodig hebben voor drivers? Die hoeven toch niet los van een applicatie iets uit te voeren?
Nee in DOS werkte alle(?) drivers met interrups, TSR systemen en ingeladen stukken uitvoerbare code. Geen multi-tasking dus.

Een muis-driver registereerde een stuk code ergens in een interrupttabel (oid), maar die driver voerde dus zelf geen code uit "los" van de applicatie. Die applicatie riep gewoon driver-code aan waar nodig, en wachtte tot deze klaar was.

Als je code wilde uitvoeren "samen" met een applicatie moest je een timer-interrupt aanzette die gewoon elke zoveel ms triggerde en dan jouw code weer uitvoerde. Zoals een trainer van games bijv. Een programma die in het geheugen ligt te wachten totdat hij wordt uitgevoerd heet een TSR.

http://en.wikipedia.org/wiki/Terminate_and_Stay_Resident

quote:

Op zondag 8 augustus 2010 21:24 schreef Cruise.Elroy het volgende:

[..]

Uiteindelijk is elk programma in elke taal op het Windows platform uiteindelijk een wrapper voor de Win32 api, er is geen andere logische manier om Windows "te gebruiken".

quote:

Op zondag 8 augustus 2010 23:56 schreef TeringHenkie het volgende:

[..]

Volgens mij is dit niet helemaal waar. Als ik in C# een object aanmaak, maakt het framework voor mij een object aan, dat doet de code niet zelf. Ook neem het framework mij GC uit handen. Als ik in C++ een object aanmaak, maakt mijn eigen code voor mij geheugen aan (in een door windows bepaalde geheugenruimte weliswaar). Als voorbeeld: als ik twee ints optel, doet mijn C++ programma dat gewoon in de registers, zonder tussenkomst van een of andere DLL.

quote:

Op zondag 8 augustus 2010 23:56 schreef TeringHenkie het volgende:

[..]

Volgens mij is dit niet helemaal waar. Als ik in C# een object aanmaak, maakt het framework voor mij een object aan, dat doet de code niet zelf. Ook neem het framework mij GC uit handen. Als ik in C++ een object aanmaak, maakt mijn eigen code voor mij geheugen aan (in een door windows bepaalde geheugenruimte weliswaar). Als voorbeeld: als ik twee ints optel, doet mijn C++ programma dat gewoon in de registers, zonder tussenkomst van een of andere DLL.

quote:

Op maandag 9 augustus 2010 00:13 schreef netolk het volgende:

[..]

Dat is ook de rede dat zware-/besturingsprogramma's doorgaans in C++ geschreven zijn
Maar doet C# dat met tussenkomst van DLL's?? Dat zou behoorlijk inefficiënt zijn

quote:

Op zondag 8 augustus 2010 23:08 schreef TeringHenkie het volgende:

[..]

Maar hoe werkte dat dan als je de muis bewoog? Of als je netwerkkaart data ontving? Werd die pas uit de buffer gehaald als je programma polde of de socket data te verwerken had?

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

quote:

Op woensdag 25 augustus 2010 12:23 schreef netolk het volgende:
Hey, ik heb problemen met het maken van een ico...

ik heb op http://www.hackerfactor.c(...)-Ico-Ico-Un-Day.html en op http://en.wikipedia.org/wiki/BMP_file_format gekeken, maar nu werkt de volgende code niet...

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

bij de raw data copy (die while(!Read.eof()) loop) komt ie nooit aan bij end of file en krijg ik dus een oneindig groot ico file... weet iemand miss wat ik niet goed doe

quote:

Op donderdag 26 augustus 2010 11:25 schreef Cruise.Elroy het volgende:
Wat lees je dan uit, zet die zooi op het scherm en kijk waar het mis gaat. Toch niet zo enorm moeilijk?

quote:

Op donderdag 26 augustus 2010 12:44 schreef Cruise.Elroy het volgende:
Je moet ook geen << operator gebruiken bij binary streams. Je wilt gewoon byte-voor-byte die data ophalen en wegschrijven met read en write. Als hij nog maar 1 getal uitleest, welke is dat dan? -1 ofzo?

quote:

Op donderdag 26 augustus 2010 15:08 schreef netolk het volgende:

[..]

nee iets van 236825 ofzo het maakte niet uit of ik binary las en schreef of niet bleef het zelfde getal krijgen...

quote:

Op donderdag 26 augustus 2010 16:18 schreef Cruise.Elroy het volgende:

[..]

Gebruik je nog steeds << ? Want die moet je dus _niet_ gebruiken voor dit soort dingen

edit: ik zie dat je hele grote getallen krijgt, dus je bent niet byte voor byte binair aan het lezen. Dat moet je wel doen aangezien een BMP/ICO file vol zit met binaire troep.
Gooi dat getal er eens in HEX uit, misschien iets van 0xFFFF of 0x8000: een of andere errorwaarde.

quote:

Op vrijdag 27 augustus 2010 23:41 schreef thabit het volgende:
if(argc = 2) moet if(argc == 2) zijn

quote:

Op zaterdag 28 augustus 2010 13:44 schreef Cruise.Elroy het volgende:
netolk, je bent bekend met de string-zero opslag in C++ neem ik aan?
Een string sla je dus op als een reeks char's, en je point dan naar het begin van de string. het einde van de string wordt aangegeven met een nul (als character kan je het schrijven als '\0')

Als je dus twee strings wilt vergelijken moet je dus het volgende doen:
[ code verwijderd ]

deze lus loopt de beide strings af totdat er een verschil wordt gevonden, of totdat ze beide tegelijk aflopen. Oh en deze methode is niet optimaal en zit wss vol fouten, gebruik daarom de ingebouwde strcmp() functie.

Of gebruik de std::string klasse uit de STL lib van C++, maar mss leuk om precies te weten wat je doet.

quote:

Op zondag 29 augustus 2010 15:33 schreef Cruise.Elroy het volgende:
Vergeet niet dat je bij elke string() call wel een stukje geheugen alloceert etc. Als je met std::string werkt, probeer dan zo snel mogelijk (en 1-malig) alle inkomende char* naar strings te converteren, en werk daarna met const string& referenties (of pointers) om zo het onnodig aanmaken van strings te voorkomen.

Niet dat je daarmee in de problemen zal komen, tenzij je echt tijdkritieke code gaat schrijven.

quote:

Op maandag 30 augustus 2010 23:35 schreef netolk het volgende:

[..]

Ik laat hem een tijdelijk object aanmaken voor het if-statement gebeuren

zoiets als dit
[ code verwijderd ]

quote:

Op donderdag 2 september 2010 11:12 schreef Cruise.Elroy het volgende:
ja ik had het nagezocht, en dat is idd zo. Vergeet niet dat std::string een specialisatie is van std::basicstring<> maar deze heeft nog extra functies om handig met de "ouderwetse" string0s uit C om te kunnen gaan
[ code verwijderd ]

quote:

Op donderdag 2 september 2010 14:37 schreef Cruise.Elroy het volgende:
Dat kan sowieso, als je er 20.000 per seconde gaat doen, dan wordt het pas een issue

quote:

Op maandag 20 september 2010 13:11 schreef Cruise.Elroy het volgende:
Nee, niet makkelijk volgens mij. Bijna alle standaard I/O is min of meer console-achtig.
Wat je kan doen is een frame-workje ergens downloaden die cross-platform is en die dingen goed wrapt.

quote:

Op maandag 20 september 2010 15:32 schreef thabit het volgende:
C++ is dan ook meer een verzameling hacks bij elkaar dan een echte programmeertaal.

quote:

Op maandag 20 september 2010 15:32 schreef thabit het volgende:
C++ is dan ook meer een verzameling hacks bij elkaar dan een echte programmeertaal.

quote:

Op maandag 20 september 2010 15:38 schreef Cruise.Elroy het volgende:
Troll

quote:

Op maandag 20 september 2010 23:04 schreef thabit het volgende:
Face it, mensen: het is niet goed porteerbaar, het heeft geen geheugenmanagement met garbage collector, het heeft geen goede ingebouwde ondersteuning voor parallelisatie. t Is eigenlijk gewoon een verkapte assembly en alleen handig voor kleine libraryfuncties die tot op de bit geoptimaliseerd moeten zijn en real-time applicaties en games waar elke ms telt en geheugen vaak de halve GB net haalt.

quote:

Op dinsdag 21 september 2010 13:29 schreef Cruise.Elroy het volgende:

[..]

Dit klopt allemaal, maar dat komt gewoon omdat de taal op een bepaald abstractieniveau zit. Maakt de taal niet slecht, gewoon krachtiger maar minder geschikt voor RAD.

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

quote:

Op woensdag 22 september 2010 21:47 schreef Cruise.Elroy het volgende:
Onder Windows kan je winsock.h gebruiken, werkt nagenoeg hetzelfde, maar je zal hier en daar wat calls moeten versleutelen.

quote:

Op donderdag 23 september 2010 10:08 schreef Cruise.Elroy het volgende:
Nog gelukt? Want winsock zou redelijk gelijk moeten zijn aan de standaard berkley sockets interface, zeker voor simpele apps.

http://en.wikipedia.org/wiki/Berkeley_sockets

quote:

Op zaterdag 25 september 2010 19:53 schreef Cruise.Elroy het volgende:
Ja dat zal je toch echt even zelf moeten debuggen, ik denk dat de client gewoon de verbinding verbreekt zodra hij verbinding heeft gemaakt. Iig een program-flow fout van jouw kant waarschijnlijk.