[xmlsec] xmlsec library, memory allocation and initialization
aleksey at aleksey.com
Thu Nov 14 07:50:09 PST 2002
I have good and bad news for you. The good news is that I am doing
some code refactoring right now and you might get all you want when
I am done. My current plan is to create an object system similar to one
found in GLib/GTK with universal constructors and destructors.
The bad news is that you still need to have something similar in LibXML
as far as I can understand. And I am not sure that this will be easy.
Marius Kjeldahl wrote:
> Hi all (and Aleksey)...
> I'm embedding libxml2 and xmlsec into lua (http://www.lua.org/) and
> plan on using this for various applications dealing with secure credit
> card transactions.
> Lua (and most other scripting languages) uses different memory
> management than the explicit alloc/free found in lower level
> languages, and ideally I would like to avoid introducing "c-style"
> memory management in the scripting part of the application.
> In lua, it is possible to add something called "metatables" to objects
> (in general) and "userdata" (which is memory allocated by the lua
> memory allocater which can be garbage collected automatically).
> If xmlsec would separate memory allocation from initialization,
> supporting garbage collection (and other methods, like reference
> counting that perl use) would be quite easy.
> In xmlsec the method xmlSecSimpleKeysMngrCreate currently does BOTH
> memory allocation and initialization. This means it is difficult to
> allocate the memory from within lua (to enable garbage collection).
> Ideally, one could split that function into two other functions:
> xmlSecSimpleKeysMngrAlloc which allocates the memory
> xmlSecSimpleKeysMngrInit which initialize it
> Then xmlSecSimpleKeysMngrCreate would simply call both of them in
> order and behave just like before.
> These changes throughout the xmlsec library would probably help
> getting xmlsec into more scriptable cores like Lua, Perl and more, and
> would ease memory and object management considerably under those
> higher level languages.
> Any other ideas on how to accomplish something similar? I'm writing
> more and more applications using script languages these days, and I am
> getting spoiled with avoiding explicit memory management.
More information about the xmlsec