Compiling using IMPORT, NT=1

ruby-talk
1

Hi!

I hope this is the right mailing list for this (might belong more to
core). As a lot of people, I encountered some problems when adding the
ruby import library manually to my project. Defining IMPORT and NT=1
solved those problems (thank God for the mailing list archives). But,
this introduces another really nasty problem. Those defines trigger the
inclusion of the win32/win32.h file. This file does a bunch of defines
of the sort:

#define eof _eof

Now, the problem I have with this is, that my code uses the STL
stringstream … which coincidentally has an eof() member function. Now,
I just went ahead and did something like this (without IMPORT and NT=1):

#define EXTERN extern __declspec(dllimport)
#include <ruby/ruby.h>
#undef EXTERN

The alternative to this was:

#include <ruby/ruby.h>
#undef eof

Both solutions are not really satisfactory. Does somebody know what the
exact purpose of the win32/win32.h file is? It seems a bit like an
emulation layer, but that problem should probably be solved in code, not
in a header file.

Thanks a lot,
Marco

2

“Marco Kögler” marco.koegler@web.de wrote in message
news:3DA3E640.4090903@web.de…

#define eof _eof

Now, the problem I have with this is, that my code uses the STL
stringstream … which coincidentally has an eof() member function. Now,
I just went ahead and did something like this (without IMPORT and NT=1):

That’s why STL uses the std:: namespace.

I recommend the practive of never have a using namespace std in the code.
Instead typedef the types you are using. For example:

#include
typedef int_vector_t std::vector;

Both solutions are not really satisfactory. Does somebody know what the
exact purpose of the win32/win32.h file is? It seems a bit like an
emulation layer, but that problem should probably be solved in code, not
in a header file.

Without knowing the sources, I tend to agree. Generally I’d say that the
practice should be that standard API include files (here Ruby API) should
not depend on platform specific includes. There may be platform specific
operations requiring a platform specific header, but then their prototypes
should be in seperate API include file.

Mikkel

3

Marco Kögler wrote:

I hope this is the right mailing list for this (might belong more to
core). As a lot of people, I encountered some problems when adding the
ruby import library manually to my project. Defining IMPORT and NT=1
solved those problems (thank God for the mailing list archives). But,
this introduces another really nasty problem. Those defines trigger the
inclusion of the win32/win32.h file. This file does a bunch of defines
of the sort:

#define eof _eof

I agree with you that this is a problem. In the FXRuby sources, I have
to do a lot of hand-waving to “fix back” the symbols that the Ruby
header files redefine. For example, one of the C++ class member
functions that we need to call is named “select()”:

 class FXGLViewer {
   ...
   virtual FXGLObject** select(FXint x,FXint y,FXint w,FXint h);
   ...
   };

but since the Ruby header files redefine “select” to “_select”, the call
fails. The only workaround I’ve come up with is (as you showed) to
undefine the offending symbols after having included the Ruby headers, i.e.

 #include "ruby.h"

 #ifdef select
 #undef select
 #endif
 #ifdef open
 #undef open
 #endif
/* and so on */

Both solutions are not really satisfactory. Does somebody know what the
exact purpose of the win32/win32.h file is? It seems a bit like an
emulation layer, but that problem should probably be solved in code, not
in a header file.

Definitely agree.

4

MikkelFJ wrote:

“Marco Kögler” marco.koegler@web.de wrote in message
news:3DA3E640.4090903@web.de…

#define eof _eof

Now, the problem I have with this is, that my code uses the STL
stringstream … which coincidentally has an eof() member function. Now,
I just went ahead and did something like this (without IMPORT and NT=1):

That’s why STL uses the std:: namespace.

I recommend the practive of never have a using namespace std in the code.
Instead typedef the types you are using. For example:

#include
typedef int_vector_t std::vector;

Thank you very much for the lecture on how to use the STL, but you don’t
seem to understand the problem. When I type this:

std::stringstream s(someString);

while (!s.eof())
{
}

The preprocessor turns it into:

std::stringstream s(someString);

