Slashdot Mirror
Competitive Cross-Platform Development?
Avalonia asks: "I work for a software company in the oil and gas exploration industry with a software development team of seven. Our software and development environment is cross-platform on Solaris, Irix, Linux and Windows. Most of our customers are on Solaris and Irix 64-bit systems, but Linux and Windows are increasingly important. Our environment is based around an elaborate command-line system of Makefiles controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7). Needless to say, maintaining this system and producing modern multi-threaded C++ that will go through the four build systems is time-consuming in the extreme. A large proportion of our time is spent finding C++ code that just works rather than being creative and competitive with new functionality. What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?"
"Our recent single-platform competitors (Windows only) can seriously outrun us in terms of productivity by using a single modern IDE development environment - such as C++ builder or Visual Studio - although we can scale onto larger multiprocessor Unix systems. With Windows 64-bit imminent we may lose our 'big-iron' scalability advantage. Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications."
I assume that most of your problems are in the GUI end of the equation - why not break the application into two bits? Put the numerical stuff on a grunty 8 way box, and cook up the UI with whatever language best suits the available (and hireable) skills and platform?
Communication between the two is probably best through SOAP, although to be honest I've not looked into this area for a long time. The GUI can still be built from Java (I believe Java has some reasonably fast OpenGL wrappers now), or look into wxWindows using the existing C++ resource.
Dave
I write a blog now, you should be afraid.
I've done something similar in a mixed environemnt. The way we set it up is to use java for GUI and logic development and then run a profiler against it and go native on those functions that needed it. These functions would be compiled into a library. (You'd be amazed how little of your code you need to optimize for huge performance gains!)
If I had to do it again I would do the same thing except I would use python as the 'main, relatively slow, easy to code and maintain' language.
Hajo
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
http://www.wxwindows.org/ - mature crossplatform C++ library, and not only for GUI, either.
I don't know what you need, but WxWindows and GCC cross-compiling (see mingw32 faq, for instance) might be what you need?
WxWindows also have good bindings to python and perl etc. for more rapid crossplatform development.
gcc is built for portability, not speed. VC++'s code is faster, but has zero portability and its own magical, lsd-inspired "innovations." [" for(int i=0;in;i++); for(int i=0;in;i++); ? Why would anybody ever want to compile code like that?"] That intel compiler mentioned on /. a while back sounded fast; but the gcc-for-everything approach may not be best, if they find compiled java too slow.
"Whatever happened to fair use?"
-- Duff-Man
We do exactly this in our main product (a control and monitoring system). It is about 300k lines almost evenly matched between C and C++. Portability was a major concern in its design - we've already had to port it from an obsolete platform!
;-)
We compile using gcc for unix (linux mostly) and Windows using mingw. We cross compile everything from linux and this all works from one Makefile. Recently we even managed to get the NullSoft NSIS installer working under Wine so we can make the install package under linux too.
Once we got all this ironed out we don't really have to worry which platform we are working on - "it all just works". Any developer can compile for every platform too.
We split the design into a server part and a client part. The server part doesn't do anything fancy but the client part of course interfaces with the user. We had flirtations with wxWindows [*]and GTK[*] as cross platform GUIs but in the end we decided to use SDL. SDL is very simple but it really works excellently - our application looks identical down to the last pixel on Windows and Linux. Of course we had to write our own windowing system but that is what C++ is for isn't it
[*] In our experience GTK doesn't work very well under windows, wxWindows is just too different on Windows/Unix and we couldn't (then) afford the licence fee for QT for commercial products. SDL seemed just the answer for us.
Every man for himself, all in favour say "I"
This message is outdated, possibly reflecting experience with older GCC versions. GCC 3.x is in many ways closer to ISO C++ conformance than MSVC, and it has a new x86 backend that is a big improvement over what we had before.
Sun's C++ compiler generates faster code than GCC for some cases, but slower for other cases. Sun tuned their compiler for the standard benchmarks, you will not see the gains they advertise for other platforms. In the recent pase, Sun regularly has broken binary compatibility in patch releases, leading to no end of problems for us in supporting customers.
If you need Fortran, gcc's Fortran is not great. Also, the ia64 support is immature, you will not get fast code out of gcc for that platform.
Sun, HP, and MSVC are all riddled with compiler bugs of various types; GCC's bugginess is now somewhere in the middle of the pack.
Finally, differences between compilers can often be greatly reduced by simplifying the coding of inner loops. With code that has been given this treatment, we find that Intel's compiler is only about 5% better than gcc on our large codes.
But if you do cross-platform C++, GCC can be a very good choice, as you have one set of front-end compiler bugs to work around instead of five or six.