From: Paul C. <pa...@se...> - 2009-05-29 09:58:53
|
Hi, Thanks Berend for your reply. For some reason I managed to miss your reply and didn't see it until now. On Tue, May 19, 2009 at 8:03 AM, Berend de Boer <be...@po...> wrote: >>>>>> "Paul" == Paul Cohen <pa...@se...> writes: > Paul> Hi all, I need some advice/feedback on how to convert/create > Paul> a UC_STRING from a C pointer to a UTF8 byte sequence (and > Paul> vice versa). I can't find any routines or examples in the > Paul> Gobo unicode library for doing it. The need for this arises > Paul> when writing Eiffel shared libraries (with C-style API:s). > > Paul> It is unfortunate that I have to create two "string objects" > Paul> to perform the "conversion". > > You can iterate over the C pointer and do what make_from_utf8 does if > this is a concern. Nice. Thanks. > Paul> Returning a pointer to a UTF8 octet sequence is trickier. > > It is. I've found out that the only safe way to do this in ISE is to > allocate memory with C (malloc), copy the string to there and give a > pointer to that area to C. Ok. That what was I was thinking. > This was tested on a large production system with millions of such > calls, and any attempt to give pointers to an Eiffel object would fail > with weird errors after a while. There appeared to be no safe way to > retrieve a pointer to an ISE Eiffel object, whatever tricks were > applied. Hmm. That's what I feared. Berend, do you have any comment/opinion on the API design where the caller supplies allocated memory of some size and where the supplier (Eiffel side) can: 1. Fill the allocated memory with the result, if the memory is large enough. 2. Return an error code indicating that the memory provided is to small to return the result. Personally I think this is a rather good design principle for C API:s and makes it easier to use threads on the client side. However it makes it a little bit tricker to wrap the C API from Python, Ruby or other languages. It would be nice if one could mark given runtime objects or a class as "uncollectable" by the garbage collector, so that they are not touched (collected or moved) even if there are no Eiffel references to it. Maybe something for the Gobo Eiffel compiler? Even nicer would be if one could create such uncollectable objects on a once per thread basis. It would make it much easier to write thread-safe C style API:s in Eiffel! /Paul -- Paul Cohen www.seibostudios.se mobile: +46 730 787 035 e-mail: pau...@se... |