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

De parameters geef je als pointer door in het vierde argument van CreateThread.

Misschien moet je in de main() je SOCKET behalve declareren ook initialiseren.

Het volgende is ook een erg rare cast:


Data is al een pointer. &Data levert dus het adres van een pointer. Dit cast je naar een Socket-pointer. En die dereference je. De compiler denkt nu dus dat het een Socket is, terwijl je eigenlijk een Socket-pointer hebt.

Probeer het volgende eens:


En let op dat de hClient nog steeds op de stack in main() staat: als hij hier uit scope raakt of overschreven wordt, dan ben je je gegevens kwijt en crasht de boel (dus beter advies is dynamisch alloceren).

quote:

hmm, wat ik dus probeerde was met die cast er voor zorgen dat de compiler idd denkt dat het een socket is en die vervolgens kopieert naar de socket in the nieuwe thread

Tsja, maar als de compiler denkt een Socket te hebben terwijl het eigenlijk het adres van een Socket is, kunnen er natuurlijk geen goede dingen gebeuren.

Sowieso is een nieuw kopie maken in Threader() onveilig, omdat er geen garantie is dat het object nog bestaat ten tijde van kopieren (tenzij jij die garantie als programmeur geeft d.m.v mutex locks of iets dergelijks).

quote:

Op vrijdag 11 maart 2011 18:35 schreef netolk het volgende:

kan bij die delete de brakkets ("[]") weggelaten worden?

Het moet zelfs, want je delete geen gealloceerde array van Sockets, maar één enkele. In het algemeen geldt: alleen met delete[] verwijderen als je met new[] gealloceerd hebt.

Je bovenstaande code is gevaarlijk omdat het gedrag ongedefinieerd is: per implementatie kan het resultaat verschillen (en waarschijnlijk segfaulten).

quote:

Op zondag 13 maart 2011 11:44 schreef netolk het volgende:

oke, ik snap die brakkets nu maar waarom waarom is het gedrag ongedefinieerd dan?

TL;DR versie: Omdat C++ niet beschrijft hoe deze situatie afgehandeld moet worden.

Lange versie: De programmeertaal 'C++' wordt ontwikkeld door een groep mensen die precies omschrijft wat C++ moet kunnen en doen. Deze groep maakt echter geen compilers, maar alleen een beschrijving van de taal. Compilerbouwers (zoals Microsoft, GCC, Borland etc.) gebruiken deze beschrijving en moeten deze precies volgen als ze een C++-compiler willen maken.

Niet alles staat echter in beschrijving van de taal (ook wel 'standaard' genoemd). Bijvoorbeeld het onderstaande stukje beschrijft de de memberfunctie sum() van de std::valarray class:

quote:

T sum () const ;
This function may only be instantiated for a type T to which operator+= can be applied. This function returns the sum of all the elements of the array.
If the array has length 0, the behavior is undefined. If the array has length 1, sum() returns the value of element 0. Otherwise, the returned value is calculated by applying operator+= to a copy of an element of the array and all other elements of the array in an unspecied order.

Hierin staat dus precies wat std::valarray::sum() moet doen. Het interessante stuk is dikgedrukt. Omdat niet is gedefinieerd wat de functie moet doen als lengte = 0, kan dit verschillen per compilerbouwer. Ze kunnen er bijvoorbeeld voor kiezen te segfaulten, een exception te gooien of gewoon '0' terug te geven als resultaat. Het punt is: ze kunnen kiezen.

Als je dus goede C++ code wilt schrijven, moet je zorgen dat je nooit sum() gebruikt van een leeg std::valarray object: je weet immers niet wat er gaat gebeuren. Je kunt wel testen wat er met jouw compiler gebeurt, maar je weet dan nog niet (a) of dit met iets andere code ook zo zal zijn, (b) of dit in een andere versie van jouw compiler (ouder/nieuwer) ook zo zal zijn en al helemaal niet of (c) dit met een andere compiler ook werkt.

Het resultaat van delete[] op een gewone pointer is ook zoiets: het effect van die operatie staat niet in de standaard, dus moet je er niet vanuit gaan dat het werkt. Dat wordt bedoeld met 'ongedefinieerd gedrag': het resultaat van een operatie die niet in de standaard staat en dus per implementatie kan verschillen.

[ Bericht 0% gewijzigd door GS42 op 13-03-2011 12:21:25 ]

