[xml] xmlFreeStr



Hello Daniel,

after some discussions and experiments, we discovered that the best (and nearly only) way to release memory 
allocated for strings in
libxml2 is, to have an API function there; anything else would be just a workarround. As Martijn Brinkers 
wrote:

[ http://www.geocrawler.com/lists/3/SourceForge/13788/0/7648278  ]
Personally I think providing a exported function xmlFree (like you did) is
more elegant. It just happened that the dll was build with VC++ and that the
function is exported but this is not 'by design'. Now if I would like to
recompile everything with C++ builder I will have to export that same (VC++)
function myself. So my point is that it should be (by design) a part of the
API and not just a 'coincidence'. So I would 'urge' the maintainer to add it
to the API, not just because we only need it but all user who do not use
VC++ will use it.

My opinion is that it makes the API well ballanced, if it enables the user to deallocate anything that has 
been allocated by its
other parts.
Also, take in consideration that adding this function will help in extending the library to one more platform 
(Delphi on Win32)
which might be of some importance.

I am aware that you said that "...adding new APIs is a problem ATM..." [
http://mail.gnome.org/archives/xml/2002-January/msg00209.html ]
May I ask you when will this not be problem, and what causes it ?
Is it possible to add functions to the implementation part now, and later present it in headers as an API ? 
This will work for us,
as long as Igor adds the entry to the libxml2.def.src file.

I do not know where the function fits best (parser.c or xmlmemory.c) but perhaps it wouldn't be bad to have 
all the xmlChar*
oriented functions in a separate file in the future...

The implementation is of course trivial, but perhaps it helps you to have it here at hand:
---------------------
/**
 * xmlxmlFreeStr:
 * Deallocate the string allocated by an api call.
 */
void
xmlFreeStr(xmlChar* str)
{
    free(str);
}
---------------------
Thanks
Petr






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]