DM> Interesting... I moved away from Watcom (10.6) to EMX 
DM> specifically for C++ support.

 DN> But the C++ grammar supported by EMX is archaic, 
 DN> especially compared to
 DN> Watcom.

DM>Which version of Watcom?

 DN> In this case 11.0, but I still have 10.6 on CD. The step up in C++ support
 DN> was very major going from 10.6 to 11.0.

Right - I moved "up" in C++ grammar from Watcom 10.6 to EMX ...
Watcom may very well support a closer interpretation of the standard than
EMX does, but for my budget, I couldn't afford the upgrade on Watcom, but
could on EMX...

 DN> Does it (emx 0.9d) have namespaces and RTTI yet? If so, I might make the
 DN> effort and install it.

Namespaces: apparently not...

test.cc:4: sorry, not implemented: namespace

rtti: In the stl headers I see lots of _cast's, but no dynamic casts.  More
worrisome is:

[0] d:\tmp\src>type test.cc
#include 

class base
{};

class foo: public base
{};

int main()
{
    base* b = new foo;
    foo* f = dynamic_cast(b);
}

[0] d:\tmp\src>gcc test.cc
test.cc: In function `int main()':
test.cc:12: cannot dynamic_cast `b' (of type `class base *') to type `class foo
*'


Perhaps I've not used dynamic casting in so long that I'm not doing it
right.  However, I doubt it...

 DN> Is VAC++ 4.0 the full ISO/ANSI standard? [At least at FDIS level, which
 DN> should be fully finalised by now.]

Good question.  I haven't been able to test it, but it probably is - the NT
users would probably demand it...

DM>I seldom have any choice but to use makefiles.  Gotta check 
DM>in my code, including makefiles, and get it compiled 
DM>elsewhere.  Much easier to guarantee with manually-created 
DM>makefiles over automatically generated ones...

 DN> I suffered from that at work with MS Visual C++, and different versions of
 DN> VC++ had different support for makefiles. ... :-)

Heheh - I think we use nmake even on Windows... :-)

 DN> system software companies I
 DN> have found with decent technical support have been IBM and Honeywell.

DM>Heheh... and I've heard such nasty rumours about IBM tech 
DM>support - right up there with MS tech support.  :-)

 DN> Well, I deal with Santa Teresa more than Toronto. ... :-)

I meant IBM in general, although all of my dealings with IBM support have
been quite good.

 DN> [Sorry, couldn't resist.]

:-)

DM>Unfortunately, I didn't stick to that API set.  :-)

 DN> When is the "Undocumented Warp" book being published then? ... :-)

Heck, I'm using the same INF file that's on Hobbes!  :-)

 DN> I thought javah was supposed to produce ISO/ANSI standard C source.

DM>Right.  However, the jni_md.h file is optimised for VAC++ 
DM>... Watcom may support looking like VAC, but EMX isn't 
DM>likely to...

 DN> Provided you #define _Optlink and a few others, you should be off and
 DN> racing, unless your jni_md.h is seriously visualaged. 
 DN> Just how non-standard
 DN> does VAC++ get, apart from linkage conventions and thunks?

Who is non-standard on OS/2 for providing linkage conventions or thunks? 
Wouldn't the owner of the platform provide the "standard" for
these things?
:-)

jlong == 64-bit.  How is it typedefed?

Hopefully the same as it is used internally by the "long long" (I
think) in EMX... if you want to use the EMX functionality rather than
calling the functions inside the javai DLL.

I'm not sure - I just wouldn't want to commit to using EMX for Java native code.  :-)


---