Well, fortran subroutines don't really have return values (versus fortran functions, which do - as far as I know that's the only difference between fortran subroutines and functions).
There is also a somewhat sticky matter, of C routines that returns fairly complex types, like pointers, strings... and likewise, fortran functions can return rather complex things, like matrices, etc. It is going to be difficult to do a one-size-fit-all solution. So all you are trying to cater for, is a rather small subset of C/fortran functions which returns a single int or a single double? (anything to do with arrays you'll need to "smuggle" the array size out the old-fashion way via argument pointers). Harris A. Jaffee wrote: > Re: src/main/dotcode.c:do_dotCode() > > The value, if there is one, of a function called by .C or .Fortran is not > captured, so one needs a wrapper. To avoid that, the user would have to > declare that there is a value, specify its type, and supply an R variable > to hold the value. Presumably, all of these could be combined in a new > "VALUE=var" parameter. Then do_dotCode could arrange the correct type of > C variable to receive the value (for every one of the 66 possible instances > of the call), and then transfer that value to 'var'. It seems doable with > a strong enough macro, if a bit complicated. Or one could say VALUE=<type> > and get the value as a new, (n+1)_th element of the current list value. > > Of course, existing code naming an argument with "VALUE" would break, so a > completely new interface, perhaps .C.function(), .Fortran.function(), would > be required to avoid that. > > Has this facility been ruled out? > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
