AmidaBucu

---

Cpp be ejhetek bármien szintaktikai hibát nem foglalkozik vele.

---

msvs-ban programozol, és nem includoltad a fileokat, de a source file-okhoz azért hozzácsatoltad?

milyen fordítót használsz? én gyakran elnézem azt,h nem adom hozzá a .cpp fájlt a projekthez ...

hát talán nem 200 soros kóddal kéne tesztelni...



ilyesmivel teszteld vagy nemtom mi van a headerben

huhh, nem tudnám elmagyarázni, nem vagyok egy fogalmazó bajnok (gondolom ez feltûnt)
de elküldhetem mailben ( ámbár nem fog neked tecceni mer zöldfülû-kód )

akkor mit fordit egyáltalán?
main fv van? meghivsz valmit a headerböl?

nah, nincs semmi pragma,
ezér csak a kezdõ h-ban ágyazom be a varray.h-t
amit szintén inkludolok a varray.cpp-ben, de ott beletenyereltem a billentyûzetbe
és nem foglalkozik vele

hö mi? na mégegyszer

kitörlöm........


jahhh, igen linker hiba, nem tudja használni a tagfügvényeket, mert hiába definiáltam õket, mivel, ugye a cppben vannak

hát arratippelek hogy az #ifndef # define párost irtad el

thx, rákukkantok! Nem akarod megmondani mire utaltál elõzõ hozzászólásodban?

Jah,a 14es példában van amiben felosztottad úgy, de az a baj hogy én is ugy csináltam
Valami icurkapicurka doldot tuti ugy elírtam hogy még egy darabig nem fogok rájönni mi ahiba

van a honlapom amin vannak régebbi c++ kódok amiket még nem volt idöm emészthetö formába önteni..sajnos a komment angol. ha máshol nem nézel utána akkor ezeket fusd át az ilyen fájloka osztás a vége felé van vhol. szerk.: 14

http://people.inf.elte.hu/asylum/programming/C++/old/

mondjad nyugodtan, nem sértõdõk meg. Igazábol, tényleg nem értem mért csinálja
hiszen a cppben beágyaztam a h-t, a fõfiléban is a h-t, mégis nem akarja látni a cpp-t

gondoltam még nem mondom ki...de valószinüleg a többiek is osztanák a véleményem.

Idézet

---

Asylum :

---

?

Tehát eddig, nem tudtatok rajtam segíteni..

1, MSVS-t használok.
2, Porjektben programozok
3, be ágyazok minden h-t, ami kell

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?