From: "Johan Holmberg" <johan556 / gmail.com>
> On Tue, Sep 30, 2008 at 9:27 PM, Nobuyoshi Nakada <nobu / ruby-lang.org> wrote:
>> At Tue, 30 Sep 2008 21:27:53 +0900, Johan Holmberg wrote in [ruby-core:19043]:
>>
>>> Is my analysis of the situation correct?
>>
>> Yes, and it has been fixed in 1.9.
>> Note that 1.8 hasn't supported C++.
> 
> Is there any chance that it could be backported to 1.8?
> I would like to stay with 1.8 until 1.9 is *the* Ruby used by "everybody".
> 
> Your answer in another mail in this thread seem to imply that it is a
> rather easy fix (#ifdef RUBY_EXPORT). Or is it more complicated?

Note, it's quite possible to use 1.8 with C++, even if it's
not officially supported.

We have been embedding ruby 1.8.4 into a C++ app for quite
a while.  The app builds on both Windows and OS X.

What I did was limit where "ruby.h" is included.  Indeed, I
only include "ruby.h" in a single .cpp file (and never from
a header file.)  I include all the platform headers first,
and stdlib headers, and boost headers, etc.  The very last
header I include is "ruby.h".

Also... before including "ruby.h" on Windows, I disable
the following warnings:

#if (defined(_MSC_VER))
#pragma warning( push )
#pragma warning(disable:4311 4312)
#endif


Note, because I avoided including "ruby.h" from any header
file, I did have a problem with the prototypes for a couple
private class members that used ruby's VALUE type.

I just used (void *) instead.  (I could also have avoided
that if I'd used the Pimpl idiom to keep private method
declarations out of my header file in the first place. :)


Hope this helps,

Bill