játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5484
FZoli:    4893
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2526

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2196
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] > 90 < [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [142]
ibax - Tag | 154 hsz       Online status #83365   2008.03.17 12:52 GMT+1 óra  
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?
   
MaximumViolence - Törzstag | 1020 hsz       Online status #83150   2008.03.12 12:49 GMT+1 óra  
milyen fordítót használsz? én gyakran elnézem azt,h nem adom hozzá a .cpp fájlt a projekthez ...
Ez egy reszeg post...

   
Asylum - Törzstag | 5484 hsz       Online status #83142   2008.03.12 09:22 GMT+1 óra  
hát talán nem 200 soros kóddal kéne tesztelni...

Kód:
#include "Alma.h"

int main(int argc, char* argv[])
{
    Alma alma;
    alma.foo();

    system("pause");
    return 0;
}


ilyesmivel teszteld vagy nemtom mi van a headerben
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83140   2008.03.12 09:16 GMT+1 óra  
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 )
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #83138   2008.03.12 09:13 GMT+1 óra  
akkor mit fordit egyáltalán?
main fv van? meghivsz valmit a headerböl?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83135   2008.03.12 09:11 GMT+1 óra  
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
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #83126   2008.03.12 09:02 GMT+1 óra  
hö mi? na mégegyszer
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83125   2008.03.12 09:00 GMT+1 óra  
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
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #83117   2008.03.12 08:52 GMT+1 óra  
hát arratippelek hogy az #ifndef # define párost irtad el
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83114   2008.03.12 08:48 GMT+1 óra  
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
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #83113   2008.03.12 08:47 GMT+1 óra  
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/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83108   2008.03.12 08:41 GMT+1 óra  
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
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #83107   2008.03.12 08:36 GMT+1 óra  
gondoltam még nem mondom ki...de valószinüleg a többiek is osztanák a véleményem.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83105   2008.03.12 08:32 GMT+1 óra  
Idézet
Asylum :


?
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #83100   2008.03.12 08:19 GMT+1 óra  
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #83095   2008.03.12 07:46 GMT+1 óra  
Tehát eddig, nem tudtatok rajtam segíteni..
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #83094   2008.03.12 07:46 GMT+1 óra  
1, MSVS-t használok.
2, Porjektben programozok
3, be ágyazok minden h-t, ami kell
Ami tönkremehet, az tönkre is megy!!!
   
Orphy - Törzstag | 1893 hsz       Online status #83073   2008.03.12 05:29 GMT+1 óra  
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?
   
Asylum - Törzstag | 5484 hsz       Online status #83044   2008.03.11 11:40 GMT+1 óra  
megoldodott

Ezt a hozzászólást Asylum módosította (2008.03.11 13:01 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
WToma - Szerkesztő | 635 hsz       Online status #83042   2008.03.11 09:33 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.
Ez nem bug, hanem feature!
http://sohivatal.uw.hu
   
AmidaBucu - Tag | 281 hsz       Online status #83041   2008.03.11 09:24 GMT+1 óra  
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!!!
   
Orphy - Törzstag | 1893 hsz       Online status #83039   2008.03.11 09:03 GMT+1 óra  
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ő.
   
AmidaBucu - Tag | 281 hsz       Online status #83038   2008.03.11 08:54 GMT+1 óra  
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!!!
   
AmidaBucu - Tag | 281 hsz       Online status #83037   2008.03.11 08:53 GMT+1 óra  
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!!!
   
Kristf - Törzstag | 125 hsz       Online status #83032   2008.03.11 07:31 GMT+1 óra  
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.

   
AmidaBucu - Tag | 281 hsz       Online status #83028   2008.03.11 06:49 GMT+1 óra  
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!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82794   2008.03.06 11:27 GMT+1 óra  
THX
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5484 hsz       Online status #82792   2008.03.06 10:15 GMT+1 óra  
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, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82791   2008.03.06 10:10 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!!!
   
Asylum - Törzstag | 5484 hsz       Online status #82789   2008.03.06 09:39 GMT+1 óra  
öö 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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82787   2008.03.06 07:54 GMT+1 óra  
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!!!
   
Orphy - Törzstag | 1893 hsz       Online status #82784   2008.03.06 07:32 GMT+1 óra  
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)
   
AmidaBucu - Tag | 281 hsz       Online status #82783   2008.03.06 07:20 GMT+1 óra  
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!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82781   2008.03.06 07:17 GMT+1 óra  
Jajajaja, én is igy csináltam
Ami tönkremehet, az tönkre is megy!!!
   
Orphy - Törzstag | 1893 hsz       Online status #82753   2008.03.05 14:07 GMT+1 óra  
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
   
Asylum - Törzstag | 5484 hsz       Online status #82745   2008.03.05 11:53 GMT+1 óra  
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.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82735   2008.03.05 09:02 GMT+1 óra  
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!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82734   2008.03.05 08:59 GMT+1 óra  
Mondom hogy bocsi! Csak sulivolt, azé vok ilyen.
Ami tönkremehet, az tönkre is megy!!!
   
beast - Törzstag | 1241 hsz       Online status #82733   2008.03.05 08:24 GMT+1 óra  
Azt hiszem, ezek után innen ne várj segitséget...

   
AmidaBucu - Tag | 281 hsz       Online status #82732   2008.03.05 08:14 GMT+1 óra  
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!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82728   2008.03.05 07:58 GMT+1 óra  
[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!!!
   
Asylum - Törzstag | 5484 hsz       Online status #82723   2008.03.05 07:08 GMT+1 óra  
van értelme, 4 karakternek
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82722   2008.03.05 06:58 GMT+1 óra  
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();
   
Asylum - Törzstag | 5484 hsz       Online status #82721   2008.03.05 06:56 GMT+1 óra  
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, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82720   2008.03.05 06:30 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!!!
   
Asylum - Törzstag | 5484 hsz       Online status #82589   2008.03.02 09:30 GMT+1 óra  
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
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82584   2008.03.02 07:19 GMT+1 óra  
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!!!
   
Orphy - Törzstag | 1893 hsz       Online status #82583   2008.03.02 06:58 GMT+1 óra  
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...
   
Orphy - Törzstag | 1893 hsz       Online status #82577   2008.03.02 05:00 GMT+1 óra  
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...
   
Orphy - Törzstag | 1893 hsz       Online status #82570   2008.03.02 02:48 GMT+1 óra  
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?
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] > 90 < [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [142]