Thu, 4 Jan 2001 02:59:05 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
Actually I consider the current libraries to be on the verge of usability, modulo the missing string marshalling and error functionality.
For both subjects I have a proposal in QForeign. I have no doubts about the strings story, except the internals of the charset conversion machinery. Error handling functions are more arbitrarily chosen.
I've been wondering whether we should have something like
newtype CString = CString (Ptr CChar)
which would allow GHC to replace the representation with a ByteArray leading to a much more efficient implementation of withCString.
Do you have the overhead of malloc in mind? If so, perhaps a generic stack allocator would be better. Anyway, conversions between strings which involve charset conversions require a more sophisticated pattern of memory allocation. It is not known how much space will be needed in advance, it can only be estimated. It is known when the string has already been stored in some memory directly accessible to C functions (in the common case of using the default conversion). Doing it on ByteArrays would be very tricky. There is no reallocByteArray and ByteArrays are not convertible to Ptrs (I currently assume that a conversion implemented in C will be exposed as a function working on Ptrs). My current strategy is to use malloc directly instead of alloca. If there was a faster alloca allocator, it could make sense to make a guess about the size and use alloca, resorting to malloc if it didn't fit. It would have to be significantly faster to think about making it more complex at all. The conversion itself can be a larger overhead than malloc. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK