|
|
|
|
Azt hiszem, ezek után innen ne várj segitséget... 
|
|
|
|
BOCSIIIIIIi hoszzu napom volt, hülye suli után már mindenen megsértődők, minden negatív megjegyzést komolyan veszek ( mondjuk lehet hoghy komoly is volt ) 
Ami tönkremehet, az tönkre is megy!!!
|
|
|
|
[bunkó megjegyzés]
Tisztelet a kivételért. Bocsánat az offért. Köszönet a válaszokért.
Ezt a hozzászólást AmidaBucu módosította (2008.03.05 09:00 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
|
|
|
|
van értelme, 4 karakternek 
|
|
|
|
Idézet
AmidaBucu :
Hi!
Pointer problémám lenne.
Van egy Kód: D3DXHANDLE* handle;
handle = (D3DXHANDLE*)malloc(sizeof(LPCSTR));
pointerem;
Megvan cimezve rendesen, de amikor itt tarta program:
Kód: [...]
handle[0] = Effects[0].EEffect->EndParameterBlock();
Tönkre megy a pointer. Próbálkoztam mindennel de nem tom megcsinálni.
Vmi ötlet hogy lehet?
Az EndParameterBlock() függvény definíciója így néz ki:
D3DXHANDLE EndParameterBlock();
Úgy látom, csinálsz egy handle-t, aminek aztán LPCSTR méretű memóriát foglalsz (LPCSTR = const char*, ergó pointer típus).
Aztán ebbe D3DXHANDLE-t próbálsz beleerőltetni. Értelme semmi.
Csináld így:
Kód: D3DXHANDLE handle;
[...]
handle = Effects[0].EEffect->EndParameterBlock();
|
|
|
|
na vajon mért
#define LPCSTR const char*
ami 4 bájt és pointer típus..
wtoma válasza sem jó mert az ugyanazt csinálja
helyesen:
D3DXHANDLE* alma = (D3DXHANDLE*)malloc(valami * sizeof(char));
ahol valami a szöveg hossza + 1 (stringvége karakter)
amugy biztos vagy te ebben a dx ben?
Ezt a hozzászólást Asylum módosította (2008.03.05 07:07 GMT+1 óra, ---)
|
|
|
|
Nah, valaki tudna segíteni az előző kérdésemmel kapcsolatban? A pointer problémában?
Ami tönkremehet, az tönkre is megy!!!
|
|
|
|
Idézet
Orphy :
Megvan a megoldás, elég tanulságos lehet azoknak, akik hozzám hasonlóan C# alól érkeztek:
Ha egy C++ progit dll-be, vagy static library-be fordítunk, akkor a kötelezően mellékelt header file-nak tartalmaznia kell a private részeket is...
ezért szoktak inkább interfaceket csinálni és igy csak azok a headerek, minden más számraztatással történik
|
|
|
|
Idézet
Nem vagyok benne a DX-ben, de nekem logikusnak tűnne D3DXHANDLE típusú ptr-nek D3DXHANDLE méretet foglalni
Mindegy mer D3DXHANDLE végüis LPCSTR típus csak más néven. Any Idea?
Ami tönkremehet, az tönkre is megy!!!
|
|
|
|
Megvan a megoldás, elég tanulságos lehet azoknak, akik hozzám hasonlóan C# alól érkeztek:
Ha egy C++ progit dll-be, vagy static library-be fordítunk, akkor a kötelezően mellékelt header file-nak tartalmaznia kell a private részeket is...
|
|
|
|
hmm, megpróbáltam sima static library-ként is, de ugyanaz a hiba:
úgy tűnik, mintha a tömböket, és std-s osztályokat valamiért teljesen rosszul kezelné lib-ből... 
|
|
|
|
Van egy eléggé idegesítő problémám:
A framework-ömet szeretném dll-esíteni.
A megfelelő osztályokhoz betettem a __declspec(dllexport) sorokat, átállítottam a projektet dll-re, le is fordult hiba nélkül, megkaptam a dll-t, és a lib-et.
A probléma akkor van, ha használni is szeretném:
megcsináltam az import interfészt, a megfelelő osztályok .h-ja van benne namespace-estől, de csak a függvénydefiníciókkal, és __declspec(dllimport)-tal az osztálydefiníció előtt.
Eddig is ok.
A main.cpp-ben is ok a kód, szépen le is fordul.
Aztán amikor tesztelném, akkor kapok egy access violation writing location error-t az arcomba, ha pl egy olyan osztályt példányosítok, ami konstruktorban default értékekkel tölti fel magát.
Ha pl static függvényt hívok egy osztályból, ami nem nyúlkál ilyenekhez, az megy.
Az osztályok nem hibásak, működnek, a hiba biztosan a dll-esítéssel függ össze!
Találkozott már valaki ilyennel?
|
|
|
|
Nem vagyok benne a DX-ben, de nekem logikusnak tűnne D3DXHANDLE típusú ptr-nek D3DXHANDLE méretet foglalni 
Kód: D3DXHANDLE* handle;
handle = (D3DXHANDLE*)malloc(sizeof(D3DXHANDLE));
(az LPCSTR egy pointer típus, ha jól értem a google találatokat...)
|
|
|
|
Hi!
Pointer problémám lenne.
Van egy Kód: D3DXHANDLE* handle;
handle = (D3DXHANDLE*)malloc(sizeof(LPCSTR));
pointerem;
Megvan cimezve rendesen, de amikor itt tarta program:
Kód: [...]
handle[0] = Effects[0].EEffect->EndParameterBlock();
Tönkre megy a pointer. Próbálkoztam mindennel de nem tom megcsinálni.
Vmi ötlet hogy lehet?
Ami tönkremehet, az tönkre is megy!!!
|
|
|
|
Ellenben ha érvényes objektumra mutat, akkor a (2005-össel kezdődően már biztosan) a VS debugger meg tudja mutatni, hogy mi is van az objektumban. Hasznos még az expression kiértékelés, azzal is lehet ellenőrizni dolgokat.
|
|
|
|
Megpróbálhatod, hogy nyomsz egy F5-t (elindul a debug), fontos, hogy ne legyen fullscreen a cucc, majd megmutatja azt a sort, ahol kifagy. Ha ott van vmi pointerkedés, akkor megnézheteted akár csak egérrámutatással, hogy hátha vmelyik 0-ra mutat (vagy a 0xCCCCCC...érték is lehet hiba - not iniced kb.).
Ha itt nincs, és ez mondjuk egy class vmelyik függvényében van, akkor valszeg valahol van egy pointer aminek a típusa ez az osztály, de rossz címre mutat. Nekem sokszor így van.
(bocs a fogalmazásért, épp most ettem )
|
|
|
|
Ha access violation, akkor az egyik pointered nem ok.
Elképzelhető, hogy létrehozáskor, vagy törlés után nem incializáltad NULL-ra (és ilyenkor az if(pointer) ellenőrzések sem segítenek), esetleg egy függvény valami hiba miatt NULL pointert ad vissza, és ezt nem vizsgáltad meg...
Debugolj ezerrel, ilyenkor az segít a legtöbbet!
|
|
|
|
közelebbit sajna nem, access violation error hiba, de sajna nemtok rájönni...
|
|
|
|
ja arra ondoltm nálam mindkettő fagyásnak számit
|
|
|
|
Igaz, pointerek is okozhatják.
Mondjuk nálam pointer miatt még soha nem fagyott ki semmi, maximum kaptam egy access violation error-t, és szétszállt a progi. A kifagyásra szerintem általánosságban a végtelen ciklus valószínűbb.
Ibax, esetleg valami közelebbit tudsz mondani?
|
|
|
|
általában pointerek okozzák
|
|
|
|
Az hogy a build successfull, az azt jelenti, hogy nincs a kódban olyan syntax hiba, illetve nem implementált fügvény, ami miatt nem lehetne a progit lefordítani.
Ez viszont nem jelenti azt, hogy a program jól is fog működni.
A debugolás úgy működik, hogy a program egy sora elé beteszed a piros pöttyöt - ekkor ha odaér a vezérlés, akkor a progid megáll, és az F10, F11 billekkel soronként tudod a kódot végrehajtani, vagy az F5-tel folytatni. Közben meg tudod nézegetni a változóidat.
Ennek előfeltétele, hogy a debughoz szükséges map file-t a Studio elkészítse, hogy debug módban fordíts, meg hasonlók. Szvsz a progid első sorára nézd meg, működik-e a debug, ha nem, akkor még be kell állítani valamit. Ha megy, akkor debugolhatsz.
A lefagyást általában végtelen ciklus okozza, érdemes megnézegetni a while és for ciklusokat.
|
|
|
|
a debug-olásban tudna segíteni valaki (visual studio 2005).
c++ -os projektem van, és tudom, hogy a sor elejére egy KATT lerak egy piros pontot, ami azt jelzi (gondolom), hogy addig a pontig fusson a progi, és utána várjon felhasználói beavatkozásra a továbbfutáshoz (?).
sajnos elakadtam egy proginál, mert a build successfull, de a progi kifagy egy idő után, és így nehéz rájönnöm a hiba tényleges okára...
|
|
|
|
vagy felveszed attribútumnak
|
|
|
|
1) adogasd át szépen minden függvénynek. Ha nagy adatról van szó, akkor persze csak a címet
2) rakd be egy osztályba statikus változónak. Ekkor gyakorlatilag globálisként viselkedik, de legalább van egy hely, ahova logikailag tartozik (valamint elkerülhető a névütközés.)
|
|
|
|
és miért baj globális változókat használni? ha szükségem van olyan változókra, amiket több függvényben is használni fogok, felhasználok, akkor azt hogy oldjam meg globális változók nélkül?
|
|
|
|
hát ha már nekiálltál az oop-nek akkor nemkéne globális változókat használi egyrészt...másrészt figyelni kell arra, hogy mi minek adsz értékül mert pointerek esetén a legeldugottabb hibától is az egész program hülyeséget csinál.
|
|
|
|
hmm, ma megoldottam a problémát, egy kicsit másképp. ami mindenképp hiányzott, az a while ciklus if -jének else ágából a Kód: temp.nextRow(); sor, vagyis amikor a feltétel nem teljesült, és belementem az else ágba, attól kezdve végtelen ciklusra futottam. valamint kivettem a fgv negyedik paraméterét, és egy másik fgv-t írtam, ami egyszerüen átadja a globális patientID mutatónak a kapott char* mutatót.
aztán szépen lassan óvatosan a Kód: cout << patientID; -t lecseréltem Kód: cout << patientID[0]; -ra, majd töröltem a sort, és most müxik 
igazából máig se értem, mi lehetett a gond...
|
|
|
|
a függvényen belül a negyedik paraméterként kapott mutató értékét átadom egy újonnan deklarált mutatónak, és annak segítségével vizsgálok a feltételben. mivel mindez egy fgv-en belül van, ezért ennek így müködnie kéne, nem?
függetlenül attól, hogy hol deklaráltam (vagy rosszul tudom?)
egyébként a header file-ok után deklaráltam, mielőtt elkezdtem volna kidolgozni az egyes függvényeket (az admin osztályom függvényeit; void admin::mainMenuDatas(), stb)
|
|
|
|
hát de ebben amit beirtál én nem látok deklarációt 
ugyérted, hogy ez egy member változó? ha igen mi képes megváltoztatni
|
|
|
|
és így hívom meg a main-ból a fgv-t:
Kód: admin.mainMenuDatas(env,driver,device,tempbuf);
ahol tempbuf-nak lefoglaltam memterületet. így a tempbuf által lefoglalt területre mutat az előbb említett pid mutató is (ugye?)
|
|
|
|
patientID-t még az összes fgv elején deklaráltam, hogy minden fgv használni tudja. igazából ebben tárolom az aktuálisan kijelölt ID-t, amit a pid-ben kapok meg (hogy esetleg más fgv is tudja, miről van szó). mivel mutatókról van szó, elég úgy, ahogy írtam. vagy nem???
bár tudom, ebben a fgv-ben máshol nem is használom
|
|
|
|
Kód: patientID = pid;
ez hol van deklarálva és mit müvel
mit is tanultunk ovodában a pointerekröl?
|
|
|
|
a patientID = pid kell, mert máshol is felhasználom, más fgv-ekben...
az első cout kikommentezése után végtelen ciklust kapok, a második cout (while-ban) kikommentezése után kifagy a progi...
de ebben a formában müxik 
|
|
|
|
azt kihagytam, mert ennek így is teljesen müködnie kéne...
de ez a müködő verzió:
Kód: void Admin::mainMenuDatas(IGUIEnvironment* env, IVideoDriver* driver, IrrlichtDevice* dev,char* pid)
{
cout << pid;
patientID = pid;
int i;
b1 = env->addButton(rect<s32>(275, 200, 403, 264),0,6003); // gomb
b1->setImage(driver->getTexture("buttons/bUsePatient.jpg"),rect<s32>(0, 0, 128, 64));
b1->setToolTipText(L"Use selected patient");
b2 = env->addButton(rect<s32>(510, 200, 638, 264),0,6003); // gomb
b2->setImage(driver->getTexture("buttons/bDetails.jpg"),rect<s32>(0, 0, 128, 64));
b2->setToolTipText(L"View patient's details");
name = env->addStaticText(L"Name:",rect<s32>(270,70,420,92),0,0,0,-1);
date = env->addStaticText(L"Date of birth:",rect<s32>(270,110,420,132),0,0,0,-1);
id = env->addStaticText(L"ID:",rect<s32>(270,150,420,172),0,0,0,-1);
namebox = env->addEditBox(L"",rect<s32>(460,68,688,94),1,0,-1);
datebox = env->addEditBox(L"",rect<s32>(460,108,688,134),1,0,-1);
idbox = env->addEditBox(L"",rect<s32>(460,148,688,174),1,0,-1);
db.open(dbFile);
CppSQLiteQuery temp = db.execQuery("SELECT * FROM patients;");
const char* buf;
wchar_t* wbuf;
char* var = new char[20];
sprintf(var,pid);
while(!temp.eof())
{
cout << "pid " << pid;
if (strcmp(var,temp.fieldValue("personalID")) && !temp.eof())
{
temp.nextRow();
}
else
{
buf = getSelectedListItem();
mbstowcs(wbuf,buf,52);
namebox->setText(wbuf);
buf = temp.fieldValue("year");
mbstowcs(wbuf,buf,5);
datebox->setText(wbuf);
buf = temp.fieldValue("personalID");
mbstowcs(wbuf,buf,20);
idbox->setText(wbuf);
}
}
temp.finalize();
db.close();
}
csak akkor müxik az egész, ha az elején,és a while ciklusban is kiíratom a "pid" értékét, valamint a if feltételébe nem konrkétan a pid-et ellenőrzöm, hanem egy olyan változót, amibe beleírtam előtte a "pid"-et (var változó)
nagyon kókány és beteges megoldás, de csak így müxik a progi...
|
|
|
|
és hol iratod a ki a problémás részt?
és a ciklus előtt még jó a pid? hogyan adod át, hogyan deklarálod
Ezt a hozzászólást Asylum módosította (2008.02.25 10:15 GMT+1 óra, ---)
|
|
|
|
még egy picit szenvedek vele, mert állandóan próbálkozok átírom, és irrlicht-béli osztályokat jócskán felhasznál, valamint egy adatbázissal is össze van kötve a progi, de a lényeg a köv. fgv:
Kód: void Admin::mainMenuDatas(IGUIEnvironment* env, IVideoDriver* driver, IrrlichtDevice* dev,char* pid)
{
int i;
b1 = env->addButton(rect<s32>(275, 200, 403, 264),0,6003); // gomb
b1->setImage(driver->getTexture("buttons/bUsePatient.jpg"),rect<s32>(0, 0, 128, 64));
b1->setToolTipText(L"Use selected patient");
b2 = env->addButton(rect<s32>(510, 200, 638, 264),0,6003); // gomb
b2->setImage(driver->getTexture("buttons/bDetails.jpg"),rect<s32>(0, 0, 128, 64));
b2->setToolTipText(L"View patient's details");
name = env->addStaticText(L"Name:",rect<s32>(270,70,420,92),0,0,0,-1);
date = env->addStaticText(L"Date of birth:",rect<s32>(270,110,420,132),0,0,0,-1);
id = env->addStaticText(L"ID:",rect<s32>(270,150,420,172),0,0,0,-1);
namebox = env->addEditBox(L"",rect<s32>(460,68,688,94),1,0,-1);
datebox = env->addEditBox(L"",rect<s32>(460,108,688,134),1,0,-1);
idbox = env->addEditBox(L"",rect<s32>(460,148,688,174),1,0,-1);
db.open(dbFile);
CppSQLiteQuery temp = db.execQuery("SELECT * FROM patients;");
const char* buf;
wchar_t* wbuf;
while(!temp.eof())
{
if (strcmp(pid,temp.fieldValue("personalID")) && !temp.eof())
{
temp.nextRow();
}
else
{
buf = getSelectedListItem();
mbstowcs(wbuf,buf,52);
namebox->setText(wbuf);
buf = temp.fieldValue("year");
mbstowcs(wbuf,buf,5);
datebox->setText(wbuf);
buf = temp.fieldValue("personalID");
mbstowcs(wbuf,buf,20);
idbox->setText(wbuf);
}
}
temp.finalize();
db.close();
}
igazából itt a "pid" változó (kb 6-7 karaktert tartalmaz) a lényeg, ami egy char*. az is furcsa, hogy a pid változó értéke a while() ciklusba érés után megváltozik. mégpedig akkor, amikor az if ciklus féltételei igazat adnak vissza. amíg nem igazak a feltételek, addig megmarad az értéke, amint igaz, és végrehajtja a temp.nextRow() utasítást (ami nem más, mint az előzőekben leírt sql lekérdezés következő sorára ugrás), a pid értéke megváltozik, eztán már csak a pid-ben az előző 6-7karakter 1. karaktere marad (egyetlen karakter). ezt sem vágom,hogy ez miért így van ...
szóval sok a megválaszolatlan kérdés...
várom az ötleteket...
|
|
|
|
hát azt kéne ja
szerintem a hatókörrel lehet valami..de igy látaltanba csak tipp
|
|
|
|
pfff... 
bemásolhatnád ide a progi/függvény kódját, ha nem túl hosszú....
|
|
|
|
ha csak ennyit íratok ki:
Kód: cout << "parameter: " << endl;
akkor meg egy végtelen ciklus indul el, ami folyton a fenti sort írja ki
ezt már végképp nem értem
|
|
|
|
én ezt azért nem értem, mert mi történik másként, ha kiíratod azt a 2 változót??
még csak az értéküket sem módosítod, csak kiolvasod... 
nem próbáltál még ki apróbb módosításokat?
pl hogy nem a változókat iratod ki, hanem csak egy szöveget, vagy csak az egyik változót, stb.
talán a progi viselkedéséből lehet következtetni a hiba okára.
|
|
|
|
Idézet
gaborlabor :
Visual Studio-ban Ctrl+Shift+B kombóval tudsz build-elni.
jaja, ugyanaz (nálam!), mint az F7
|
|
|
|
Idézet
Asylum :
ja várj ez ismerös lehet h má nekemis volt..hmm és ha egy space t rax a // után?
amugy azért mert ha C-ben irod akkor ott nincs //
nem, sajnos a // után rakott space sem oldja meg a problémát, sőt ha kitörlöm az egész sort, akkor is kifagy a progi, csak ha benne marad, akkor okés.
mégegyszer az emlitett sor:
Kód: cout << "parameter: " << parameter << ", es pId: " << pId << endl;
char* típusú a "parameter" es a pId változó is...
|
|
|
|
Visual Studio-ban Ctrl+Shift+B kombóval tudsz build-elni.
Debug módban a fordító még pakol a progidba extra kódot, hogy könnyebb legyen debuggolni, ezért kicsit lassabb is mint a release fordítás. És vannak apróbb különbségek, pl ha jól tudom, debug módban alapból kinullázza azokat a változókat is, amiket nem kéne, stb.
|
|
|
|
ja várj ez ismerös lehet h má nekemis volt..hmm és ha egy space t rax a // után?
amugy azért mert ha C-ben irod akkor ott nincs //
|
|
|
|
ööö, asylum hozzászólásához annyit, hogy visual studio 2005-ben nekem a ctrl - F11 semmit se csinál, gaborlabortól pedig kérdezem, hogy mi a kettő közötti különbség, mert visual studio alatt nyomok egy F7-et, és az gond nélkül build-el.
|
|
|
|
Ez számomra is érthetetlen.
Debug és Release fordítás ugyanazt csinálja?
|
|
|
|
ujraforditás
ctrl f11 (dev-c++)
|
|
|
|
sziasztok.
magyarázza el nekem valaki lécci, hogy a "cout << "-al kezdődő soraim kikommentelése, illetve progiban hagyása miért van hatással a futo programomra.
annyit csinálok a cout-ban, hogy kiíratom 1-2 változóm (char*) tartalmát
Kód: cout << "parameter: " << parameter << ", es pId: " << pId << endl;
ha benne hagyom a progiban a sort, akkor müxik (persze kiírja a sort is), ha kikommentezem (//cout), akkor meg kifagy.
ez számomra érthetetlen
|
|
|
|
Visszatértem a sima std::string-re, úgy tűnik, a magyar betűk mennek ezzel is...
|
|
|
Legutóbb frissített
project:
Visual Novel Engine
Friss kép a galériából:
|
Frissebbek | Korábbi postok 
