![](https://secure.gravatar.com/avatar/d41a1ae8ef63e95a9816f4fbbb9223a3.jpg?s=120&d=mm&r=g)
On Tue, Oct 1, 2013 at 12:35 PM, Luís Oliveira <loliveira@common-lisp.net> wrote:
On Tue, Oct 1, 2013 at 5:28 PM, Liam Healy <lnp@healy.washington.dc.us> wrote:
OK. On superficial examination, it seems like foreign-string-alloc and lisp-string-to-foreign have significant duplicated code. Is there a reason for that rather than having the former call the latter?
Having the foreign-string-alloc call lisp-string-to-foreign would cause the string length to be calculated twice. But it indeed seems like they could both share a helper function at least.
-- Luís Oliveira
Are you sure? ;;; LMH new function (defun length-of-string-as-foreign (string encoding start end null-terminated-p) (+ (funcall (octet-counter (lookup-mapping *foreign-string-mappings* encoding)) string start end 0) (if null-terminated-p (null-terminator-len encoding) 0))) ;;; LMH new version (defun foreign-string-alloc (string &key (encoding *default-foreign-encoding*) (null-terminated-p t) (start 0) end) "Allocate a foreign string containing Lisp string STRING. The string must be freed with FOREIGN-STRING-FREE." (let* ((length (length-of-string-as-foreign string encoding start end null-terminated-p)) (ptr (foreign-alloc :char :count length))) (lisp-string-to-foreign string ptr length :start start :end end :encoding encoding) (values ptr length))) The only duplication of effort is mapping and null-len, which seem like pretty lightweight operations. However, by adding key variables to lisp-string-to-foreign, we could avoid the recalculation. The new function I have defined is mostly for my clarity of thought and can be folded into foreign-string-alloc if that's preferable. Does this look right? What do you think? Thanks, Liam