Class in a DLL

[Colin B Maharaj]

Hi all I have huge app in v3 of BCB and need to "move" it to v6, BUT, I
also want to have most of the functionality of the old app declared in a
class so I can instantiate it multiple times. AND....

I am thinking of doing this via a DLL.
Basically I have separated my app into the visual part and the
non-visual part and I am moving all the non-visual code (core
functionallity) to v6 BCB.

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.

AND I am then going to write a websnap interface to control the app and
edit tables and non-tabular data (ini settings) that are in this DLL.

Does this sound too complicated?
Any advice would be nice?
Thanks....

[Andrue Cope [TeamB]]

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

[Colin B Maharaj]

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.

[Andrue Cope [TeamB]]

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.