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.
C++ lijkt een beetje op CSS als je totaal niet oplet 
[ Bericht 93% gewijzigd door Pakspul op 05-08-2010 16:37:15 ]
[ Bericht 93% gewijzigd door Pakspul op 05-08-2010 16:37:15 ]
[CSS] voor dummies #15quote:Op donderdag 5 augustus 2010 16:23 schreef Pakspul het volgende:
Waarom werkt tekst transparantie in de volgende situatie niet?
[ code verwijderd ]
Zoals te zien is dat bij de eerste div situatie de tekst gewoon mooi wit is, maar bij de twee is de tekst ineens roodachtig ook al zou je anders verwachten
Je moeder is een hamster
Als je totaal niet oplet dan lijkt Annemarie Jorritsma ook op Chantal Janzenquote:
C++ lijkt een beetje op CSS als je totaal niet oplet
Je moeder is een hamster
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | int _tmain(int argc, _TCHAR* argv[]) { int (*fpoint)(int) = doeietsmetgetal; cout << fpoint(5); return 0; } int doeietsmetgetal(int x){ int * y = new int(x*5); return *y; } |
*y blijft inderdaad geheugen innemen omdat je new aanroept. Ook als je *fpoint wel zou kunnen verwijderen, dan blijven alle *y instanties gewoon geheugen innemen.
En hoe zorg ik ervoor dat y geen geheugen meer inneemt? Niet aanroepen met new? En hoe delete ik m'n fpoint? Of moet ik dan van die doeietsmetgetal functie gewoon een class maken? En mag ik aannemen dat zodra een variabele die zonder new is gedeclareerd verwijderd wordt zodra de functie exit?quote:Op donderdag 5 augustus 2010 18:10 schreef thabit het volgende:
*y blijft inderdaad geheugen innemen omdat je new aanroept. Ook als je *fpoint wel zou kunnen verwijderen, dan blijven alle *y instanties gewoon geheugen innemen.
Locale (niet-static) variabelen van functies worden op de stack aangemaakt, en die stackruimte wordt vrijgegeven als je de functie verlaat. De pointer y wordt dus ook vrijgegeven, maar niet de int *y waar hij naar verwijst. Ook is fpoint een functiepointer, dus gewoon een locale variabele die wordt verwijderd zodra je de functie verlaat. In het bovenstaande voorbeeld kun je beter
int y = x*5; return y;
doen, of zelfs direct return x*5;
int y = x*5; return y;
doen, of zelfs direct return x*5;
Ok en m'n functiepointer? Valt die gewoon te verwijderen? Of moet ik 'm dan in de scope van een functie zien te proppen?quote:Op donderdag 5 augustus 2010 18:35 schreef thabit het volgende:
Locale (niet-static) variabelen van functies worden op de stack aangemaakt, en die stackruimte wordt vrijgegeven als je de functie verlaat. De pointer y wordt dus ook vrijgegeven, maar niet de int *y waar hij naar verwijst. Ook is fpoint een functiepointer, dus gewoon een locale variabele die wordt verwijderd zodra je de functie verlaat. In het bovenstaande voorbeeld kun je beter
int y = x*5; return y;
doen, of zelfs direct return x*5;
Je functiepointer is gewoon een lokale variabele en zit in de scope van _tmain. In dit voorbeeld heb je verder geen functiepointers nodig en kun je gewoon
cout << doeietsmetgetal(5);
doen.
cout << doeietsmetgetal(5);
doen.
Hey,
Ik heb een probleem met virtual functies...
ik heb een namespace gemaakt in een header genaamd Shape.h
en ik heb dan in mn main het volgende staan:
Als ik dit probeer te compileren krijg ik de volgende foutmelding:
ik gebruik G++ als compiler, zou iemand me kunnen vertellen wat ik dan niet goed doe?
Ik heb een probleem met virtual functies...
ik heb een namespace gemaakt in een header genaamd Shape.h
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | class Point{ unsigned short X,Y; public: Point(unsigned short x,unsigned short y):X(x),Y(y) {} unsigned short get_X(){return X;} unsigned short get_Y(){return Y;} }; class Shape{ public: virtual void Rotate(int)=0; virtual void Draw()=0; virtual bool is_Closed()=0; }; class Circle:public Shape{ Point _CENTER; unsigned _RADIUS; void Rotate(int); public: Circle(Point p,unsigned r):_CENTER(p),_RADIUS(r){} void Draw(); bool is_Closed(){return true;} }; } |
| 1 2 3 4 5 6 7 | int main(){ shp::Circle myCircle(shp::Point(40,20),5); //myCircle.Draw(); return 0; } |
| 1 2 | collect2: ld returned 1 exit status |
Beware of the Raping Zebra's
even een recompile ofzo? hij zegt dat Circle geen virtual table heeft, en blijkbaar ergens niet als derived class is gedefinieerd?
Geen idee verder.
Geen idee verder.
Dat is toch raar want Circle zou toch gewoon een virtual table moeten hebben aangezien zijn base class puur virtueel is?quote:Op vrijdag 6 augustus 2010 13:56 schreef Cruise.Elroy het volgende:
even een recompile ofzo? hij zegt dat Circle geen virtual table heeft, en blijkbaar ergens niet als derived class is gedefinieerd?
Geen idee verder.
Beware of the Raping Zebra's
nou omdat een cirkel roteren niet echt nuttig is...
maar ik dacht miss is dat het probleem maar toen ik hem public had kreeg ik nog steeds de zelfde melding...
maar ik dacht miss is dat het probleem maar toen ik hem public had kreeg ik nog steeds de zelfde melding...
Beware of the Raping Zebra's
Hij is public in Shape. Dus als je een object van type Shape hebt, en weet niet wat voor Shape het is, moet je wel Rotate erop kunnen aanroepen. Maar goed, dat terzijde.
Hmm... daar heb je idd een puntquote:Op vrijdag 6 augustus 2010 14:44 schreef thabit het volgende:
Hij is public in Shape. Dus als je een object van type Shape hebt, en weet niet wat voor Shape het is, moet je wel Rotate erop kunnen aanroepen. Maar goed, dat terzijde.
Beware of the Raping Zebra's
Staat ook in mn 1e post maar ik zal hem nog een keertje neerzetten
ik heb die Circle::rotate(int) ook maar even public gemaakt
[ Bericht 4% gewijzigd door netolk op 06-08-2010 15:17:26 ]
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | #define SHAPE_H namespace shp{ class Point{ unsigned short X,Y; public: Point(unsigned short x,unsigned short y):X(x),Y(y) {} unsigned short get_X(){return X;} unsigned short get_Y(){return Y;} }; class Shape{ public: virtual void Rotate(int)=0; virtual void Draw()=0; virtual bool is_Closed()=0; }; class Polygon:public Shape{ public: bool is_Closed(){return true;} }; class Circle:public Shape{ Point _CENTER; unsigned _RADIUS; public: Circle(Point p,unsigned r):_CENTER(p),_RADIUS(r){} void Rotate(int); void Draw(); bool is_Closed(){return true;} }; } #endif |
[ Bericht 4% gewijzigd door netolk op 06-08-2010 15:17:26 ]
Beware of the Raping Zebra's
Ja, iknow ik heb geen .cpp file maar die heb ik voor classes toch ook niet nodig??quote:
Ik heb de functies nog niet verder uitgewerkt, dus nog geen .cpp
Beware of the Raping Zebra's
Dan zit daar dus het probleem: de functies Circle::Rotate en Circle::Draw zijn alleen gedeclareerd, maar niet gedefinieerd. Dat vindt de linker niet zo grappig (vandaar ook een 'ld' error: het compilen gaat op zich goed, alleen het linken wil niet).
Hehe, daar kwam ik idd ook net achter...quote:Op vrijdag 6 augustus 2010 15:18 schreef thabit het volgende:
Dan zit daar dus het probleem: de functies Circle::Rotate en Circle::Draw zijn alleen gedeclareerd, maar niet gedefinieerd. Dat vindt de linker niet zo grappig (vandaar ook een 'ld' error: het compilen gaat op zich goed, alleen het linken wil niet).
Best wel dom, nouja bedankt in iedergeval
Beware of the Raping Zebra's
Maar hij roept Rotate en Draw niet aanquote:Op vrijdag 6 augustus 2010 15:18 schreef thabit het volgende:
Dan zit daar dus het probleem: de functies Circle::Rotate en Circle::Draw zijn alleen gedeclareerd, maar niet gedefinieerd. Dat vindt de linker niet zo grappig (vandaar ook een 'ld' error: het compilen gaat op zich goed, alleen het linken wil niet).
Nog wat algemene opmerkingen: als je een base class aanmaakt, waar je classes van wilt afleiden, is het raadzaam om ook de destructor virtual te maken. En in de constructor van Circle kun je Point beter als reference doorgeven dan als value.
C++ is geen Python.quote:Op vrijdag 6 augustus 2010 15:23 schreef TeringHenkie het volgende:
[..]
Maar hij roept Rotate en Draw niet aan
[ Bericht 0% gewijzigd door thabit op 06-08-2010 15:33:57 ]
jepquote:Op vrijdag 6 augustus 2010 15:31 schreef Cruise.Elroy het volgende:
Wel rare error voor een linkerfout. Maar is het nu gefixed?
hoe zo als reference dan? kost dan minder resources?quote:Op vrijdag 6 augustus 2010 15:25 schreef thabit het volgende:
Nog wat algemene opmerkingen: als je een base class aanmaakt, waar je classes van wilt afleiden, is het raadzaam om ook de destructor virtual te maken. En in de constructor van Circle kun je Point beter als reference doorgeven dan als value.
En die destructor moet ik die in de afgeleide classes ook neerzetten of kan ik dat achterwege laten? (tenzij ik een destructor nodig heb natuurlijk)
Beware of the Raping Zebra's
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★
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.
