> > However why did do that? I wonder it would take you the same > > amount of time to apply f2c and make the final C++ code up. > Not really. > I was asked to provide an interface to some CERNLIB functions. Maybe > tomorrow I will be asked to do it for some other functions ? > The time spent on rewriting the code in C (even using f2c) would be much > longer then just writing a couple of lines of "glue" code. I agree the wrapper around the legacy Fortran library entry is simpler and one doesn't need to be tested providing the original Fortran code was tested. However I do not think the idea to keep the Fortran environment just to be able to call the legacy Fortran codes may survive in long term. This means sooner / later we will need the "pure" C++ implemented numerical methods. By this reason I did not implement the wrapper around F110 / F112 CERNLIB functions and did spend my time with converting code to C++ class methods. > Anyhow, I've spent most of the time trying to provide an interface between > compiled and interpreted code (mainly because of some CINT problems, the > most nasty being in G__isinterpretedp2f). This would NOT disappear even if > the source code was in C. Yes, this is why I find your example is extremely useful.. > > On another hand your example is good for some UNIX systems only. > > It does take in account only one kind of "FORTRAN subroutine name > > mangling schema". > Well, typically it's just appending an underscore, or not. This is taken > into account by "#ifdef extname" in the CERNfunctions.cxx file (one needs > to add "-Dextname" while compiling, or not - this should be taken > automatically into account in the Makefile). > > > I think this should mentioned on ROOT Web site. Otherwise the Windows > > users will be confused again. > I'm sorry for these people, but ... this is just one reason more to > delete FAT partitions and replace them with some ext2 ones. I have not used FAT for 7 years and I am not familiar with "ext2" However NTFS serves me well. > Well, I don't know how the Windose screws things up. If you know how to > unscrew it, One can find this information within well-known "cfortran" packages. In fact what you did is another implementation of that package. See "cfortran.h" from: ls /afs/cern.ch/asis/share/cern/pro/include/cfortran/ Examples geant321.h hbook.h jetset74.h lepto62.h zebra.h cfortran.h gen.h higz.h kernlib.h minuit.h geant315.h graflib.h hplot.h kuip.h packlib.h With my best regards, Valery
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:39 MET