From: Dmitry I. <div...@gm...> - 2014-04-03 13:46:55
|
Christophe Rhodes wrote on Tue, 01 Apr 2014 06:58:39 +0100 09:58: CR> It's not documented as far as I remember, but it's UCS-4 (i.e. 4 CR> bytes per character). Thanks. That does not fit well my needs as there basically two possibilities on Windows: - either ANSI/Latin-1 - or UCS-2 (aka wide character type). The later two-byte encoding is enough for most of European languages. In LispWorks, there is the *default-character-element-type* parameter that controls the character size of all the strings allocated by my application. So I could pass many Russian strings to Win32 API directly if there were pinning. As there is no analog of with-pinned-objects in LispWorks, I have to allocate a space for any string in stack and invoke copying in binary mode. With SBCL, the situation is worse. All my strings are in UCS-4 though UCS-2 were enough. To pass any string to foreign a function, the following two steps are always invoked behind the scene or explicitly: 1) allocating in heap, 2) the "heavy" external-format routine recodes the string to UCS-2. Sigh... NS> Notice also the :external-format option to alien c-string, which NS> gives you an implicit copy in whatever format you ask for. NS> (...yeah, not sure if that its properly documented anywhere.) Sorry NS> about top posting,- n I have heard about :external-format for the alien c-string type. Maybe this is helpful for declaring foreign functions in SBCL syntax. But if you wish to implement FFI compatibility between LispWorks and SBCL, the :external-format were hardly useful. I would prefer to allocate foreign objects explicitly and explicitly pass the foreign pointers to foreign calls. UFFI and CFFI, the two most popular compatibility libraries, work hard to unify foreign calls. The huge amount of CFFI code "simply" reimplements the SBCL FFI layer because the latter is not comfortable enough. -- Sincerely, Dmitry Ivanov lisp.ystok.ru |