hi Geert,

 * Re:
   to   Peter Fitzsimmons

 GB> I don't think that's a good enough reason to advise anybody, without
 GB> further investigations, to use C/C++., Most current languages have no
 GB> problem linking with C/C++ functions and the OS/2 API calls are
 GB> exactly the same.

Linking with C++ code is a problem for every language, even for C++ itself:
it just ain't possible across implementations.

 GB> For many applications I think using an other language than C/C++ might
 GB> lead to better results and maintainability.

C was never intended as an application language, just as a high-level assembly...

 GB> But that's not the point I want to make. There are *different*
 GB> languages with their pros and cons, not only the C/C++ compilers in
 GB> Jonathans highly unofficial list ;-)

Jonathans list includes only C++ compilers, and off-handedly dismisses
products he has never seen.  Nor does he correct bugs after they've been
pointed out to him (like EMX-compiled programs ability to run in DPMI
sessions).  In short, he's havely biased to one vendor and doesn't really
care about the rest.

 GB> to worry about it. Other languages with serious advantages over C/C++
 GB> are Modula-2, Modula-3, Objective-C (clean object-model, like
 GB> SmallTalk's, unlike C++'s), SmallTalk (if you're talking *fast*

And how many Objective C compilers are there on his list? ;-)

 GB> Furthermore, if you've used some other languages than C/C++ it will
 GB> be good for the quality of your C/C++ code. 

Very true.  And the fact that no C++ code cannot be implemented in C should
be food for some thought too, IMHO.

regards,
         hugo (and much cleaner:-)