On 23 May 2014, at 3:46 , Torsten Bergmann <[email protected]> wrote: > YES, COOL - it now works as the attached PDF proves. > > 1000 timesRepeat: [ Transcript show: 'Henrik thanks!!!' ;cr ] > > Henrik - you have saved me to have to return to the darker sides of computing > and digg deeper into low level again ;) > > I knew that it must have been something in the calling wrapper and > was too blind to see it. > > A little bit misleading that one can not use the original C signature > in the NB description with char* and autoconversion through NB. > > Maybe I was too used to NB's predecessor FFI where one wrote char* and > just passed the Smalltalk string. > > Stupid me, I should have RTFM of NativeBoost instead of assuming > its close to FFI in this regard! So again the problem was in front > of the computer.
Really, blame char *, it’s too ambiguous. Is it raw byte(s)? Is it a string? How is its length conveyed? What’s the encoding supposed to be? You can’t really determine the answer to those questions up front in the FFI, though the right answer is usually clear on a case-by-case basis from the context. * So the NB rationale is (I think) not to do extra overhead which would still, sometimes, leave the user stumped at some strange error when the automatic handling mismatches reality. You only get bitten by it once (or maybe twice?), though the path to enlightenment could be less bumpy :) Cheers, Henry * No corresponding length parameter? Either single element or null-terminated string, as per context. String or bytes? Should be clear from context. Encoding? Well… usually utf8, but could also be some environment-defined code page, gotta check the library docs to be sure. Say what you want about Windows, but at least they their APIs use explicit string types with well defined encoding.
signature.asc
Description: Message signed with OpenPGP using GPGMail
