|
|
Idézet AmidaBucu :
Eddig is a cppkben includoltam a h-at. De mégis előjön az, hogy a cpp, nem fordítja le a fordító.
Milyen fordítót használsz?
|
|
|
megoldodott
Ezt a hozzászólást Asylum módosította (2008.03.11 13:01 GMT+1 óra, ---)
|
|
|
AmidaBucu
Cpp be ejhetek bármien szintaktikai hibát nem foglalkozik vele.
Magyarul nem kerül oda a fordító -- ez azért van, mert nem állítottad be, hogy azt is fordítsa  Környezettől függ, hogy ezt hogy tudod beállítani, a legtöbb rendszerben érdemes a projekt funkciót használni, a projekt fordítása esetén az összes .cpp fordul.
|
|
|
Eddig is a cppkben includoltam a h-at. De mégis előjön az, hogy a cpp, nem fordítja le a fordító.
Ami tönkremehet, az tönkre is megy!!!
|
|
|
A .cpp file-okba be kell include-olni a hozzájuk tartozó .h-kat.
Ha ezek után is linker hibát kapsz, nézd meg, tényleg implementáltad-e az x függvényt.
A .h-kra ne akarj mélységet beállítani, akkor mélységben dolgozza fel a fordító, amekkorában szükséges. Nem érdemes korlátozni, esetleg valami kimaradna a progidból, aztán néznél, hogy mi van...
Másrészt, ha esetleg a
Kód: ////1.h
#include 2.h
///2.h
#include 1.h
esete forog fenn, és végtelen ciklusba kerülne a fordító, akkor is egy idő után abbahagyja, mert túlcsordul.
Használd a lentebb javasolt
Kód: #ifndef VALAMI_H
#define VALAMI_H
..ide jön amit a .h-ba írnál
#endif
sorokat, akkor ilyen nem fordulhat elő.
|
|
|
Ráadásul nem tom beállítani mien méjségig használja a h-kat
A varray.cppbe beirtam hogy #include"varray.h"
És hiába inkludolom be vhola varray.h-t, a cppvel nem foglalkozik.
Cpp be ejhetek bármien szintaktikai hibát nem foglalkozik vele.
Ezt a hozzászólást AmidaBucu módosította (2008.03.11 09:00 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
|
|
|
OKok. Most meg hiába inkludolom csak a h-kat, ugy csinál mintha nem léteznének cpp, és mikor egy osztály tagvügvényét használnám akkor bedob linker hibát
Ami tönkremehet, az tönkre is megy!!!
|
|
|
Idézet AmidaBucu :
Hi! Nem tudjátok, mit kell átállítani, ahoz hogy ne kössön belém a fordító, ha
Kód: /////1.h
#include"2.h"
#include"3.cpp"
/////2.h
class akarmi;
/////2.cpp
#include"2.h"
[akarmi fügvényeinek definiálása]
/////3.cpp
akarmi bigyo;
bigyo.fugveny();///ittt
A lényeg az hogy 3.cppben nem használja a fordító a 2.cpp cuccait és linker hibát dob;
Ha a 3.cppben inkludolom a 2.h,akkar, redefinition ba köt bele;
Ebben több hiba i van: először is nem szabad cpp-t include-olni. A másik, hogy érdemes a header fileokban az elejére beírni hogy
#ifndef VALAMI
#define VALAMI
//változók, fv-ek..
#endif
így max 1-szer tudod beilleszteni.
Ha változót több modulban szeretnéd használi, akkor headerben extern tipus valtozonev; -el adod meg, utána egy modulba beírod a definiciót is, hogy tipus valtozonev.
|
|
|
Hi! Nem tudjátok, mit kell átállítani, ahoz hogy ne kössön belém a fordító, ha
Kód: /////1.h
#include"2.h"
#include"3.cpp"
/////2.h
class akarmi;
/////2.cpp
#include"2.h"
[akarmi fügvényeinek definiálása]
/////3.cpp
akarmi bigyo;
bigyo.fugveny();///ittt
A lényeg az hogy 3.cppben nem használja a fordító a 2.cpp cuccait és linker hibát dob;
Ha a 3.cppben inkludolom a 2.h,akkar, redefinition ba köt bele;
Ami tönkremehet, az tönkre is megy!!!
|
|
|
THX
Ami tönkremehet, az tönkre is megy!!!
|
|
|
ha egy almám van és három körtét megeszek akkor hány barackom van?
Kód: LRESULT WINAPI WndProc(HWND hWnd, unsigned int msg, WPARAM wParam, LPARAM lParam);
typedef LRESULT (WINAPI *WindProc)(HWND hWnd, unsigned int msg, WPARAM wParam, LPARAM lParam);
WindProc wndproc = &WndProc;
Ezt a hozzászólást Asylum módosította (2008.03.06 10:23 GMT+1 óra, ---)
|
|
|
okok.
Jah, hadd kérdezzeg még vmit.
Kód: HRESULT WindowProc (HWND IN_hwnd, UINT IN_msg, WPARAM IN_wparam, LPARAM IN_lparam) fügvényre mutató pointer a Kód: HRESULT ( *WindowProc )(HWND IN_hwnd, UINT IN_msg, WPARAM IN_wparam, LPARAM IN_lparam)
akkor a
Kód: HRESULT CALLBACK WindowProc (HWND IN_hwnd, UINT IN_msg, WPARAM IN_wparam, LPARAM IN_lparam) fügvényre mutató pointer hogyan néz ki?
Ami tönkremehet, az tönkre is megy!!!
|
|
|
öö ezt igy lehet ?  arra gondolok, hogy tömböt meg lehet indexelni...erröl még nem tudtam...
probáld ki egy teszt ben hogy mivan akkor ha a tömböket adod át egyben SetVectorArray() -al meg stb vel.
|
|
|
Nem azt mondtam hogy az a fügvény rossz csak rossz pointert ad: Nem ugy értettem hogy alapból hanem, hogy aktuálisan. Jah azt is ésszerünek tartottam, hogy vmit én rontottam el. Azthittem ez kiveheteő.
Ezt a hozzászólást AmidaBucu módosította (2008.03.06 08:12 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
|
|
|
Idézet AmidaBucu :
Debugmodban is ránéztem, és arra jutottam hoghy ez a fügvény vmiért rosz pointer címet add.
(magyarul nem jutottam semmire )
Ebben azért nem lennék ennyire biztos a helyedben...
Bocs, de valószínűbb, hogy valamit valahol rosszul csinálsz. Elég sokan használják a DX-nek ezt a részét ahhoz, hogy feltűnjön, és kijavítsák, ha nem jó. Továbbá az ezt bemutató SDK-s sample is működik.
Én a helyedben ránéznék a többi pointerre is. (Bár nem tudom, pontosan mit értettél pointer hiba alatt)
Azt is érdemes lehet megnézni, hogy pontosan mikor lehet használni ezeket a függvényeket (pl effekt.begin(), effekt.end() között kell lennie, stb)
|
|
|
Kód: Effects[0].EEffect->BeginParameterBlock();
for(int i = 0; i < min(MPPL, Lights.size()); i++)
{
itoa(i, t,10);
Effects[0].EEffect->SetValue(SMerge(SMerge("LightDistance[", t),"]"),&distance[i], num);
Effects[0].EEffect->SetValue(SMerge(SMerge("LightPower[", t),"]"),&Lights[i].Power, num);
Effects[0].EEffect->SetValue(SMerge(SMerge("LightSpecular[", t),"]"),&Lights[i].Specular, num);
Effects[0].EEffect->SetValue(SMerge(SMerge("LightPos[", t),"]"),&Lights[i].xyz, num);
Effects[0].EEffect->SetValue(SMerge(SMerge("LightDiffuse[", t),"]"),&Lights[i].Diffuse, num);
}
D3DXHANDLE temphandle = Effects[0].EEffect->EndParameterBlock();
Debugmodban is ránéztem, és arra jutottam hoghy ez a fügvény vmiért rosz pointer címet add.
(magyarul nem jutottam semmire  )
Ami tönkremehet, az tönkre is megy!!!
|
|
|
Jajajaja, én is igy csináltam
Ami tönkremehet, az tönkre is megy!!!
|
|
|
Next, the sample creates a parameter block that contains the effect parameters. This is done by first calling BeginParameterBlock. This call indicates to the effect object that it should record all subsequent set calls, until EndParameterBlock is called. When EndParameterBlock is called, the effect returns a D3DXHANDLE for the parameter block. From this point on, when the parameter block is applied (with ApplyParameterBlock), the effect looks at the parameters inside the block, and sets the values for each of the parameters. The result is as if the application called this series of set methods. For instance, if an effect has two float4 parameters called Diffuse and Specular, a parameter block can be created to include these two parameters like this:
Kód: D3DXVECTOR4 vDiffuse;
D3DXVECTOR4
vSpecular;
D3DXHANDLE hBlock;
// Initialize vDiffuse and
vSpecular
pEffect->BeginParameterBlock();
pEffect->SetVector(
"Diffuse", &vDiffuse );
pEffect->SetVector( "Specular",
&vSpecular );
hBlock = pEffect->EndParameterBlock();
After this code is run, hBlock contains two parameters, Diffuse and Specular, and the recorded value of vDiffuse and vSpecular. Now, whenever the application does this:
// Apply the parameter
block
pEffect->ApplyParameterBlock(hBlock);
The result is equivalent to the following, assuming vDiffuse and vSpecular still have the correct values:
Kód: pEffect->SetVector( "Diffuse", &vDiffuse
);
pEffect->SetVector( "Specular", &vSpecular );
http://www.paradoxalpress.info/Docs/dx9_out/EffectParam_Sample.htm
|
|
|
hát ugye ez most egy karaktertömbre mutató pointert ad vissza, kérdés, hogy ezt hogyan probálod feldolgozni...nekem spec. nem világos, hogy mi mert msdn azt irja hogy a paraméterek állapotaira mutató pointert ad vissza
Returns a handle to the parameter state block.
|
|
|
Nah próbáltam ugy ahogy mondtátok:
Kód: D3DXHANDLE handle;
[...]
handle = Effects[0].EEffect->EndParameterBlock();
de ahogy ez a sor lefut Rosz pointer lesz a handle. Talán az endparameterblock és a beginparameterblock között valamit csunyán csináltam?
Ezt a hozzászólást AmidaBucu módosította (2008.03.05 10:54 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
|
|
|
Mondom hogy bocsi! Csak sulivolt, azé vok ilyen.
Ami tönkremehet, az tönkre is megy!!!
|
|
|
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)
|
|
|
Legújabb project:
Szókirakó 3
Legutóbb frissített project:
Szókirakó 3
Friss kép a galériából:
|