Recent

Author Topic: External libraries with just object class definitions..  (Read 1267 times)

JernejL

  • Jr. Member
  • **
  • Posts: 90
External libraries with just object class definitions..
« on: July 05, 2018, 01:03:25 pm »
I've got a project in which id like to have people compile their own add-on libraries.
 
Those should somehow be able to interact with objects / classes in main application without actually having any implementation of the classes methods and functions.
 
Is it possible to somehow use RTL / rtti to do something like this in freepascal? How would the external dll allocate my objects and work with them, call methods without knowing their implementations?
 
These libraries would load once during startup and stay in memory (no unloading is needed)
 

taazz

  • Hero Member
  • *****
  • Posts: 5365
Re: External libraries with just object class definitions..
« Reply #1 on: July 05, 2018, 01:22:46 pm »
one word interfaces. You define you interfaces of all the components/controls you want to access from the dll or the dll creates for you and pass the interfaces between dll and exe.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

JernejL

  • Jr. Member
  • **
  • Posts: 90
Re: External libraries with just object class definitions..
« Reply #2 on: July 05, 2018, 01:28:18 pm »
I'm not totally sure how this would work - i am very unfamiliar with interfaces, but is this something to do with OLE objects?
Also the needed classes would be implemented only in main application, dll / .so library will just need a way to create and manipulate those classes.
 

taazz

  • Hero Member
  • *****
  • Posts: 5365
Re: External libraries with just object class definitions..
« Reply #3 on: July 05, 2018, 02:24:20 pm »
I'm not totally sure how this would work - i am very unfamiliar with interfaces, but is this something to do with OLE objects?
Interfaces is something like an abstract class as long as you are careful not to pass managed types between boundaries of dll and exe you are safe to use abstract classes. The only drawback is that everything has to be build with fpc you can't use an abstract class created in C/C++ (I'm cleverly avoiding managed languages,java C# etc) not easily that is. With interfaces you have that luxury and if you use COM interfaces you have a bit wider range of data types you can safely pass between dll and exe (dynamic arrays, widestrings etc) if you shy away from com then same rules apply no managed types between boundaries.

Also the needed classes would be implemented only in main application, dll / .so library will just need a way to create and manipulate those classes.
the needed classes will be implemented both in dll and main application. The implementor has the responsibility to create and destroy them. You should never create class a in the dll and destroy from the exe. If for any reason you need the dll to create classes and fill them with data then make sure that some sort of factory is exported from the main application that will create those classes for the dll.
 to give some context to the above information. you are not allowed to pass1) strings2) dynamic arrays of any data typeor any other managed data type from the dll to the exe and vice verse you pass a pointer with the data (lets talk from dll to exe) the exe copy's the data in to its own memory and asks the dll to release the memory.anything created in the dll must be released from the dll and the dll only that is mandatory.a factory can be a simple abstract class that has a method (called add/append/inset etc) that returns a specifc class take a look the add method of the TCollection  class in the RTL you can say that it is a small factory that creates only a single type of classes.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

 

TinyPortal © 2005-2018