Hans-Christoph Steiner wrote:
Hey,
Just a thought here, I am currently porting a Max object to Pd and just saw that the setup is called main(). So how about making it possible to just use setup() as the function name?
if i/you remember correctly, we have been talking about this at the LAC. miller has some reservations against it which i think are invalid.
afaik, the point against this is that we would have function name clashes. obviously this is not a problem, as it works in max, in ftm4pd (where i chose "ftm_main()" as the setupfunction for _all_ externals) and in most other plugin APIs.
it becomes more problematic if we are dealing with multi-object libraries rather than single-object externals: in this case we get real nameclashes. to solve this one would have to either discard multi-object libraries or inform the preprocessor on whether we want a library or an external.
then i think that "main(void)" is really the worst name they could have thought of, as it clashes with "main(int argc, char**argv)". i would much more prefer a name like "pdsetup(void)"
all this could be resolved very simple by not having to explicitely call a setup-function but by using the automatic function execution at load-time (on gcc this is "__attribute__ ((constructor))", on M$VC there are other ways...) the only drawback i see here is that you don't have control about which function is executed first.
finally, i don't know why this should be embedded into hexloader. hexloader currently does some clever recursive calling of other loaders in order to be able to use it not only for C-externals but also for lua, python,... therefore you would just have to write a "main loader" that calls "main()" (or whatever) for external initialization. once you have loaded both the "main loader" and the "hexloader", Pd will magically call the "main()" function in your "here0x2d0x3ethere.l_i386"
mfga.sdr IOhannes