Niet specifiek C++ deze vraag, maar is het mogelijk de handle van een control te krijgen (bv een textbox) in flash?

Aangezien ze voor zover ik kan zien geen eigen hWnd hebben.

Ok weet niet of iemand me kan helpen maar ik waag maar de gok

Ik wil graag libHaru, een opensource pdf library, compilen naar een dll. Op de wiki documentatie zeggen ze dat je het volgende moet doen voor windows:

- unzip libharu-X.X.X.zip
- cd libharu-X.X.X
- Microsoft VC++ Compiler: nmake -f script/Makefile.msvc_dll demo

Nu heb ik dat gedaan alleen krijg ik steeds een error:

quote:

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.

cl -Fosrc\hpdf_streams.obj /MD -nologo -O2 -Iinclude -Iwin32\include -
I"../../libpng"\include -I"../../zlib"\include -DHPDF_DLL_MAKE -c src\hpdf_strea
ms.c
hpdf_streams.c
src\hpdf_streams.c(28) : fatal error C1083: Cannot open include file: 'zlib.h':
No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\cl.EXE"' : return code '0x2'
Stop.

Blijkbaar kan hij een header zlib niet vinden. Ik geloof dat deze bij de zlib hoort, http://zlib.net/. Alleen lees ik nergens in de documentatie dat je die ook moet hebben. Ook lijkt het als of je http://www.libpng.org/pub/png/ nodig hebt... ook hier lees ik niets van in de documentatie...

Iemand enig idee hoe ik dit oplos? Ben niet echt bekend met het compilen van dll's en makefiles.

De code is hier te downloaden, niet van http://libharu.org/ zelf want dan mis je een aantal dirs.

De makefile

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.

Dale, heb je geprobeerd de preprocess-flag LIBHPDF_HAVE_NOZLIB te definieren? Als ik de code in /src/hpdf_streams.c doorblader, krijg ik het idee dat er dan gecompileerd wordt zonder zlib-functionaliteit (wat dat ook in moge houden...).

Zoniet, dan lijkt het erop dat je inderdaad de zlib library nodig hebt op je systeem.

Je lijkt dingen te deleten die niet met new worden aangemaakt. Dat kan natuurlijk niet goed gaan.

quote:

Op donderdag 17 maart 2011 18:10 schreef thabit het volgende:
Je lijkt dingen te deleten die niet met new worden aangemaakt. Dat kan natuurlijk niet goed gaan.

Dat is inderdaad een probleem, maar zijn fout wordt veroorzaakt door iets anders: bekijk je LList constructor LList(Piece start):_START(&start) eens goed. Wat klopt hier niet? (Hint: waar wordt 'Piece start' geinitialiseerd en wanneer wordt deze vernietigd?)

quote:

Op donderdag 17 maart 2011 18:55 schreef netolk het volgende:

[..]

umm, hij word geïnitialiseerd bij de constructie, en weer vernietigd tijdens de destructie van LList

Je past daar pass-by-value toe. Dat ding wordt dus meteen al vernietigd bij het verlaten van de constructor.

quote:

Op zaterdag 2 april 2011 15:32 schreef netolk het volgende:
Hey heeft iemand een idee waarom dit niet werkt??
[ code verwijderd ]

als bool b_temp = true; dan zou dit toch een oneindige loop moeten vormen die steeds read op ifstr_loc zet en dan iets gaat doen??

Ja, tenzij b_temp in Handle_Function aangepast wordt. Dan hoeft de loop niet oneindig te zijn.

quote:

ik krijg nu dat Handle_Function 1x word uitgevoerd en daarna is read.tellg() -1 nadat seekg(44) is aangeroepen, kan iemand mij misschien vertellen waarom read.tellg() -1 word?

Aannemende dat 'read' een of andere istream is, dan geeft tellg() -1 terug als deze faalt. Dit betekent hoogstwaarschijnlijk dat 'read' geen vailde status meer heeft, dus dat een of andere operatie in Handle_Function gefaald is. In het algemeen lees je nooit van een istream zonder te controleren of de istream wel leesklaar is. Probeer maar eens de statusbits van de istream af te drukken (eof, fail en bad), dan zal je zien dat dat de stream zich in een foutstaat bevindt.

[ Bericht 1% gewijzigd door GS42 op 03-04-2011 15:15:35 ]