lua-users home
lua-l archive

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

Paul Moore wrote:
> On 01/02/2008, Thomas Harning <> wrote:
>> Paul Moore wrote:
>>> The biggest issue I have is that converting char <-> wchar_t requires
>>> memory buffers for the conversion. I can obtain these in a number of
>>> ways (the lua allocator, creating userdata objects, etc) but I need to
>>> manage the lifetime of the buffers
>> One of the API's in Lua that I think might solve at least the wchar_t ->
>> char problem is the luaL_Buffer setup [1].
> [...]
>> I'd hope that some sort of _convert_ API exists like that...
> [snip snip]
> So it looks like I have 2 reasonable choices:
> - Use luaL_Buffer and disallow strings over LUAL_BUFFERSIZE.
> - Use lua_newuserdata to allocate a memory block on the stack which is
> managed by gc.
> I could use a hybrid, using luaL_Buffer if LUAL_BUFFERSIZE is OK,
> otherwise allocate a userdata. That is probably overkill, though.
> Thanks for the suggestions. I'll probably go with the userdata option,
> just because I hate code with arbitrary limits.

What I am doing in the same area: I'm writing a small Lua library
to improve my personal incremental backup scripts (in Lua) on
Win32, and impedance matching calls like FindNextFileW via a very
basic UTF-8 <-> UTF-16LE layer. I decided to keep required structs
and handles as userdata bundles and convert wchar_t <-> UTF-8
right at the end or edges. I am calling two conversion functions,
one to get buffer length and one to convert. I guess for the file
and directory calls I am making, I don't think the performance of
that particular part of the code will be an issue on an average
2007 desktop.

Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia