alloc and free function for types

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some time ago we discussed the following extension to our plugin mechanism:

~   Pass every link-type two functions into it's new_instance() function:

~        ...
~        void* new_instance(void* (*gphx_alloc)(unsigned int), void (*gphx_free)(void*));
~        ...

~   The semantics of the parameters should be appearant from their naming.
~   Now the new instance will use these two functions for dynamic memory management
~   (and _must_not_ use other functions like new/delete, malloc/free, ...)

The motivation for this extension was the increased flexibility:
It would be possible to use a different memory allocator on a *per instance* basis
- - for example, if you have two number-links, one could be allocated via std. malloc/free and
the other one with a special pool allocator
~ (this is just an example, does not seem to make too much sense...)

The primary application of this extension is:
put some links into shared memory in order to communicate with
units that have been moved into different processes (stability).

Different applications might appear (for example, use efficient pool allocation for certain
types).

So far everything seems fine, now to the problems.
I have implemented this for our number plugin and it works (core just passes malloc and free as parameters).
But there is one open issue: alignment!
I use gphx_alloc in combination with placement new to create the NumberLink object
(in plugins/src/numbers/number/number_cwrapper.cpp). This works, but completely ignores all alignment issues!
(I think in x86 this should work most of the time, but other platforms will cause problems).

Also, I did not find a good way to wrap this memory managment stuff s.t. the implementation of NumberLink
could simply use new/delete (overloading new/delete for this class does not do the trick).
So the coder of the link type will have to use gphx_alloc and placement new, and will have to care
abotu alignment, too.

(Actually, when coding an effect in plain C there seems to be no problem).

So what do you think? Is it worth pushing this approach further?
(Anyone nows how to deal with the alignment stuff in a platform independent way?)

Or should we just drop this extension?
(Is there another good way to communicate with units that are moved into different processes?)
It will be somewhat costly if we drop it now and decide that we want it later on - every type must
be modified then.

Regards,

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAIBDa/rP0cdKF/ToRAoTAAJ4oYyqaYw0YoRb+ffyygckZ9Hl8EACgnBlC
6ut9fSyXzFjOYKAsL5Gugtw=
=Y6j8
-----END PGP SIGNATURE-----