Re: Creating and using a .DLL/.SO?
- Posted by jeremy (admin) Dec 26, 2008
- 1119 views
Why would you use open_dll() to include a translated include file?
I thought you'd just do
include dbi_mysql.so as mysql
That seems like a nice way to simply include compiled code, however, it does not allow any type of dynamic module loading. For instance, take eudoc. It has source code parsers, each parser has a function called parse(sequence filename) and it returns a sequence structured property for eudoc. Here's how I would envision something like that working:
enum PARSER_FEXT, PARSER_FUNC_ID sequence parsers = {} procedure load_parser_modules() sequence files = dir("parser_*.so") for file in files do atom lib = open_dll(file[FILENAME]) atom init_func = c_func(lib, "init", ...) sequence parser_info = c_func(init_func, ...) parsers &= { parser_info[PARSER_NAME], parser_info[FILE_EXTENSION], c_func(lib, "parse", ...) } end for end procedure -- Now later in code: function parse(sequence filename) atom parser = find_parser_in_parsers_sequence(filename) return c_func(parser, {filename}) end function
That of course is not all legit code, but could easily be. So, in this case we may have a parser for Euphoria, C, Makefile, Text files, Creole files, HTML files, or whatever. EuDoc could be used for *any* language, as long as a parser is written for it. In this example (a very viable and common use of loadable modules) the user of the loadable module does not want the functions embedded, nor does he/she want to handle them by namespaces. Further, they want to load them dynamically (i.e. not knowing what they are at the time of writing the code).
Jeremy