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."
You can, with some loss of performance, use GCC on all of those platforms. That would cut out compiler quirks as a variable.
Don't write Makefiles yourself. Instead write a script that translates simple build rules (foo.cpp -> foo.o -> foo.exe) into a custom Makefile for each platform. I went this route after battling for years with complex Makefile rules that never quite worked.
gcc is cross-platform, can cross-compile to different platforms, and for those who feel the need to use Windows, gcc has been ported, to the ever-popular development suite called DJGPP.
GCC
DJGPP
You are great player! Present you with points!
You don't want to use GCC if you can help it because it's performance is terrible. GCC is great for xplatform stuff, but for real power, native compilers spank it every time.
Of course, there is the extra effort of maintaining compatability, but the speed increase is definitely worth it.
[ custom app compiled with cc on solaris/sparc and aix/xlc was around 45-65% faster than gcc 2.95.1. There was a lot of data moving around, and not a lot of I/O or calculation. YMMV ]
Use gcc 3.x on Solaris, IRIX, and Linux. That way, you remove two vectors of incompatibility, and you only have to test UNIX and Windows for compatibility. And if you stick to standard C++, you shouldn't have very many problems with even that.
Of course, there are drawbacks. I doubt gcc's optimizer is as good as the native optimizers for the Solaris and IRIX compilers, for example. But you might want to try it anyway, and see if the performance hit you're taking is worth the hassle.
If you're daring, you could even try to replace Visual C++ on Windows with cygwin or ming. But don't try that until you're happy with the Solaris and IRIX solutions first.
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.
custom app compiled with cc on solaris/sparc and aix/xlc was around 45-65% faster than gcc 2.95.1.
GCC 3.2 performs MUCH better.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
If you have to use C++, then wxWindows is a great environment: it works on lots of platforms and has extensive support for platform-independent I/O, threading, and networking.
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.
Um Java??
No its not as stupid as it sounds.
A few years back there was a good article on this
in magazine that I used as the base for a system
we developed.
All user interactions as handled by a Java client
(if you prefer Python, Perl, Lisp wahtever) easy to code, easy to run wherever there is a JVM.
All your number crunching, algorithms, (back end stuff) goes into libraries that you call by
JNI. Just make sure you do not make the JNI API
too specific, try to keep to coarse, and the number of calls to it done. That is have high level of abstraction on the JNI API.
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
You aren't necessarily using GLibC. GCC works just as well with other LibC implementations, so you can use your "Big Iron"'s own LibC and LibC++.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Ant is an excellent alternative to Makefiles. It might not solve all your problems, but you should at least be able to simplify your build process quite a bit.
Apache Ant
If you can't beat them, arrange to have them beaten. -George Carlin
Why not isolate threads and files, and IPC into light-weight objects?
Sure you are going to have incompatible concepts across platforms (e.g. Windows doesn't support just unlinking an inode), but I'm sure you can find a happy subset without making too much compromise.
I know Alias|Wavefront uses a very similar concept for their Studio and Maya products. (studio looks and behaves identically on all platforms - so it *is* possible).
I've developed several multi-threaded mulit-plateformed applications using ACE. This is a very well thought out package using various patterns to abstract the vulgarities of the different OS / compilers. ADAPTIVE Communication Environment
Three things are certain: Death, taxes, and lost data. Guess which has occurred.
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"
gcc is the compiler people on linux use because its available, not because its the best.
gcc on MIPS-IRIX is just awful. gcc is the least common denominator in terms of performance and just as bad as the others w.r.t. compilerisms and peculiarties. it just so happens that if you ported your code to gcc, it would _compile_ everywhere and run in a degraded state on non-linux-x86 platforms.
so to review:
On Solaris - the sun compiler smokes gcc for c, c++, and fortran code
On IRIX - the SGI C++ compiler is almost a reference for how a good C++ compiler should be done. Oh yeah, its code generation is ideal on MIPS architectures (big surprise). can gcc even emit MIPS4 code yet ?
On Windows - well, msvc is a pretty performant compiler.
My opinions are my own, and do not necessarily represent those of my employer.
Obviously, you would leave the numeric and "immersive graphics" in C++, and link the python code to it....
:)
Leaving you to do interesting stuff _with_ the C++ components, but without having to formulate everything in C++.
Just preempting the "you did not read the post"-posts
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
Why not see what others who are facing the same issue have done? In particular, I'm thinking of mozilla, which is another C++ application which has builds for Linux x86, Windows, OS X, OS/2, HPUX, AIX and Solaris.
Yeah, they had to make their own toolkit (XUL), but I don't know if you need one (it wasn't totally clear from the question).
In particular, check out this helpful document the mozilla team made about writing portable C++ code.
http://www.talknerdy.org
While we're talking about switching languages, why not Common Lisp? It compiles to native code and has all the features mentioned (fast numerical code, vendor support for multithreading (this will likely be standardized now that J13 has decided to meet again), portable graphics (CLIM), very platform-neutral, no more rat nest makefiles - hell, no more making at all). The only downside is that Allegro CL is the only compiler continuing support for SGIs (although it also supports hp-ux, aix and various flavor of DEC unix, with no extra porting effort unless you're doing tricky FFI). If the contract is large enough, it might be possible to convince Xanalys to port Lispworks to the SGI again (I'm fairly certain it ran on that platform sometime in the past).
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Also, you can try the cross platform operating system facility from the same mozilla project.s pr.ht ml
Check out
http://www.mozilla.org/projects/nspr/about-n
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.
We have very similar needs in the medical software industry and we find RogueWave to be a pretty good solution for our cross platform C++ needs. They have various libraries (database abstraction, STL, math, etc.) which are all cross platform and provide decent performance. There is still some tweaking to be done to get all platforms to compile clean but it is much less than what we had before we moved to RogueWave.
Real-Time
Multithreaded
OO
Decent type checking.
Used by dod for safety critical/mission critical so fits well in your oil and gas exploration.
see www.gnuada.org and
www.gnat.com
I don't care so much about Java, but with Python, it's just that a lot of its cool features are also in Lisp, like functions-as-data, classes with metaclasses and the ability to define and change them at runtime, dynamic typing, docstrings, the REPL/interactive prompt, keyword and "rest" arguments to functions, ability to fix bugs without having to stop the running program, ... However, it lacks, for example, macros (don't even try to compare the power and beauty of Lisp macros to the C preprocessor!) and good native code compilers, optional type checking and a variety of free and proprietary implementations all adhering to the same standard.
As for syntax: Both Lisp and Python have the problem that people, esp. newbies, hate their syntax (the parentheses in Lisp and the significant whitespace in Python). Most people eventually get over it and even get to like it. Just because a language doesn't look like C doesn't make it bad.
You are right about the lack of easy-to-find, ready-to-use libraries for common tasks, however (not about the "standardized" part, however. Last I looked there was no Python standard.) There are some projects to change that, for example CLOCC, but there's still a long way to go.
IMHO, the single greatest problem Lisp has is non-technical. It is the (wrong) perception that the only data type in Lisp are lists, that there is no OO, or even iteration, that it is interpreted and slow, and generally dead. I'm not interested in forcing anyone to use Lisp, but I for one do like it, and if you are looking for a cool language to learn next, I'd say you definitely should have a look at it.
Programming can be fun again. Film at 11.