Re: Creating and using a .DLL/.SO?

new topic     » goto parent     » topic index » view thread      » older message » newer message
jimcbrown said...

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu