Board index » cppbuilder » how can I share a dynamic list of objects in a dll

how can I share a dynamic list of objects in a dll


2006-01-03 06:18:58 PM
cppbuilder93
Hi again,
I've tested successfully the way I share a simple data (=an integer)
in a dll for several applications that use the same dll.
this example works fine :
bdn.borland.com/article/0,1410,20008,00.html
I'd like to know how can I share a dynamic list of objects in a dll
(I'm using BCB 6.0 Pro)
class TMyObject
{
protected:
long fCodeId;
double fData1;
char fData2;
long fData3;
double fData4;
double fData5;
public:
TMyObject ( long, double, char, long, double, double);
long GetCodeId () const { return fCodeId;}
double GetData1 () const { return fData1;}
char GetData2 () const { return fData2;}
long GetData3 () const { return fData3;}
double GetData4 () const { return fData4;}
double GetData5 () const { return fData5;}
};
typedef std::vector <TMyObject*>V_MyObject_LST;
typedef std::vector <TMyObject*>::iterator V_MyObject_Iterator;
is it possible to share a dynamic list (size between 5000000 and 8000000)
of these objects in a dll for 3 .exe that need same datas ?
actually each executed process takes about 500Mb in the task manager.
thanx a million for any response.
 
 

Re:how can I share a dynamic list of objects in a dll

David L wrote:
Quote
typedef std::vector <TMyObject*>V_MyObject_LST;
typedef std::vector <TMyObject*>::iterator V_MyObject_Iterator;

is it possible to share a dynamic list (size between 5000000 and
8000000) of these objects in a dll for 3 .exe that need same datas ?
I'd be a little loathe to do that. Such data types are language
specific and even compiler specific. Accessing them through shared
memory would pretty much rely on the executable code of each DLL/client
being generated by the same compiler. I also imagine it would put a
horrible burden on you and other developers to locate and manipulate
the data correctly.
One the of the main benefits of DLLs is that they can be language and
compiler agnostic. As soon as a DLL exports (explicity through the API
or implictly through shared memory) anything beyond simple types that
benefit is lost. In the case of shared memory I think you are also
relying on the clients to understand and respect the layout of complex
structurs in memory. It's bad enough having to do that for yourself but
expecting/trusting other people to do it scares me :)
Unless performance is absolutely, 100% critical I would always far
rather use access functions. By that I mean you export iteration
functions like this:
// DLL code
int Object_ListBegin()
{
return 0;
}
int Object_ListEnd()
{
return OBJECTLIST_END_MARKER;
}
void Object_ListIncrement( int * ObjectHandle )
{
if( ( *ObjectHandle!=Object_ListEnd() )&&
( *ObjectHandle+1<V_MyObject_LST.size() ) )
++( *ObjectHandle );
else
*ObjectHandle=ObjectListEnd();
}
// Example method call:
double Object_GetData1( int Handle )
{
return V_MyObject_Lst[ Handle ]->GetData1();
}
Of course you'd probably want to add more validation for the above code
but I hope it conveys the idea.
BTW:Are you sure you want to populate your std::vector with /pointers/
to objects? It is usually better to populate the std::vector with
object instances so that the std::vector can take full ownership and
save you having to worry about correct allocation/deallocation. The
example class you've posted here will store quite nicely in a
std::vector. Of course not all classes will but it's always possible to
create a copy ctor and assignment operators. The additional work for
such classes is usually outwheighed by the advantage of not having to
worry about ownership semantics.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:how can I share a dynamic list of objects in a dll

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
One the of the main benefits of DLLs is that they can be language and
compiler agnostic. As soon as a DLL exports (explicity through the API
or implictly through shared memory) anything beyond simple types that
benefit is lost.
I'd say that that would be when to make it a COM server. Then you can
have arbitrarily complicated types, with multiple language support.
COM may not be the most elegant possible solution, but at least it's got
defined rules, and it usually works quite well. It's just a pain coding
it up in the first place (says he who has just created a 48K type
library with several dozen interfaces and who now needs to actually
write some code to go behind it).
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

{smallsort}

Re:how can I share a dynamic list of objects in a dll

Alan Bellingham wrote:
Quote
I'd say that that would be when to make it a COM server. Then you can
have arbitrarily complicated types, with multiple language support.

Good point, actually.
Quote
COM may not be the most elegant possible solution, but at least it's
got defined rules, and it usually works quite well. It's just a pain
coding it up in the first place (says he who has just created a 48K
type library with several dozen interfaces and who now needs to
actually write some code to go behind it).
Lol. We use COM but luckily the BCB wizards did everything for us and
they did it right. I /still/ have almost no idea how it works :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:how can I share a dynamic list of objects in a dll

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >écrivait news:43ba763b
$ XXXX@XXXXX.COM :
Quote
Alan Bellingham wrote:

>I'd say that that would be when to make it a COM server. Then you can
>have arbitrarily complicated types, with multiple language support.
>

Good point, actually.

>COM may not be the most elegant possible solution, but at least it's
>got defined rules, and it usually works quite well. It's just a pain
>coding it up in the first place (says he who has just created a 48K
>type library with several dozen interfaces and who now needs to
>actually write some code to go behind it).

Lol. We use COM but luckily the BCB wizards did everything for us and
they did it right. I /still/ have almost no idea how it works :)

thanx for your responses.
in fact, theses datas are available on a server (workstation1), I have 3
clients (.exe built under BCB6.0 Pro) on the same workstation2
(communication protocol = Ace Tao CORBA), each one loads locally about
400/500 Mo of datas, because these are "real-time" clients, they need to
access instantly to datas.
it works fine actually, but the workstation2 needs at least 2Go of RAM.
so I just wandered if sharing datas in memory into a common dll on
workstation2 would be a solution which needs only 1Go of RAM ???
 

Re:how can I share a dynamic list of objects in a dll

David L < XXXX@XXXXX.COM >wrote:
Quote
so I just wandered if sharing datas in memory into a common dll on
workstation2 would be a solution which needs only 1Go of RAM ???
Not if you're trying to share that data between processes, no. When two
executables both load the same DLL, the two copies of the DLL don't
access the same data segment.
(Life was different with Windows 3.)
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

Re:how can I share a dynamic list of objects in a dll

Alan Bellingham wrote:
Quote
Not if you're trying to share that data between processes, no. When
two executables both load the same DLL, the two copies of the DLL
don't access the same data segment.

(Life was different with Windows 3.)
And so much more 'interesting' :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:how can I share a dynamic list of objects in a dll

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote:
[sharing memory]
Quote
>(Life was different with Windows 3.)

And so much more 'interesting' :)
Ah, yes.
I was happily able to allocate memory in one application, pass it to
another application, and delete it there. You can imagine the fun I had
when finally porting that to the Windows NT family.
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK