0

I am thinking of the following:

library LinuxRPM;

{ Important note about DLL memory management: ShareMem must be the
  first unit in your library's USES clause AND your project's (select
  Project-View Source) USES clause if your DLL exports any procedures or
  functions that pass strings as parameters or function results. This
  applies to all strings passed to and from your DLL--even those that
  are nested in records and classes. ShareMem is the interface unit to
  the BORLNDMM.DLL shared memory manager, which must be deployed along
  with your DLL. To avoid using BORLNDMM.DLL, pass string information
  using PChar or ShortString parameters. }

uses
  System.SysUtils,
  System.Classes;

{$R *.res}

type
  TRadioTracer = class

  end;

var
  RPM: TRadioTracer;

exports
  RPM;

begin
  RPM = TRadioTracer.Create;
end.

However, not sure where and if do I need to call RPM.Free.

justyy
  • 5,831
  • 4
  • 40
  • 73
  • Never ever ever pass objects across dll boundaries. Consider interfaces instead. – Jerry Dodge Jan 23 '17 at 14:42
  • why? and how? do you have a simple, minimal working example? – justyy Jan 23 '17 at 14:45
  • From the example in the link you provided, I don't see how to export the 'object', because an object contains private attributes, fields, but the example just exports the function... Put it simple, where should I initialize the object and destroy the object? – justyy Jan 23 '17 at 14:51
  • You don't export an object. You export a function which returns an instance of an object. There's no such thing as exporting an object. Even then, like I said, you should never ever pass an object through a DLL. – Jerry Dodge Jan 23 '17 at 14:54
  • so, is it correct that, I could instead export two functions, e.g. CreateObject and DestroyObject, then the object is not exported but maintained inside the DLL only (only visible in DLL)? – justyy Jan 24 '17 at 11:11
  • Yep, that could work – David Heffernan Jan 25 '17 at 05:29

0 Answers0