dll-ek parbeszede 2.
Info.StaTOR
Még március közepén írtam, de nem jött válasz (:-)
---------------------------------------------------------------------------------------------------
Van egy felhasználói interface-em, ez természetesen egy exe. Ez meghív
egy dll-t, ami a "piszkos" munkát végzi.
A kérdésem, hogyha még egy dll lenne, akkor a két dll-em tudna-e
egymással közvetlenül kommunikálni, vagy csak a felhasználói
interface-en keresztül? (Ami nekem nem lenne jó!)
(XP, BCB2006)
---------------------------------------------------------------------------------------------------
Mostanra nagyon aktuális lett a dolog.
Ott tartok, hogy a project groupba betettem a 2. dll projectjét.
Simán le tudom fordítani, létrejönnek a obj, dll, lib, exe file-ok. A méretük
is jónak látszik, a lib tartalma is.
Az új dll project lib-jét az exe és a másik dll-be is beletettem,
természetesen a header file is be van includálva mindkét helyre.
Az eredmény: sem a másik dll-ből, sem az exe-ből nem látom az új dll
osztályát.
A két dll-nek különben ugyan az a forrása, ugyanazok az osztályfüggvények,
csak mások a fordítási kapcsolók, meg természetesen a dll, lib neve.
Nincs valami tippetek, hogy milyen - elemi - dolgot szúrtam el? Hátha ezt már
megszívta valaki és kisegít... (:-)
A válaszokat előre is köszönöm.
Cap
Nagy Zoltán
Info.StaTOR wrote:
> Még március közepén írtam, de nem jött válasz (:-)
Pedig elvileg 100 körüli a taglétszám. :)
> A kérdésem, hogyha még egy dll lenne, akkor a két dll-em tudna-e
> egymással közvetlenül kommunikálni, vagy csak a felhasználói
> interface-en keresztül? (Ami nekem nem lenne jó!)
Igen természetesen tudnak, hiszen azonos címtartományban vannak.
> Az új dll project lib-jét az exe és a másik dll-be is beletettem,
> természetesen a header file is be van includálva mindkét helyre.
>
> Az eredmény: sem a másik dll-ből, sem az exe-ből nem látom az új dll
> osztályát.
Azt tudnod kell, hogy a DLL és a C++ azok nem barátok. Elvileg ettől
még, statikusan szerkesztve a DLL-t, működhet de a várható problémákra a
DLL projekt fejlécében lévő kommentben is felhívják a figyelmet.
Ha nem akarsz kézzel írt C wrapperrel vacakolni, és mindenáron C++
osztályokat akarsz közvetlenül importálni DLL-ből, akkor a Borlandnak
elvileg lett erre egy speciális megoldása, amit úgy hív, hogy "Package".
Ez nem csak a komponensekhez van kitalálva. Csomagot létrehozhatsz Te is
a saját kódoddal a saját alkalmazásodhoz, a BPL fájl is DLL, csak kicsit
más mint a hagyományos DLL, annyiban más, hogy ott már elvileg barát a
C++ és a DLL. Bár a hatos Builderben azért ezzel is voltak gondok, dehát
nem is Builder a Builder ha nincs benne verziónként több ezer hiba,
amiből legalább ezret soha nem javítanak ki a sokadik Update után sem... :)
Z.
Info.StaTOR
Te vagy az egyik, akire lehet mindig számítani (:-).
> Pedig elvileg 100 körüli a taglétszám. :)
Úgy látszik a többiek már annyira kiokosodtak, hogy nincsenek problémáik (:-)
> Azt tudnod kell, hogy a DLL és a C++ azok nem barátok. Elvileg ettől még,
> statikusan szerkesztve a DLL-t, működhet de a várható problémákra a DLL
> projekt fejlécében lévő kommentben is felhívják a figyelmet.
Na itt kezdődnek a gondok. A kommentet nem értem, nem tudok annyira angolul.
Nem tudom, mit értsek az alatt, hogy nem barátok. Mondjuk azt jelenti, hogy
bizonyos dolgok nem mennek, vagy nem korrektül mennek.
Erre azt mondom, hogy emberemlékezet óta használom a CBuidert, azzal
fejlesztem, fordítom a dll-t és az exe-t is. Az is igaz, hogy ugyan
maximálisan kihasználok szinte mindent, amit osztályokkal csinálni lehet, a
többi C++ lehetőséget nem használom, hiszen eredetileg Turbó C-ben, majd
Borland C-ben kezdtem a fejlesztést DOS alatt, majd áttértem a CBuilderrel a
Windows-ra való fejlesztéssel.
Működik is rendesen, most egy második dll-re volt szükségem, ezzel volt gond,
de már működik minden.
> statikusan szerkesztve a DLL
Meg nem tudnám mondani, hogy úgy van-e. Az Options/Linker/Linking/Use dynamic
RTL nincs kipipálva, ha erre gondolsz.
A Package-val, mint komponens készítés móddal - szintén a Ti tanácsotokra -
már próbálkoztam, de feladtam. Pontosan nem emlékszem mi volt, de talán az,
hogy rendkívül nehézkessé tette a fejlesztést, hiszen éppen a komponenst
fejlesztettem. Minden próba egy tortúra volt.
Ha elakadok majd más okból, akkor - tanácsodra - megpróbálom a dll helyett a
bpl-t.
Még egyszer kösz!
Cap
Nagy Zoltán
Info.StaTOR wrote:
> Na itt kezdődnek a gondok. A kommentet nem értem, nem tudok annyira angolul.
Ez a memóriakezeléssel kapcsolatos problémákról szól, ami a szöveggel
ellentétben valójában nem csak C++ specifikus.
> Nem tudom, mit értsek az alatt, hogy nem barátok. Mondjuk azt jelenti, hogy
> bizonyos dolgok nem mennek, vagy nem korrektül mennek.
Nem akarok túlzottan belemerülni, ha nem ismered a C++ és a COFF
lelkivilágát belülről, akkor is a neten minden infót meg lehet találni a
témában.
>> statikusan szerkesztve a DLL
> Meg nem tudnám mondani, hogy úgy van-e. Az Options/Linker/Linking/Use dynamic
> RTL nincs kipipálva, ha erre gondolsz.
Ez az opció egy másik történet, de ez a Te esetedben legyen bekapcsolva
az EXE és a DLL projektekben is. Akkor van statikusan szerkesztve ha a
DLL vagy EXE import táblában szerepel bejegyzés a hivatkozott DLL
exportjára (lásd.
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx).
A Te esetedben ez most biztosan így van.
> A Package-val, mint komponens készítés móddal - szintén a Ti tanácsotokra -
> már próbálkoztam, de feladtam. Pontosan nem emlékszem mi volt, de talán az,
> hogy rendkívül nehézkessé tette a fejlesztést, hiszen éppen a komponenst
> fejlesztettem. Minden próba egy tortúra volt.
Mint ahogy írtam, a Package és a komponens két különböző dolog. Nem is
tudom, hogy fogalmazzam, próbálom egyszerűen, szóval a komponenseknek
kell a package, de fordítva nem, a package köszöni jól van komponensek
nélkül is, azaz másra is használható. Már amikor működik. :)
> Ha elakadok majd más okból, akkor - tanácsodra - megpróbálom a dll helyett a
> bpl-t.
Előbb azért lehet, hogy érdemes utánaolvasni ennek a DLL dolognak úgy
általában. :)
http://msdn.microsoft.com/en-us/library/1ez7dh12(VS.80).aspx
Z.
Nagy Zoltán
Wow. Biztos nagyon olcsón adták az eredeti árhoz képest. :))) Lehet,
hogy 5 éven belül már valami értelmeset össze is hoznak majd, valami
olyat amit már mostanra kellett volna.
"Today, we are very pleased to announce that Embarcadero Technologies
has signed a definitive agreement to acquire CodeGearTM from Borland®
Software Corporation. The combined company will operate as a private
company with over $100MM in annual revenue and more than 500 employees
worldwide. We expect this transaction to close by June 30, 2008. This is
an important milestone in the history of software and database development."
emel
> http://www.embarcadero.com/
>
>
>
"platform-independent software provider of database and application
development tools"
Csak nem arra jöttek rá, ami évekkel ezelőtt felmerült, hogy a
platformfügetlen (hordozható forráskódú) programfejlesztésben van fantázia.
Egy terület, amivel külön pályát nyithattak volna és szűz piacot nyernek.
Nem véletlen annó a Kylix vonal, de amit abból csináltak az egy horror.
Most meg már lehet hogy késő... jáva + mono...
eMeL
Nagy Zoltán
emel wrote:
> "platform-independent software provider of database and application
> development tools"
> Egy terület, amivel külön pályát nyithattak volna és szűz piacot nyernek.
Igen, szerintem is.
> Nem véletlen annó a Kylix vonal, de amit abból csináltak az egy horror.
Úgy egészben mindennel amit csináltak az egy horror, a Kylix csak a
jéghegy csúcsa, bár az egy kétségtelenül látványos szívatás volt.
> Most meg már lehet hogy késő... jáva + mono...
A bizonyos új cég jelenlegi termékei a képernyőfotók alapján Win32
Delphi és Java (Eclipse). Gondolom ez utóbbira értették az, hogy kereszt
platformos.
Ha lesz egy kis szerencsénk, akkor az egész CodeGear fejlesztőbázist
ráuszítják arra, hogy a jelenlegi Win32 Delphi és Java cuccaikat írják
át .NET-re és ezzel végleg vége is lenne a CodeGear-nek mint a botnak.
:D Az eddigi döntéseikhez képest ez még nem is a legrosszabb lenne. :D
Komolyabbra fordítva, ha az új cég nem akarja majd elhagyni a Java-t,
akkor, nagyjából az történhet, hogy bazi sok adatkezeléssel kapcsolatos
innovációt akar majd beletolni a Delphi(?)-be az új cég. Kérdés, hogy
ezt a sok újdonságot implementálják majd .NET és VCL-ben is? Esetleg
csak Java-ban? Mert előbbi az dupla meló, utóbbinak nincs értelme mert
hosszú távon úgyis kihal PC-n, és csak elvinné a kapacitást a többiről,
ha meg mindháromba akkor az tripla meló. És lenne mit fejleszteniük
amúgy enélkül is bőven,a korábbi évek rossz döntései miatt.
Egyedül akkor lehet esélye a CodeGear-nek, ha az új cég saját fejlesztői
tolnák az "innovációt" a Delphi-be, (alkérdés, ők viszont .NET-et nem
fejlesztenek a .NET libeket ki fogja majd megcsinálni?), de ennek meg mi
értelme lenne, mivel plusz pénzt azért aligha kérhetnek. Esetleg még
olyan jövőképet látok, hogy szétszakad a termékvonal és lesz a mostani
alap (BDE+IBX) Delphi, meg lesz majd "Embarcadero" edition dupla
pénzért, amiben lesz majd minden csoda(?). De ez utóbbi csak akkor jöhet
létre ha nem a CodeGear fejlesztők idejét viszi el... Végülis mostantól
a Delphi sorsa ezen múlik.
Z.
Ricsóvári László
Toth Csaba
Töttö Gábor
From: bcb...@googlegroups.com [mailto:bcb...@googlegroups.com] On Behalf Of Toth Csaba
Sent: Monday, February 08, 2010 06:07
To: bcb...@googlegroups.com
Subject: [bcbhun] TComPort
Levelezési lista címe: bcb...@googlegroups.com
Leiratkozás, levél küldéssel ide: bcbhun-un...@googlegroups.com
További információ: http://groups.google.com/group/bcbhun