James Tittle II wrote:
CPPEXTERN_NEW_WITH_GIMME and *_WITH_ARGS: what did you mean by "manual" type-checking? I've been looking at the different usages throughout the
this means, you have to check the types of the atoms, whether they fit your assumption, if you want to make sure, that the "correct" arguments are supplied by the user. if someone types [GEMglProgramEnvParamter4dARB foo bar 1 2 3] it is your responsibility to tell the user, that this won't work.
...If pd only allows 5 typechecked arguments, does that mean I can't make a CPPEXTERN_NEW_WITH_SIX_ARGS?
exactly.
"typechecked" means, that pd checks the correct types for you, and if the arguments won't fit in, creation of the object is denied.
with c-externals one could always return a NULL-pointer when the manual typecheck fails, however this is not possible in C++ (we could try to utilize some exception that is thrown when creation fails...)
...If I use the GIMME method, does that limit the number of inlets I can deal with? Fr'instance, for this current wrapper "GEMglProgramEnvParameter4dARB", I'd like to have seperate inlets for not only target and index, but also x, y, z, w: after all, there is another call "GEMglProgramEnvParameter4dvARB" that would accept target, index, and a vector of x,y,z,w (and therefore only need 3 inlets)...I ask this because it seems that some GIMME-based externs use a "params" message, and I don't want to require non-vector accepting GL calls to accept vectors...
no, there is no relationship between the number of type-punned (oh another word!) inlets and the nunber of (type-checked) arguments.
probably it would be easiest, to not use any arguments at all and supply all parameters via inlets.
mfg.as.dr IOhannes