// note the underscore!!
while (!s._eof())
{
}

No namespace will save you from that!

-Marco

5

“Marco Kögler” marco.koegler@web.de wrote in message
news:3DA4318A.1020007@web.de…

Thank you very much for the lecture on how to use the STL, but you don’t
seem to understand the problem. When I type this:

std::stringstream s(someString);

while (!s.eof())
… becuase eof is defined _eof you get
while (!s._eof())

Sorry, you are right. There is similar probablem in ADO COM interfaces, here
the EOF of ADO is redefined in the COM wrapper generator, but you can’t do
that with STL.

What about

#include “the file that is the problem”
#undef eof
#include

Also, it seems to matter what order you are including in when dealing with
stl and <windows.h>, so possibly a simple rearrangement of includes might
solve the problem.

Mikkel

6

MikkelFJ wrote:

“Marco Kögler” marco.koegler@web.de wrote in message
news:3DA4318A.1020007@web.de…

…

std::stringstream s(someString);

while (!s.eof())

… becuase eof is defined _eof you get

Yes, I know that. I don’t like that the win32/win32.h header has all
these #defines in the first place. It is extremely intrusive practice,
IMHO. I’d like to do something about these, but I’m pretty new to Ruby
and don’t know how the defines are used/why they are necessary? For
example, why are they exposed to client-code? I was hoping somebody on
the list might clarify this.

while (!s._eof())

#include “the file that is the problem”
#undef eof
#include

Also, it seems to matter what order you are including in when dealing with
stl and <windows.h>, so possibly a simple rearrangement of includes might
solve the problem.

It doesn’t … it can’t as long as the #define is still active in my
code, as I’m having the problems there, not in an included file. I
already placed the Ruby headers last to counter problems with other
includes.

-Marco

7

I’m guessing that it makes it easier for some extension writers to
maintain source code that’s more similiar between win and non-win
architectures. But it does sound that it needs a little cleanup.

I’d try to isolate the ruby interface portion of your code? Its not
ideal, but it’s the most expedient option.

···

On Thu, Oct 10, 2002 at 03:00:16AM +0900, Marco K?gler wrote:

MikkelFJ wrote:

“Marco K?gler” marco.koegler@web.de wrote in message
news:3DA4318A.1020007@web.de…

std::stringstream s(someString);

while (!s.eof())

… becuase eof is defined _eof you get

Yes, I know that. I don’t like that the win32/win32.h header has all
these #defines in the first place. It is extremely intrusive practice,
IMHO. I’d like to do something about these, but I’m pretty new to Ruby
and don’t know how the defines are used/why they are necessary? For
example, why are they exposed to client-code? I was hoping somebody on
the list might clarify this.

–
Alan Chen
Digikata LLC
http://digikata.com

8

“Marco Kögler” marco.koegler@web.de wrote in message
news:3DA46E93.5030303@web.de…

… becuase eof is defined _eof you get

Yes, I know that.

I am glad you do, because I was summarizing what you wrote for other readers
to follow.

Mikkel

9

MikkelFJ wrote:

“Marco Kögler” marco.koegler@web.de wrote in message
news:3DA46E93.5030303@web.de…

… becuase eof is defined _eof you get

Yes, I know that.

I am glad you do, because I was summarizing what you wrote for other readers
to follow.

Sorry, I didn’t want to overreact. I just misunderstood your post. No
harm intended.

-Marco

10

Hi,

I’m guessing that it makes it easier for some extension writers to
maintain source code that’s more similiar between win and non-win
architectures. But it does sound that it needs a little cleanup.

Yes, it should be efficient in extension libraries too. But,
in particular, eof() is never used in ruby itself nor its
standard libraries. It doesn’t exist on other platforms.

Although I don’t know about the origin since it seems to come
from Perl, it may be better to link with libcoldname.a or
oldnames.lib. Also, suspect the redefines to use functions in
win32.c are possibly done in same way.

···

At Thu, 10 Oct 2002 03:18:51 +0900, Alan Chen wrote:

–
Nobu Nakada