Exporting and loading a class

Question

1.00/5 (1 vote)

See more:

I've been working on a scripting engine, something like Lua, for about 2 months, and now that it's done, I want to be able to distribute it in a DLL form. Because of the way it works, I have to export the whole class (TQScript).

And to add new functions, the user has to define a new class (that inherits from TQScript, like Lua-for-Delphi does), like this:

Delphi

type
  TMyScript = class(TQScript)
  published
    procedure MyNewFunction(Arg: TArgList);//TArgList is another class to hold arguments
                                           //and pass on the Result
  end;

Now the problem is that I do not want to open source it, just be able to export the class so that it can be loaded like you do a function:

Delphi

function FunctionName(Arg: Byte): Byte; external 'SomeName.DLL';

But how do you do this with classes?
BTW I'm using Delphi, don't know a thing about C++ (except for basics).

Posted 20-Dec-15 17:27pm

Nafees Hassan

Add a Solution

Comments

Sergey Alexandrovich Kryukov 21-Dec-15 0:31am

First of all, what is the user of your DLL? If this is another Delphi model, it's not a problem. But I feel you are talking about the use in projects written by a wide range of languages. Then it is still possible, but indirectly. Windows API used by Delphi remains non-OOP. You could create some technology close to COM, or use COM itself, which would be a shame. Newer OOP API? As far as I know, Delphi is not there yet...

So, the problem is quite solvable, but is pretty difficult. It can be discussed on what level it should be solved. Say, "object-based" API is simpler, but the using code would not be able to do inheritance, late binding, etc. Not quite real OOP. Interface-based solution is possible. And yes, if you know Delphi really well, it means you know C++ pretty well, not counting some fine and non-critical C++-specific detail, mostly syntactic. Delphi is more powerful and flexible, easier to do development; one important feature is different concept of constructors. You need to understand it all, first of all, some common denominator of a wide range of OO languages and their compatibility on binary level.

And what do you mean by "loading class"? I believe, there is no such thing. :-)

—SA

Nafees Hassan 21-Dec-15 1:11am

By user, I mean another Delphi programmer. And loading a class: Like you export and import functions, I want to export and import a class from a DLL. And I'm only targeting Delphi, I don't need to support other languages.

Sergey Alexandrovich Kryukov 21-Dec-15 1:25am

Your comment only confirms: there is no such thing as "loading", export/import is obvious.
—SA

Sergey Alexandrovich Kryukov 21-Dec-15 1:41am

All right, then the problem is solved — Solution 1.
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-12-20T19:40:00

Nafees Hassan wrote

By user, I mean another Delphi programmer. […] And I'm only targeting Delphi, I don't need to support other languages.

Then, this is not a problem at all.

The solution is: develop and use runtime packages instead of DLLs:
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Libraries_and_Packages_Index[^],
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Packages[^],
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Writing_Dynamically_Loaded_Libraries[^],
http://edn.embarcadero.com/article/27178[^].

You can consider this type of units as a specialized form of PE (DLL), "a DLL for Delphi". They allow to distribute code between those units freely, as it was in one executable file. In other words, all constructs, including classes can be "imported" or "exported". You use ordinary Delphi Pascal syntax. The boundaries between runtime packages are quite transparent.

Not that runtime packages as a are roughly equivalent to .NET assemblies, but not really equivalent in terms of their roles and development technology. In .NET, an assembly is usually the only compilation unit; even though each can have more than one module, multiple-module assemblies are not popular at all, and Visual Studio does not support them directly. In Delphi, there are two levels of library units: unit is a separate compilation unit, a main encapsulation device, and several units can make a single executable module, which can be application, DLL, or the runtime package, so a package can be considered as a higher-level unit and can be re-used "at Delphi level".

—SA