What i'd like to see is compiler level support for loading dynamic libraries
and binding thier functions on demand.
this would mean a lot more flexibility. New features could be used without
breaking compatibility with older versions of the library. Version and
naming issues could be dealt with at
On Tue, 2006-05-09 at 20:31 +0100, peter green wrote:
> What i'd like to see is compiler level support for loading dynamic libraries
> and binding thier functions on demand.
Like the database-base packages do? (example:
packages/base/ibase/ibase60dyn.pp)
But here I've used wrappers. But it's not
> > What i'd like to see is compiler level support for loading
> dynamic libraries
> > and binding thier functions on demand.
>
> Like the database-base packages do? (example:
> packages/base/ibase/ibase60dyn.pp)
ok that unit really confuses me, it seems to treat procedures declared
external as if
On Tue, 2006-05-09 at 21:26 +0100, peter green wrote:
> > > What i'd like to see is compiler level support for loading
> > dynamic libraries
> > > and binding thier functions on demand.
> >
> > Like the database-base packages do? (example:
> > packages/base/ibase/ibase60dyn.pp)
> ok that unit reall
oost van
> der Sluis
> Sent: 09 May 2006 23:26
> To: FPC developers' list
> Subject: RE: [fpc-devel] a shared library suggestion
>
>
> On Tue, 2006-05-09 at 21:26 +0100, peter green wrote:
> > > > What i'd like to see is compiler level support for loading
>
> yeah that technique requires far less stubs but it means that the coder has
> to manually call an init function.
>
> also how does your code respond if one of the entry points isn't found?
Myself I use
{$IFDEF DEBUG}
if getprocaddress(somefunc) = nil then write('somefunc getproc error');
{$EN
On Wed, 10 May 2006, peter green wrote:
yeah that technique requires far less stubs but it means that the coder has
to manually call an init function.
No.
- This can be put in the initialization of the unit.
- It can be called by components that need it. SQLDB does it like that.
also how
>
> It does get very very tedious to type all this out for large libraries with
> 50 functions
> or so.
> If you want to economize the size of the library you turn off the {$DEFINE
> DEBUG}
>
> Do you know that FPC will have a Package system available in fpc 2.1.1,
> sooner or later?
> It will
peter green wrote:
> yeah that technique requires far less stubs but it means that the coder has
> to manually call an init function.
>
Not necessarily, because you can load all addresses in initialization
section of the unit. That's what I do in my various wrappers.
> also how does your code re
> > Do you know that FPC will have a Package system available in fpc 2.1.1,
> > sooner or
later?
> > It will require shipping the RTL in a package, I think - which means we get
> > into
Package
> > hell like BPL's offered. I'd rather have the ability to load one package
> > and not have
to
> > s
10 matches
Mail list logo
