Howdy TonyLB
>>
With java I could just use the already build class files, one of the reasons I rejected C/C++ since I didn't want the hassle of recompiling and so on.
>>
Yes, we can at least thank sun for that, i think if MS had their way, they would have introduced constructs to tie in development done on their platform. As they do with C/C++.
>>
one of the reasons I rejected C/C++ since I didn't want the hassle of recompiling and so on.
>>
hmmmm, a nice fast processor and reasonable ram would solve that. The run speed increase is worth it. Especially noticeable on lower MHz boxes. I can remember having to do quite a lot of editing on component anchor points (x/y) with java ports to Linux from windows. Due to MS using a different window decoration concept. But that was a few years ago. And i feel MS were at error there.
One problem that does just stare out with C, is the preprocessor problem. Warned on by Stroustroupe as well. And taken advantage of beautifully by MS. The WINMAIN macro MS use is a classic example. When i first traced that to an expansion for 'stdcall', (of all things) ... i just thought wtf !!!.
But then i realised, with such a simple construct, they managed to lock in all the rad generated code generated by gui's such as the CBuilder and others to their own platform. I would think that, true evil genius, must always be as simple.
I like the gcc approach in compiling java to native (gcj) too. I hope development on that facility continues to improve with time, as java is a nice language. I don't think i could live without pointers though (grin). I get kinda suspicious of systems when they try to govern out low level access/scrutiny ... well, my story anyway

.
>>
One problem though. The additional libraries when ported to other operating systems tended to show different bugs to the Sun ones - frustrating!
>>
Yep, time time, templates are apparently getting better, (grin).
GMorgan wrote:
>>
I think Java is hyped for portability since Bytecode is unreadable and only one step from binary
>>
I was only meaning that the portability depends on a vm being available for the platform. C/C++ is a very portable language, as long as it's written with that goal in mind. Such as using 'long' rather than 'int'. As i've been taught can be helpful in endingness and 32/64 bit concerns. And it does make sense. Plus, unavoidable plate form issues can be dealt with by the configure stage of a build. I think Sun were expressing a design goal more than anything. And that goals success depends on all the other companies playing ball so to speak, as is the case with C. so there isn't a lot of difference there.
I think i must have 'goal' and 'ball' on the mind at the moment for some reason
jm