kyan wrote:
Hello all,
A couple of questions regarding handling of strings, dynamic arrays
and objects -especially exceptions- when writing programs that use
shared libraries (.dll, .so).
This seems to be a hot topic at the moment.
In Delphi we have the option of either using packages to ensure that
there is only one instance of the memory allocator or use ShareMem.pas
that installs a memory allocator that can handle memory allocations
across libraries. Given that in FPC/Lazarus there are no "packages" in
the Delphi sense what is the equivalent of ShareMem.pas? Is it
cmem.pp?
Yes. A reference to cmem should appear as the first entry in the uses
statement of earliest-executed unit, i.e. assuming Lazarus this is the
.lpr file. If using heaptrc this has to be put as the next entry, FPC's
-gh won't work, but I don't know to what extent having heaptrc in both
the main program and the library is workable (and various people are
currently mentioning heaptrc problems possibly caused by inadvertent
optimisation).
Regarding objects, in Delphi an object cannot safely cross dll
boundaries because separate class record(s) for it exist in each
executable file. OK, actually it can if one is certain that the class
records compiled in each executable are identical.
Agreed. However I'd suggest better terminology would be something like
"cannot safely be referenced across", simply saying "crossing" is too
evocative of "crossing a 64K boundary" for us old-timers :-)
Having said that, I'm successfully referencing (non-short) strings
across the divide, doing a deep-copy of TMenuItems from a form designed
in the shared library (which is there purely as a placeholder for menu
entries, and executing click events associated with menu items (which
work because they get a sender when invoked). I'm moving onto more
complex stuff shortly /but/ due to design requirements will be handling
this by passing parseable text commands, i.e. the backend can tell the
frontend to change the UI state (without full knowledge of the current
state) and the frontend can tell the backend to change state (with the
same limitation).
But if an exception
crosses dll boundaries then you are in trouble, because the operator
"is" does not work due to the class pointer that points to another
Exception class record than the one known by the handling executable.
Generally agreed.
The best way to solve this is to put the class Exception at least
inside a package that all executables use so at least "is" will work
for Exception. Is there a way to handle this problem in FPC that does
not have packages?
Not knowing, can't say. Looking at the larger picture, I don't know how
one best debugs operation as control is transferred from the main
program into the shared library, bearing in mind that this might be
important since the library might have all the tricky code.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
