malloc-free allocation -- here: instance methods

Hoehle, Joerg-Cyril writes:

 > I still believe modules is a way to go to interface to foreign
 > stuff. That implies C code, be it automatically generated or
 > not. This C code should then contain the offsets and other
 > architecture/platform dependent forms. Let the .fas file and Lisp
 > code remain free of that.

good point! I'll follow this approach.

 > >returned function prototype could be a problem: every DB fuction has
 > >its own parameter list. Probably the C factory function should return
 > I don't understand this.

well, different DB functions have different argument lists. For example:

int DB->get(DB *db, DB_TXN *txnid, DBT *key, DBT *data, u_int32_t flags);

int DB->open(DB *db, DB_TXN *txnid, const char *file,const char *database, 
             DBTYPE type, u_int32_t flags, int mode);

In C the factory function could probably be declared as

typedef int (*db_function) (/* we can't specify argument list! */);
db_function ff_factory (DB *dbp, int function_type)
{
 [...]
}

It would be better to specify arguments in the db_function type
definition, but the C compiler can work without them. How should such
a foreign function be defined in CLISP? What return type should we use?

(def-call-out ff-factory
  (:name "ff_factory")
  (:arguments (db (c-ptr DB :in)) (function-type int :in))
  (:return-type ???))


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf