Sziasztok.
Az az én nyűgöm, hogy írtam egy dll-t egy delphi programohoz Borland C++ 2006-ban. Igen ám de a másik program delphi 5-ben íródott (1999-es nyelv szóval.....) És még az a baj hogy egy csak a borlandék által készült Tbitmapot kellene hogy kapjon a függvényem. de akkora a verziókülömbség, a két nyelv között, hogy a kód hibával elszáll, miszerint végzetes kivétel xyz.bpl modulból, és ad egy hexa-memóriacímet, amivel sokra nem megyek. Szereztem egy Borland C++ 5.02-es fordítót, de azzal az általam írt cpp nem fordul. Bármilyen kódot, bármit odaadok, hogy elemezne tudjuk. Előre is mindent köszönök.
Ja szóval le kellene gyártanom ezel az ősi fordítóval egy olyan dll-t ami kompatibilis az 5-ös delphi Tbitmapjával.
- 1204 megtekintés
Hozzászólások
Nemrég szaladt itt valaki hasaonló gondal - keress rá.
Amennyire emléksztem a Pascal vs. C++ meghívásokkal volt a baj.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Az is én voltam :).
- A hozzászóláshoz be kell jelentkezni
Nem lehet az ősrégi alkalmazást portolni valami értelemes platformra? Az ilyen öszetákolt dolgokkal az a baj, hogy egyszer még csak összerakod, de aztán az egészet karban kell tartani meg tovább támogatni még évekig - feltéve hogy sikeres volt a projekt. Akkor aztán ami most régi az már _nagyon_ régi lesz.
Amúgy meg megpróbálhatnál Delphiben olyan ojjektumot létrehozni amit C-ben rendesen el tudsz érni. Esetleg külön processzbe is tehetnéd a két alkalmazást és valami IPC-vel kommunikálhatnának (pipe, shared memory vagy TCP).
Nem elég hangsúlyozni az interfészek jól definiáltságának fontosságát.
Mondjuk te mindig azzal jössz, hogy a te feladataidhoz nem elég az ördög processzora sem, úgyhogy lehet hogy nem fér bele a processzoridőbe egy konverzió vagy pláne egy IPC...
- A hozzászóláshoz be kell jelentkezni
Most azon agyalok, hogy amit összepakoltam C-ben azt átvésni Delphibe, de azt vettem észre, hogy a delphi. kb fele sebességet produkál, mint a cpp matematikában. Az a baj hogy ilyen bonyolult kommunikációval töbet bukok, mint ha átvéssük delphibe.
- A hozzászóláshoz be kell jelentkezni
Biztos hogy késő lenne újragondolni és rendesen megtervezni az alkalmazást?
- A hozzászóláshoz be kell jelentkezni
Meg van az elég rendesen tervezve, az a baj, hogy képekkel kell dolgozni, és a maximum sebességet akartam megoldani úgy hogy a kollegámnak a lehető legkevesebbet kelljen beavatkozni a programjába. Ha a függvényhívás során átjönne a kép akkor semmi baj nem lenne kb 100-sor kellen +ban a delphi kódba. Te hogy oldanád meg? Leírom a probélmát. Van egy kép amit elmezni kell, csak sokat kell rajta számolni, ezért azt gondoltam hogy cak pakk a képet átadja a dll-nek ott elvan és visszad egy kis tömböt amiben pár adat van. A képből a modul az RGB-értékeket használja.
Ui: Mint ahogy lentebb írtam. Ha nem Tbitmapot ad át, hanem egy 640*480-as tömböt, akkor ez nem okozhat fennakadást a modulban mert azt már nem használja. Szerinted ez mennyire jó ötlet?
- A hozzászóláshoz be kell jelentkezni
Egyébként minek a Delphi ha a C jobb?
Nem lehet hogy ott valami más aritmetikát használtál? Egyébként ha a sebesség kritikus akkor inkáb Intel compilert kell használni, az a bajnok ebben.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Pont ezen gondolkodom, hogy csak egy tömböt adjon át ami meg van tömva az adatokal. Akkor nincs Tbitmap átadás. Akkor meg már tök mindegy milyen C-vel fordítok.
- A hozzászóláshoz be kell jelentkezni