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

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ó.

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



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


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.

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

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


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;

THX

ha egy almám van és három körtét megeszek akkor hány barackom van?

okok.
Jah, hadd kérdezzeg még vmit.
fügvényre mutató pointer a
akkor a
fügvényre mutató pointer hogyan néz ki?

öö 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õ.

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)

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 )

Jajajaja, én is igy csináltam

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:



The result is equivalent to the following, assuming vDiffuse and vSpecular still have the correct values:



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:

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?

Mondom hogy bocsi! Csak sulivolt, azé vok ilyen.

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 )

[bunkó megjegyzés]

Tisztelet a kivételért. Bocsánat az offért. Köszönet a válaszokért.

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:

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?

Nah, valaki tudna segíteni az elõzõ kérdésemmel kapcsolatban? A pointer problémában?

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?

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


(az LPCSTR egy pointer típus, ha jól értem a google találatokat...)

Hi!
Pointer problémám lenne.
Van egy
pointerem;
Megvan cimezve rendesen, de amikor itt tarta program:

Tönkre megy a pointer. Próbálkoztam mindennel de nem tom megcsinálni.
Vmi ötlet hogy lehet?

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 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 -t lecseréltem -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)