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."
why all the different compilers?
.. but can't gcc cross compile? At least then you could dump alot of the compiler-specific scripting in your build procedures.
Hrm, this seems too simple an answer, there must be something wrong with it
"Old man yells at systemd"
Are you kidding me? They are building a real application that performs and does multi-threaded as only C++ can do. If you can't use java, what makes you think that perl, especially interpretted, would do the trick? Yeah, fine for prototyping, but how is this going to help?
...begins in wonder
...uhm...ahmmm...mmm. Dunno what to add.
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
In defense of my previous post:
As for graphics, there is a QT binding for perl that will allow you to do cross platform GUI work (and it looks nice, too)
As for speed, making C/C++ plugins for perl is not hard, and if you can break out your high-speed numerical pieces into small bits of code, it's relatively easy to call them from perl.
That said, perl isn't that slow. After you break out a few critical routines into their own XSUB modules, I bet you'd be surprised how fast perl is.
Also, perl 5.8 has very good threading support, and it isn't a global mutex around the interpreter like it is with some other interpreted languages.
...why you think you can't use Java.For all the bad press Java gets about being "slow", it is mostly old, outdated FUD. Newer virtual machines are often faster than C/C++ applications, especially in the number crunching arena. Intensive graphics are no big issue since Java now has a fullscreen API (page flipping, double buffering, and all that), a very fast implementation of Java3D, and (if you prefer) OpenGL wrappers.
Even if you feel that Java doesn't cut it for everything, apply the 80/20 rule. 80% of your non-performance critical code in Java, and the later 10& in C/C++. This solution would at least *reduce* your multi-platform woes. You might try posting this on JavaGaming. The guys over there are wizards at making Java perform with intensive graphics. (No surprise considering that some of the industries greatest performance experts hang out there.) They can also help you find the APIs you need. I'd really take a second look before you toss Java out as an option.
Javascript + Nintendo DSi = DSiCade
Java isn't an all or nothing deal. You could write your app in Java and then convert the parts that really need performance into C and call it via JNI. Then you only have to deal with keeping a much smaller C library portable.
-----
Free P2P Backup, Windows & Linux
Have you looked at Qt? It supports all the platforms you are developing for. It is primarily a platform independent GUI toolkit, but it also got a lot of other stuff like container classes (if you for some reason won't use stl), thread support, sql classes, xml classes and socket classes, all which are platform independent. It is not only just a portable GUI toolkit, I think it is the best GUI toolkit there is. I recommend it even if you're writing for Windows only. If you think of Qt more as a platform than a GUI toolkit, writing applications that run on multiple platforms (with native speed) may be easier than you think. (I'm not an employee of trolltech, although I am wearing a Qt t-shirt as I write this :)
Step 1. Go to http://java.sun.com and download the JRE 1.4.1.
Step 2. Visit http://www.datadino.com and click on "Webstart Now!".
Step 3. Right click and save Meat Fighter. Find where you saved the JAR file and double click.
Step 4. Right click and save Duke Nukes Stuff. Double click on the JAR.
Step 5. Visit jGoodies and try their wide variety of products.
If you are under Linux, I'm afraid the games probably won't perform well. (Little issue with getting X to be configured to handle high speed direct-framebuffer graphics). However, DataDino should work, although you may need to get the installer instead of using the super-cool WebStart link (Mozilla problem only!). If you don't have a database to use, visit the "Supported Databases" page and download the test HSQLDB database.
The plain and simple fact is that Java is fighting two issues:
1. Poorly written apps that give all Java apps a bad name. (For example, "genius" A decides to load a table before releasing the event thread. Table takes 5 minutes to load and user gets annoyed. The solution would have been to load the table in a separate thread so that the user can see and interact with the table items as they are being loaded.)
2. Perceived performance vs. actual performance. People see Swing and the default look and feel and instantly "feel" that the app is slower than windows. Nothing could be farther from the truth. In all reality, it is probably running faster than the Windows app, it just doesn't seem right. This is caused by the Java L&F being way too "flat". Your brain doesn't quite connect the buttons and other objects as being solid objects to be manipulated.
Javascript + Nintendo DSi = DSiCade