RE: [Boost-Users] Re: Re: preprocessor: convert to capitals

From: HartmutKaiser_at_[hidden]
Date: 2003-04-10 01:28:39

Paul Mensonides wrote:

> > 1) all manual
> > For the bindings we #ifdef on the platform to determine
> > how to convert identifiers (to match their fortran counterpart) and 
> > then define an identifier for every function (with the additonal 
> > underscore ...)
> >
> > e.g.
> > #ifdef __sgi
> > #define DAXPY daxpy_
> > #endif
> >
> > 2) Wave (as suggested by Hartmut Kaiser)
> > Use wave to create a header from an input-file. This puts
> > a strong dependency on Wave  and although the tool is 
> impressive, this 
> > will make it difficult for people to add a new binding IMHO.
> 
> Actually, what Hartmut is working on now is a general 
> mechanism for the preprocessor to call external programs.  
> The tolower, toupper types of things fit into this mold perfectly.

There now is a special pragma:

_Pragma("wave system(toupper whatever)")

Where toupper is an external command, which converts the arguments
supplied on the command line to upper case and puts the result into the
stdout stream. Wave intercepts the stdout of the spawned command and
uses this as the replacement text for the whole pragma. This way you may
write (as suggested by Paul Mensonides):

#define TO_UPPER(id) \
    _Pragma( \
        BOOST_PP_STRINGIZE(wave system(toupper id)) \
    ) \
    /**/

# if /* style == _func */
#  define FORTRAN(id) BOOST_PP_CAT(_, id)
# elif /* style == FUNC */
#  define FORTRAN(id) TO_UPPER(id)
# else
#  define FORTRAN(id) id
# endif

Ok, using Wave involves one more build step, but your source is more
clean this way, because you do not have to write things like

FORTRAN_ID( d a x p y )

Which is error prone and not obvious. If you're planning to provide the
generated headers anyway (just like the MPL does for different
compilers), so the Wave execution step is to be done _once_ for every
binding, which shouldn't introduce any new problems. Moreover, the Wave
executable does not need to be installed on the target machine.

BTW: I expect to ask for a Boost rewiew for Wave soon, so maybe it will
be a part of Boost anyway.

> > 3) Suggestion above of Paul Mensonidis
> > This option will give us minimal work, we could just write IIUC 
> > FORTRAN_ID( d a x p y ).
> > (Paul: could we leave out the seperation of the characters if we 
> > always provide seperated characters directly as in the line above ?)
> > However, this solution might limit portability.
> 
> Yes, you could do it either way and it won't effect 
> portibility.  I just thought that you want syntactic 
> "cleanliness", without having to do this:
> 
> # if /* style == leading-underscore */
> #  define FUNCTION _function
> # elif /* style == all-caps */
> #  define FUNCTION FUNCTION
> # else
> #  define FUNCTION function
> # endif
> 
> ...for every identifier used.  For maximum syntactic 
> cleanliness, you need a minimum of one macro per identifier:
> 
> #define DAXPY FORTRAN_ID(d a x p y _)
> 
> But this is just a shorthand for directly using FORTRAN_ID(...).
> 
> > Although I'm used to option 1, I would like to go for option 3 
> > (although maybe looking at the portability of the pp lib would not
> > hurt)
> 
> I'm not sure what you mean here.  I would use the pp-lib of 
> course.  In fact, I'd add a few things to it that should 
> probably be added anyway.

Regards Hartmut