DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Die destructor maak je virtual zodat hij (automatisch) kan worden aangeroepen als je afgeleide klassen destruct. Anders krijg je later evt. memory leaks (hoeft eigenlijk alleen als je destructor echt iets doet maar het is wel goed om het aan te leren)
En ja, als reference heb je iets minder resources maar in dit geval maakt het niet heel veel uit.
En ja, als reference heb je iets minder resources maar in dit geval maakt het niet heel veel uit.
ik heb nog een vraagje bestaat er ook iets als #exclude? aangezien je wel #define en #undef hebt...
Beware of the Raping Zebra's
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
#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
echt, cruise.elroy, jij weet tenminste echt waar je over praat.. 
Ik word echt doodmoe van alle programmeurs waarmee ik al heb moeten werken en die, zodra ze hun database connectie niet kunnen instellen via een Wizard, niet weten hoe het moet
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
Ik word echt doodmoe van alle programmeurs waarmee ik al heb moeten werken en die, zodra ze hun database connectie niet kunnen instellen via een Wizard, niet weten hoe het moet
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
"Wie niet gelooft in wonderen, is geen realist."
Da's een kwestie van economie: goede hardware is tegenwoordig goedkoper dan een goede programmeur.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
Nou, als de salaris-eis nou ook eens in overeenstemming was met het gewenste niveau..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.
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..
"Wie niet gelooft in wonderen, is geen realist."
Ik neem aan dat een C++ programmeur wel meer verdient dan iemand die formpjes in elkaar klikt in C#?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..
Hehe ja dat zeker..
Maar ik ken ook genoeg Senior C#/asp.net programmeurs die er werkelijk waar geen drol van begrijpen..
En toch ook een salaris verdienen van in de 4000 euro, maar ja
Al hebben we ook eens een Senior C++ programmeur in dienst gehad en ik begreep er destijds (als junior) al meer van dan hij Maar ja die heb je er altijd tussen zitten he.
Maar ik ken ook genoeg Senior C#/asp.net programmeurs die er werkelijk waar geen drol van begrijpen..
En toch ook een salaris verdienen van in de 4000 euro, maar ja
Al hebben we ook eens een Senior C++ programmeur in dienst gehad en ik begreep er destijds (als junior) al meer van dan hij
Maar ja die heb je er altijd tussen zitten he.
"Wie niet gelooft in wonderen, is geen realist."
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
Conclusie: C# voor de GUI, en de snelle/geavanceerde code stop je in een c++ DLL die je dan DllImport
Ja daar was ik al bang voorquote: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
, ik dacht miss kan het dus als je in een header a header b include dan kan je dus overal waar a geinclude word ook die van b gebruiken...
Beware of the Raping Zebra's
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.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
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.
Handgeschreven ASM 
daar kan geen compiler tegenop 
daar kan geen compiler tegenop
★5731U★ Death from above '79★You're a woman, i'm a machinielsie ★ ✠ ★ Telkens weer een beetje sterven★ I was born in a winterstorm, i live there still★
Als je met handgeschreven stiekem optimaal bedoelt, dan ja. Handgeschreven ASM is vaak alles behalve optimaal. Niet zo gek als je de intel procs zien icm 8086 ASM.quote:Op zondag 8 augustus 2010 21:38 schreef Trollface. het volgende:
Handgeschreven ASM
Vaak kan je met C# talen snelheidswinst halen omdat tight loops run-time herschreven worden naar gelang de variabelen. Natuurlijk kan je dit zelf gaan schrijven in ASM, maar dan ben je echt gek.
Ik ben nou eenmaal gekquote:Op zondag 8 augustus 2010 21:56 schreef Cruise.Elroy het volgende:
[..]
Als je met handgeschreven stiekem optimaal bedoelt, dan ja. Handgeschreven ASM is vaak alles behalve optimaal. Niet zo gek als je de intel procs zien icm 8086 ASM.
Vaak kan je met C# talen snelheidswinst halen omdat tight loops run-time herschreven worden naar gelang de variabelen. Natuurlijk kan je dit zelf gaan schrijven in ASM, maar dan ben je echt gek.
__asm__ {}
★5731U★ Death from above '79★You're a woman, i'm a machinielsie ★ ✠ ★ Telkens weer een beetje sterven★ I was born in a winterstorm, i live there still★
Zonde van je tijd 
ik schrijf eigenlijk alleen maar zware time-critical code en zelfs ik gebruik het eigenlijk nooit. Er is eigenlijk altijd wel een meer (dev)tijd-efficientere manier om snelheid te winnen.
ik schrijf eigenlijk alleen maar zware time-critical code en zelfs ik gebruik het eigenlijk nooit. Er is eigenlijk altijd wel een meer (dev)tijd-efficientere manier om snelheid te winnen.
push eax
push ecx
mov al, 0
mov cl, 5
:lp1
add al, cl
dec cl
or cl, cl
jnz lp1
pop ecx
pop eax
push ecx
mov al, 0
mov cl, 5
:lp1
add al, cl
dec cl
or cl, cl
jnz lp1
pop ecx
pop eax
★5731U★ Death from above '79★You're a woman, i'm a machinielsie ★ ✠ ★ Telkens weer een beetje sterven★ I was born in a winterstorm, i live there still★
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.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
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?
@ ASM
Tof, maar je code doet niets nuttigs, doet dit bijzonder efficient, en reset zijn waardes aan het einde.
Tof, maar je code doet niets nuttigs, doet dit bijzonder efficient, en reset zijn waardes aan het einde.
Je code draait gewoon op je CPU, waar anders opquote: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?
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.
Low-level programming is mijn dingquote:Op zondag 8 augustus 2010 22:19 schreef Cruise.Elroy het volgende:
[..]
Je code draait gewoon op je CPU, waar anders op
★5731U★ Death from above '79★You're a woman, i'm a machinielsie ★ ✠ ★ Telkens weer een beetje sterven★ I was born in a winterstorm, i live there still★
Dat snap ik, maar de windows kernel mag niet hetzelfde als de HAL, en een applicatie mag niet hetzelfde als de kernel. Hoe wordt dat afgeschermd? Interrupts die worden afgevangen/geblokkeerd oid?quote:Op zondag 8 augustus 2010 22:19 schreef Cruise.Elroy het volgende:
[..]
Je code draait gewoon op je CPU, waar anders op
Dat ik bij FOK! dev wil niet zeggen dat ik alleen aan webdevving doequote:
★5731U★ Death from above '79★You're a woman, i'm a machinielsie ★ ✠ ★ Telkens weer een beetje sterven★ I was born in a winterstorm, i live there still★
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)
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)
Nee maar iemand die low-level zit te hacken (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
) is normaal niet iemand die webdevving echt kan waarderen. En je ASM is niet echt geweldig. nm, de mijne is ook kut
