From ripley@stats.ox.ac.uk  Fri Jan 31 11:37:05 2003
From: ripley@stats.ox.ac.uk (ripley@stats.ox.ac.uk)
Date: Fri Jan 31 11:37:05 2003
Subject: [Rd] Embedding R in C++
In-Reply-To: <101F2E8E-34F5-11D7-AD1D-00039391E298@zedshaw.com>
Message-ID: <Pine.LNX.4.44.0301310913320.15799-100000@gannet.stats>

It's a problem with e.g. the Matrix package, and has been with others.
Careful use of #undef is needed; see the code there.

Another problem is mixing with Windows headers, which g++ has now in its
wisdom decided to include from some C++ headers.  #under ERROR is
sometimes needed, for example, as well as length, append and Free.

It's worth noting that almost all these problems have emerged with
libg++-v3 and/or mingw-runtime-2.x.  So another version might be

     'Other libraries like to define things which R has already defined.'

which is intended to help explain why projects such as R cannot suddenly 
jump to the tune of g++ or glibc or mingw ... as our API has customers 
too.

In the case of PI, there is a standard define, M_PI, but according to
R-exts this is included in R's headers for compatibility with S (and so is
ERROR).  I do wonder if we should not have a define that removes these
compatibility defines.  What might be a good name: NO_S_DEFINES?
STRICT_R_HEADERS?

In the cases of length and append we ought to bite the bullet and stop
re-defining them.

On Fri, 31 Jan 2003, Zed A. Shaw wrote:

> Hi Folks,
> 
> Alright, so I'm figuring out how to embed from the various docs and 
> other nuggets of hidden information, and I've managed to get a nice 
> little C++ framework going which is supposed to make working with R 
> embedded stuff much easier.  The problem is, R likes to define things 
> that other libraries also like to define.  For example, the libg++-v3 
> library has a macro called length, and so does R.  This causes ALL 
> iostream uses to fail.  R also defines PI, which is defined in another 
> toolkit.  We also use a set of debugging macros named TRACE, 
> UNIMPLEMENTED, and so on, but we can work around those problems.
> 
> The work around to the iostream problem is to order the includes so 
> that C++ stuff comes before R stuff.  This works in most cases, but 
> some don't (like with PI, TRACE, and UNIMPLEMENTED).
> 
> Has anyone else run into these kinds of problems mixing R with C++?  
> I'm curious how you worked around it.  Thanks in advance.

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Embedding R in C++
ripley@stats.ox.ac.uk