🚀 go-pugleaf

Colin B Maharaj wrote:

> Now, is there some way that I can then call this code , which I want
> to put in a DLL and instantiate multiple instances of the classes in
> the DLL.

Yes but importing/exporting object instances is proprietary and
language specific. You will not find it easy to import a Borland object
from a VC application. Should you or someone else ever need to use
those classes from a different language it will probably be nigh-on
impossible.

Generally accepted wisdom is to provide handle based access to classes
across DLL boundaries. The handle can either be a subscript into an
array of objects or the pointer to the object instance casted to 'void
*'.

Example 1:Easier to spot invalid handles.
// DLL code
int DLL_Exported_Wibbler( int objectHandle )
{
  return MyObjectList[ objectHandle ]->Wibble();
}

Example 2:Slightly faster than using an array/vector
// DLL code
int DLL_Exported_Wibbler( void * objectHandle )
{
  return reinterpret_cast<TMyObject *>( objectHandle )->Wibble();
}

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

Hey Andrue thanks for the info



Andrue Cope [TeamB] wrote:

> Yes but importing/exporting object instances is proprietary and
> language specific. You will not find it easy to import a Borland object
> from a VC application. Should you or someone else ever need to use
> those classes from a different language it will probably be nigh-on
> impossible.

Actually I was thinking of separating the visual part of the application 
from the functional part. That way if I fix a bug I can tell customers 
to upload the DLL with the core fuctionality  and vice-versa with the 
visual part. Everything will be in C++ Builder.

Colin B Maharaj wrote:

> Actually I was thinking of separating the visual part of the
> application from the functional part.

Yes, that's what I thought. It's a very good idea but doesn't really
affect the validity of my reply from what I can see. Perhaps I
misunderstood your post. The core of your question seemed to be that
you wanted to instantiate objects inside your DLL and use those objects
from inside the EXE so I addressed the main issue arising from that.

> Everything will be in C++ Builder.

In that case you can export and import class instances across the DLL
boundary. I still don't think it's a good idea, however. My concern is
that DLLs have the potential to be servers for anyone and everyone. By
exporting classes you are severely limiting them and one day you might
run afoul of that. This is especially true if your DLL grows beyond a
useful collection of functions and becomes a run time library.
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html