Re: [boost] Any interest in static plugins?

Subject: Re: [boost] Any interest in static plugins?
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-12-06 00:54:02

On Sat, Dec 5, 2009 at 9:20 AM, Dave van Soest <dsoest_at_[hidden]> wrote:

> Hi Christian,
>
>  Sure, you can come up with and practically use toy systems with a given
>>
>>> linker in a given configuration that have no problem. But when you have
>>> complex and.or derived types, or use dynamic linking, it becomes an
>>> intractable problem.
>>>
>>
> Can you name any complex or derived types that wouldn't work?
>

// this requires that type A is registered before type B
struct A { };
struct B { Pointer<A> a; static void Register(Factory &f) { a =
f.Create<A>(); } };

...

// this also requires that A is registered before B
struct A { };
struct B : DerivesFrom<A> { };

...

>
> What is wrong with calling functions before main(), if you do it carefully?
>

Because "doing it carefully" sometimes isn't enough. For example, if you're
doing your own memory management (a common motivator for using factories at
all), then any allocation done before main() will be using the clib malloc -
and before any of your own custom memory allocation systems have been
initialised. Then you have to work-around that.

Then that becomes a problem because often this allocator has to be guarded
against multiple threads, which requires semaphores or other locking
structures to be setup, which then have to be done statically, and because
of the ordering issue you are back to square one.

> The client coder won't get the opportunity to call any function before
> main() through this library.
>

This is not true; initialisation code in the registration method will be
called before main(), as will anything called from it. Over time you may
want to read configuration files or do memory allocation in these pre-main
systems. It grows. It gets gnarly. You work-around it. It grows more. Then
you get it working, then change linkers and it all breaks again.

Other example gotchas are initialisation of logging systems, string pools
systems, data-structures with private static pools - basically, pre-main is
a bad space in which to try to do anything.

If you kept it extremely simple - no allocation, no threading, no file
handling, no exceptions, no nested or derived types, and in a known, single
development environment then yeah, sure, it can work. But its not portable,
doesn't scale, is untestable, and its extremely limited.

Oh, its not testable because the use of globals means that you cant create
the system, test it and tear it down again in isolation of other systems.
The lack of deterministic ordering means that testing is problematic even in
the basic cases.

> My response to the third problem is, just like the problem itself, yet
> unknown.

The C machine is not meant to be used this way. It can be used this way, but
it invariably results in many subtle problems.

This idea has been kicked around by various people and teams going back
decades. It has always proven to be a neat idea that doesn't work in the
real world. Perhaps it can work; but all I know about are counter-examples.

> Thanks. I really appreciate the time you spent on joining the discussion.
> Indeed you can't dissuade me from continuing this work, but still I really
> think it's valuable to have a sceptical counterweight to keep me from
> turning assumptions into beliefs and pointing me at potential problems I
> haven't really well thought out.

Welcome,
Christian.