> > 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