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."
Perl? :)
Platform independent, it's highly creative, and damn if you can't prototype stuff quickly.
www.eclipse.org
I think it runs on several of the environments you mention. And I think there are C++ plugins for it.
BC
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"
Why not just use gcc for all four platforms? The sticking point would likely be Windows, but even if you elect to stay with MFC++ for Windows, you've reduced the incompatibilities from four to two different compilers.
Trust the Computer. The Computer is your friend.
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.
Why not split the platforms, and hire a few more people? I know, I know, this doesn't seem feasible, right? But if you were able to split the code into what it would actually work on, say you have yourself and joe working windows, you guys just work on windows, and have all the code that works within that ide. Jan and Sue, with help from the janitor Steve, are all working on the irix side, etc, etc, etc. It would seem more feasible than actually working all these different platforms together at once? And what about mac, is there a demand for that as well? Would be a good time to look into it...
Qt is a great cross-platform C++ environment. It's a highly polished GUI framework, but also general-purpose. In terms of cross-platform C++ frameworks, I don't know of anything that beats Qt.
Another thought is Java, of course...
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!
I would imagine that you could build a collection of libraries, using a well defined interface, with precompiled object code for each platform and tie into thiose in the mainline routines using late binding. The advantage is since you control all the libraries, the binding method can be abstracted by an API specific to your industry, and 'DLL Hell' avoided by proper planning.
This would allow smaller primary binaries, and would allow upgrading part of the project without changing the whole... also, the reusable functions can be tested using known results from other platforms.
The less you have to recompile for each change, the easier the Makefiles etc are to maintain.
You can have it fast, accurate, or pretty. Pick any 2.
clr
...uhm...ahmmm...mmm. Dunno what to add.
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.
Java. Java, more Java.
www.sun.com
Java
I have to support C++ on Windows, Solaris, Linux, HPUX, and AIX. I feel your pain :-) One thing that helps tremendously is something like tinderbox from the mozilla project. It does continous builds and integrates into the version control system so you can find out when someone broke the code quickly rather than the next day. Its also good to come up with a list of C++ features that you wont use. Mozilla.org has a list that you can adopt if you want, but its probably a little more draconian than you need. But do develop some sort of programming guidlines that say (you cant use c++ feature X).
Working for an industry that isnt helping to destroy the world?
Why stick up for big business?
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.
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.
All Windows productivity oxymoron jokes aside, how do you go from most of your users being on Solaris and Irix to thinking about going Windows only?
Erg...I just saw the second part of the article, after the ad. That was annoying. Maybe it's time to sign up for a subscription.
http://www.boost.org
besides, do you really think it's the IDE that makes your competitors more competitive? I do crossplatform day in day out, its NOT THAT HARD
Why not do what a great many other people do (though I have a feeling that you may be doing this already), and target a specific platform for initial release, and then release on the others afterward? This allows you to focus on the platform that gives you the most bang for the buck, but still keep your scaling advantage. If you already have an established product/development environment, then you should already know enough to keep from doing any of the "big mistakes" when it comes to writing portable code. Plus this allows you to divvie up your engineers into functionality vs porting.
Another thing would be to standardize on say, gcc. since the source is available, you can do whatever tweaks you need to to get around any performance issues (I know, easier said than done). Then standardize on things like configure.
Have you thought about writing a simple make like tool that either generates nmake/gnu make/ant makefiles or build commands? It takes hardly any time if you use something like Spirit to handle the parsing.
Presumably you're already using something like boost? I found it sped things up no end once you get used to it.
I would suggest first using gcc on all UN*X platforms, and also trying out something like ant instead of the various forms of make you're dealing with now.
Also, have you considered using a library like Qt to handle most of the porting details? It's not free, but it is good if you can deal with it's oddities (I personally consider preprocessing to be evil).
Good luck.
-30-
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
this topic (if you haven't read it already). The basic idea is to break out all parts that don't work across the different platforms into their own sections of code (classes/interfaces) assuming you aren't doing that already. Then when you do updates (that will hopefully work platform independantly) you can just right those sections once. Pretty obvious but I have seen so many places with this same issue who actually have completely seperate code bases rather then breaking parts out.
.NET CLR's for all those platforms.
Unfortunately if you are already doing this then you are probably screwed unless someone releases
controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7)
Couldn't you just use gcc across all systems? There are also plenty of opensource IDEs around. We use
Eclipse along with ClearCase. Very good for cross platform.
-- main(s){printf(s="main(s){printf(s=%c%s%c,34,s,34
Qt from Trolltech gives you a cross-platform GUI library, that creates applications looking natively on each OS (Windows, Mac OSX and GNU/Linux).
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
Instead of different makefiles for each compiler, why not write wrappers for the various compilers to give them all the same interface? Then at least for compiler invocation you could have the same makefile for all four platforms, just set CC=cc_wrapper which is a shell script (or .cmd script on Windows, or Perl or whatever) which mangles its command-line options into whatever weird syntax this platform's compiler expects.
With more fundamental issues like differences in the code accepted by different compilers, you can use #ifdefs in the code, which is not elegant but probably much better than makefile hacking.
Some suggested switching to gcc on all platforms, but then others said it might produce slower code. Well, you won't know until you benchmark. It's possible (just) that you might decide to compile most of your object files with gcc, to eliminate most of the compiler-specific hackery, and just compile those parts of the program that are speed-critical using the native compiler. This assumes that the object formats used by gcc and the native compiler are compatible, but in principle there's no reason they shouldn't be. (Perhaps not in practice, but give it a try.)
-- Ed Avis ed@membled.com
Mod this up!
Maintain the server that does the complexities, and all you need is a Java client that talks to it. The Java client handles the multiplatforms, and the C++ backend does everything efficiently on a server.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Check out the latest edition of OilIT. Applications like this are why Fortran is still a very popular language among those who use computers for numerically-intensive work. Fortran9x is so easily portable, its not even funny. Bindings exist for all of the major threading standards (OMP, MPI, etc) and it is FAST. Further, is there any language with a better selection of libraries available for number-crunching? I doubt it. Develop your 'work' code in Fortran, and your front-end in Java. Both highly portable. The interface between the two will be platform specific, but this will only be a small portion of the total project & much easier to maintain than the large #ifdef heavy project you now have. $0.02
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.
What you need to do to work with the multithreading issues, etc with the multiple systems is create your own primitives that you need, instead of using the vendor supplied ones. For instance, MSVC uses CRITICAL_SECTION whereas cc will use a mutex. The behavior of these are significantly different, but similar in function. What you need to do is create a class that acts as a Mutex, and implement this class differently on the different platforms. Then, in the code where rapid development counts, your Mutex can be used with no regard to platform differences. Do this for all platform dependent things suchas interlocked integer functions, thread creation/destruction, network functions, etc. Use the std lib to wrap some differences, such as file access.
Just add more people to your team! Double! Tripple! GO WILD WITH NEW RECRUITS!
Sheeesh, some people never learn...
Belief is the currency of delusion.
I work on remote sensing GIS software.
Our software compiles and works under Linux (gcc), Windows (VC++ 6) and Solaris (gcc). The code base in the past has also worked on IRIX (???).
We've had good success using Qt for cross platform libs and GUI and jam (http://www.perforce.com/jam/jam.html) for cross platform builds. I do all my development under Linux and very occasionally cross compile on Windows (couple of times a month).
I'd also suggest getting Purify for one of the platforms or HeapAgent (www.microquill.com) for Windows. I've looked at some of the linux based checkers but they are dog slow when matched with Qt. HeapAgent just flies for checking....
Take a hard look at Qt, I think you'll see that its the solution with the least overhead.
t ml
They even have a case about a company like yours that had a similar problem. Take a look.
http://www.trolltech.com/products/success/pgs.h
Take a look at these sites:
Squeak (Apple's Implementation of Smalltalk-80)
Smalltalk/X from Exept Software
Cheers!
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).
Windows Only, perish the thought. Not that Id condone it....but one must assume certain falacies when one assume windows only.......
Bill Weber Linux Admin/General IT contractor 735 Dover Street Marietta GA 30067
I've heard good things about the ACE/TAO cross platform library. From what I've heard, it has a learning curve, but it adds a very strong layer of abstraction over top of the operating system services (network, threading, syncronization).
/
ACE/TAO are open source and will build on a number of platforms with a number of compilers.
Overview:
http://deuce.doc.wustl.edu/doc/RandD/TAO/Overview
Consider migrating your Makefiles to .aap files.
A-A-P may not be ready for the task yet, but as it matures, it has the potential to replace Makefiles entirely. See the multiplatform example.
A-A-P Homepage
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
...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
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.
that your Java excuses are bull shit propaganda. My company has built an application that has to proccess numerical values at incredible speeds and in real time and we were advised that C++ would be the only solution. Well we decided to use java and have not had any preformance problems what so ever. But in answer to the your general problem. It sounds to me like your lack of initial architecture is what is killing you. You need to rethink the architecture of your app and put code into the appropraite layers of that architecture. Every time I hear about a problem proting to multiple systems or tweaking code because of compilers, it just screams architecture redesign.
I like things that are sweet and not things that are lame. --
Hi,
The OpenOffice.org project builds from one source tree on Windows, Linux (ppc and x86), Solaris (Sparc and x86), and has FreeBSD, NetBSD, Irix, MacOSX coming
soon and the codebase in question uses C++, threads, STL, component technology, etc.
Kevin
The problem you're facing is exactly what Cygnus
Solutions was created to solve. They were bought by Red Hat 3 years ago, but the same people are still there doing the same thing. Go to the Red Hat website and search for "gnupro".
A virtue in programmers is laziness well applied.
The easiest way to be lazy is to make use of
someone else's work. Best of all is if it's free.
The Adaptive Computing Environment
has already done most of the heavy lifting in terms of cross-platform stuff. Free as in beer, free as in liberty.
mmmmm, turbo pascal....
What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?"
Java.
Whomever said Perl earlier is an idiot.
If you are not experiencing performance-constraints, why not use another language?
:)
Personally, I would think that if rapid development and market response is very important, you should probably select an interpreted runtime-typed language... which gives you minimum hazzle when changing desgin, arkitecture and most importantly: implementaion.
One language that would spring to mind is python
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
It sounds like you could make use of ACE the Adaptive Communication Environment. C++ wrappers for portability and cross platform developement of high-performance distributed real-time multi-threaded concurrent yadayada applications.
Why make when you can JAM! Jam will take care of all of this for you. You spend time creating your rulesets for all your different platforms/compilers and all anybody has to do is type jam to build, regardless of what they are on. I use (and have used) Jam for this purpose and currently use it to build .net C# apps and assemblies using MS command line tools. Previously we used it intensively to support C++ on both GCC 2.95 & MSVC 6.0 on Windows, Linux, and Solaris.
Just rewrite all your makefiles for gmake - which is cross platform and can use any compiler and use one of these libraries (ACE or Rogue Wave) along witg STL - and you are set.
I've done this... it works...
The GOF book gives an example of using the Bridge pattern to provide a platform-independent interface to a GUI api.
Disclaimer: I don't have any real-world experience with the Bridge pattern, so I can't say how easy it is to make work, or how it performs in performance critical situations.
150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
I can't believe I'm providing free advice to a proprietary-software company, but here it goes.
If your advantage is "big-iron" scalability, stick with it. Often it takes a lot of effort to make little effort, so changing your toolset will require substantial effort. The result of the change will be a substantial reduction in effort. If your needs change to Windows, you will nonetheless have a Windows port.
Here's the direction I recommend.
1) wxWindows (uses per-platform native graphic libs)
2) automake/autoconf (very nice for dependencies)
3) gcc/cygwin on all platforms (change to higher-performance compiler as an experimental afterthought only)
4) IDE - find one, no suggestions available.
Torsten
I've seen a few shows on TV recently that featured some really wicked looking oil and gas exploration software. Stuff that let geologists view layers of terrain collected by seismic data in 3d, moving around in realtime... If that's the kind of stuff you're into, I can understand why java isn't an option for display right now.
However, java is exactly what you need. You can scale it across processors on the big iron or run it on the desktop without recompiling.
Have you considered only writing your display logic in C++ and using java for the backend number crunching? For raw floating point math, I've read that java is barely slower than native code at this point. It's my understanding that talking to the OS so you can get to the hardware is where you take the major performance hits using java. If you could do your raw crunching in multi-threaded java code, you could then deliver the data through one of many different mechanisms to your display logic and have that be the only code that you need to port from OS to OS...
Another thing you could possibly look at is licensing 3rd party libraries made for cross-platform development. From your post, the only thing I know you're definitely having trouble porting is thread-related code. I'm sure there are multi-platform threading libraries for C++ out there somewhere.
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 :)
How about having a process running somewhere on each of the platforms that checks out your source, compiles it and runs some tests against it. As soon as it finishes it checks out a new tree, compiles it, and checks it again.
The advantage of doing this is you have near instant feedback if something you did broke on one of the platforms. This means that fixing problems becomes much faster. And, if your scripts email everyone who checked in since the last automated build then only the people who "caused" the problem get bothered.
You can also use this to track various metrics, such as performance, and produce pretty graphs. You can easily see which commits caused your program to start taking twice as long.
I've seen this used successfully in many software companies to keep their outstanding bug counts down and to keep people moving toward their goals instead of being bogged down fixing integratration issues.
You might want to look at the rest of the ideals in Extreme Programming, such as Pair Programming, Project Velocity, User Stories....
checkout java bindings using jni to native code to opengl. it's fast and portable and lgpl:
http://www.jausoft.com/gl4java.html
In terms of backend development, if Java isn't fast enough for you then look at how some popular open source projects manage cross-compiling.. Look at their ideas and learn.
Automake and autoconf can, as you imply, improve portability. Unfortunately, they can also completely destroy build reproducibility: add something to a PATH or install an additional library, and watch as your software gets built with completely different requirements than the previous build.
I'd stay away from autoXXXX for software that's not distributed as source.
:: "I am non-refutable." --Enik the Altrusian ::
PARENT IS SERIOUSLY ON TOPIC!
L4M3Rs
L4M3Rs
L4M3Rs
L4M3Rs
L4M3Rs
L4M3Rs
Yea, I know that everyone here has said it, but use gcc. We do here and the ease of just having everything work more than makes up for any speed loss. We use Windows/Linux/HPUX.
Libraries are written in C so that, if we have to, we can easily compile them with native compilers for special cases and not have to worry about a specific platform's C++ quirks.
Most code between the two of these are compilable in both, unless you are using older 5.x Irix machines that dont have pthreads. Only a few ifdefs are needed, mostly around things like devices.
Few key things, all comunications between the two of them use xdr functions to maintain correct values between components. For example, we have a lot of udp traphic between 3 programs which can be compile in Irix or Linux. The send/reception routines have all the values go though xdr so I dont have to worry about the big/little endian problem. Use of ifdefs that are based on which operating system you are using can catch the very few big differences between the pre 3.2 Linux gcc and the CC Irix compiler.
For graphical, geological, and geographical displays, have you tried INT? They sell various libraries/toolkits to do all this display stuff for you (graphs, seismic, contours, well logs, etc), and specialise in the oil industry, but also sell to other industries. Cross platform C++ (most Unices & Windows, even WinCE), and Java.
http://www.int.com
If you're staying with C++ cross-platform GUIs, X-Designer isn't bad. Not a patch on Visual Studio, but then Visual Studio isn't very cross platform.
For source management, there are lots of tools. I've only used the SourceSafe family and Perforce. Perforce was the better IMHO.
RB
I've had some experience doing just that. To date, Qt is the most mature of those and will give you uniform access to GUI, networking, threading and even database access for Win32, Unices (including Linux) and MacOS.
If you aren't so worried about GUIs but need to output multimedia contents portably, SDL is a viable alternative. The portability of some of the more esoteric components is dubious but SDL has the distinct advantage of being completely free.
As for performance concerns some people have raised about archaic versions of GCC, don't let that stop you-- even if you don't use GCC 3.2 (which produces very good code) the subtle improvement is speed is very rarely worth the greatly increased complexity in development and maintenance.
Besides, with recent GCCs I'm hard-pressed to actually find any significant difference between code generated by it and other compilers (for IA32, anyways, and with all relevant optimizations turned on).
-- MG
- First, Qt (www.trolltech.com) is awesome. High performance, excellent portability (including all the UNIX platforms you mentioned, plus Linux/Windows/MacOS X), legacy integration (with Motif, etc.), multithreading, etc. There are also third party toolkits to integrate more advanced visualization into Qt (http://www.trolltech.com/company/announce.html?Ac tion=Show&AID=108).
Nowadays, Qt doesn't just handle GUIs. It also includes networking and threading abstractions, with really nice object oriented interfaces to them.
- Second, think about what IDE features you're looking for. If it's a GUI builder (which seems doubtful, considering that you probably spend a lot more time writing visualization algorithms than dialog boxes), then you could use Qt Designer.
But, if you're more generally interested in project management, integrated debugging, and source browsing, I'd suggest you take a look at Visual SlickEdit (http://www.slickedit.com), which integrates all those features into an amazing, cross-platform IDE/editor.
Good luck!
--JRZ
Advantages:
Try QT from Trolltech . It is a C++ based applications framework. It has a visual form/screen design tool, and then you build your app using makefiles and the C++ compiler of your choice (G++ works best). It is open source, but you need ot buy a comercial license if you want to sell the result.
Supported platforms:
Any X11/Unix system (Linux, BSD, Solaris, etc).
Win32
MacOS X (Aqua -- you can do X11 development under OSX with the unix package)
I use it a lot, it is a very good package. KDE is based upon QT, and it is also the underpinnings for Borland's Kylix , which is basically C++ Builder for Linux, and also the newest versions of C++ Builder and Delphi.
If you just need Windows and Linux targets, then Kylix/C++ Builder is a good choice, I'm sure that being based on QT, Borland will be offering Kylix for other Unix platforms too.
It's amazing how many things you find this way. It actually a good way to find many bugs as well. Since we've been doing this a while we also decided to avoid a lot of the "newer" C++ features and that really helped both speed and portability. (Since not all compilers did STL well for some time)
Trolltech's (Qt) Qmake is a verypowerful meta-make system that does this very well for all platforms/compilers mentioned and many, many more. I couldn't imagine doing a crossplatform C++ project without qmake.
sHi
Cross platform STL/string/iostream is quite easy, actually: STLPort
I don't trust compiler vendors' implementations being threadsafe.
Just curious - is GCC's std::string threadsafe across all platforms yet? It used to have some serious problems.
If you definitelly need speed AND flexibility, I'd write the main application logic and GUI in full Java, then profile the application to find out those parts that really need to be accelerated, and write those as C++ code (you'd be VERY surprised at how easy it is to do this with Java; your Java code wouldn't even know that it is calling C++ code).
Give it a try, that way you can use only one IDE for all of your code (NetBeans, Forte, JBuilder, Visual Age, are all good tools).
Portable to all kinds of unixes, windows, mac, etc. Supported to some extent.
Very widely used in biotechnology community.
All the stuff is open source and is a "public property"
Makefiles management included.
http://www.ncbi.nlm.nih.gov/IEB/ToolBox/index.cgi
My initial reaction when reading your posting was of course Java - but of course - that would require a complete rewrite, which is out of the question. A decent rule-of-thumb is that a rewrite takes as long time as it took to get where you are now, despite the initial thought that "this time we make it right from the start".
The second alternative is to minimize the number of compiler versions used. Standardize on one that is available on all platforms (gcc comes to mind, since it can be run on most platforms, including windows). The platform-specific code probably needs a specific compiler, though.
However, if you manage to standardize more code than is currently being done on one compiler, it is also an indication that it really isn't platform-specific.
Thirdly, new applications might be written in Java, utilizing the JNI to get access to already written libraries. However, this would add one more configuration to test the libraries against as well, so it might even turn out to be counter-productive.
The fourth step is the step your customers don't want you to take; drop your support for the least used platform - or make sure you charge enough money to pay for the additional cost of supporting that platform - or the platform which is hardest to support, with "dedicated" engineers that provides "fixes" for that platform only, letting the main engineers focus on the main platforms.
Why not take a chance and refactor the entire process, not just the code? How on earth can you justify that many platforms with a common code base? If you calculated out all the additional costs and quality issues with supporting such a monstrocity, would it just be more cost-effective and improve the customer experience to change the product and make it only on 64-bit platforms? Just *nix? Is anyone asking these real business issues? They are the most important to ask first. Then, we get into the code parts.
IMHO, if you still had to support all the platforms, I'd take the opportunity to radically change the concepts. Use a common C++ code set for any core objects that you use in the business. Make sure that the abstractions sit around any errant issues you really have with 64-bit code (data size requirements?) Also, just be honest with people. Be willing to sunset platforms. Don't try and be all things to all people. You need to position such a change as for quality and form improved stability.
I'd then take the entire set of UI functions and write them tailored to each platform. Again, and IMHO, cross-platform UI never makes anyone happy. The dev's complain about the complexity, the users complain because it's not quite right, etc. etc. So just don't do it (I like QT, but QT on Win hurts.)
Lastly, I'd create a client/server construct so that you can optimize the back-end and front-end operations. That way, should you want, you can run on one system, or run a client/server set. That's what web dev's do all day testing out on their local systems.
(Now, if I can just find the time to get my website done...)
...tizzyd
I'm guessing you'll get plenty of suggestions to change your language, which is certainly something to consider if you have that option.
But if you're like me, you don't have that option. You've got a load of C++ that's not simply going to magically transform into Python or Java overnight.
I would suggest the hard road. Boil down supported standard features in the compilers that you can use and tell people to stick to that list unless they can make a case that all of the compilers now support the new feature that they want to use.
Although I feel it is dated now, Netscape used to publish such a guide for their developers.
For example, in our early days, we would not permit namespaces or RTTI.
Now, as compilers have gotten more supportive of the ISO C++ standard, we permit those features in our codebase.
But we haven't yet decided to open the floodgates on exception handling, although it's supported pretty broadly.
Finally, you really need an automated build system that runs the latest repository snapshots through the compilers on all the platforms and throws the results up on a web page, like Tinderbox.
That will tend to enforce good standards as developers will see that their check-in attempts fly through with green and no warnings, or get dirty yellow about warnings, or red with downright errors during the build.
"Provided by the management for your protection."
I developed and maintain a cross-platform C++ project (http://jace.reyelts.com/jace) which has roughly 10,000 lines of code and supports Windows, Linux, Solaris, HP-UX, AIX, and MacOSX.
My experience is that writing any sort of complex C++ code (especially that which involves templates) is nightmarish due to different levels of standards conformance, support, and interpretation - not to mention plain old bugs. For example, Jace has to jump through hoops to get around bugs with virtual inheritance in some compilers, and differences with respect to template specializations and the ODR. Every time I make a change to Jace, I immediately have to rebuild on several platforms, for fear that the compiler I was using was lax and let non-standard code compile or for fear that one of the many other compilers won't correctly compile the code.
I think that if you were to take the time to profile your application, you'd find that the old 90-10 axiom applies. I would suggest that you write that 90% of your application in a highly cross-platform language like Java, and the other 10% in C++. With Java, it's virtually impossible to write code that is rejected/accepted differently on different compilers, and you have access to an excellent cross-platform build tool - http://jakarta.apache.org/ant/index.html (Not that you would need to build on more than one platform). You'll also find that the Java compilers are essentially bug free. A task that is much easier to achieve with Java, considering the language is so much simpler than C++.
The next version of Visual C++, Everett, due out in 2003 and is supposed to offer increased ANSI/ISO standards compliance and UNIX/Linux compatability. The enhancements over Visual C++ .NET (7) seem very attractive and might be able to aid you. You can check it all out at:
MS Developer Tools Roadmap
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
I said this somewhere else in this message tree, but I want to say it near the top where you will definately see it. If switching to gcc on all platforms isn't feasible for any reason, then qmake is definately the answer to your building nightmares. qmake is a meta-make system that creates makefiles for many-many platform/compiler combinations (including all the ones you mentioned).
qmake allows you to write one project (.pro) file for all platforms. qmake then creates makefiles for any of its supported platforms for you. It takes some getting used to, but it is very powerful and I couldn't imagine working on a cross-platform project without it.
qmake comes with Qt, so you'll have to pay to use if for commercial use, but developer liscenses are reasonable (probably less than $20k for all seven of you). Actually, you may be able to use qmake for free, but other portions of Qt would definately come in handy for you as well -- especially if your application has a large GUI component.
sHi
I write code that works perfectly on Win32, UNIX, OSX, and everything else every day. Just stick to C, and you will have no issues at all. The SECOND you touch C++, you will have problems. It really
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
We are a games shop moving from single platform development (PS2) to multiplatform (PS2, XBox, PC, GameCube).
We have one codebase and are using gcc on the PS2, msvc6 on the PS, msvc7 on the XBox and CodeWarrior on the GameCube.
It makes things..interesting.
The approach we have gone for us to use a multiplatform kernel that handles the filesystem threading, memory allocation, various resource handling, error handling and user input. Not having to support as much in the way of user interaction as the average GUI app probably helps.
We can plug machine specific renderers into the framework by creating them as singleton objects.
Basically we try leverage the 80%/20% rule and make the 80% rule multiplatform and the 20% single platform - one for each platform. It's a lot of work, but it's the only way to get the speed needed.
The 20% bit is implemented via interfaces. For each major function (rendering, physics, sound) a singleton is created that implements the interface for the specific platform.
Ninja source control also helps. CVS sucks. Source Safe sucks. Actually, nearly all source control software I've seen sucks for this kind of thing in one way or another. It's just too easy for a coder on one platform to check in code that breaks on another.
For instance, CodeWarrior complains if you have a ";" after the closing brace of a namespace, none of the other compilers do. And Codewarrior is following the standard! Arrgh!
Compile with warnings at the maximum level, enforce warnings as errors, which makes compilers ultra picky and a pain to work with, but often causes them to pick up non-standard code that's going to be a problem for the other compilers.
We are trying to get to grips with NxN Alien Brain, a source control package where almost everything is scriptable. This may help. It may not even suck, but it's geared to games which have huge non - code related assets to deal with as well as code. Hmm. Maybe you have a similar problem with survey data. I know AB is being applied outside of games in the simulation field, so it may be worth a look.
/usr/games/fortune > ~/.signature
using autoconf might help you out
I have written many cross-platform projects in C++ without a problem. All I did was identify low-level platform dependent issues and encapsulate them within subroutines, typedefs & #defines etc. Then write software using regular C++ code and use portability library. Example: typedef unsigned long PORTA_PID; // This function returns the current process ID.
PORTA_PID getProcessID(void);
As a previous respondent said, GUIs are a different matter. I would suggest to standardize on one GUI environment such as Java (or even MFC) and split the functionality so the GUI was a thin shell that communicates with the main business logic that exists in other C++ processes.
You don' need no stinkin' tools, the amount of code required in the portability library is very small.
That's my 2$. I'm worth more than 2c (just).
I am graduate student, and as a part of my masters thesis, I am involved in the development of a behaviral modeling environment . We are using the programing language python, and the GUI toolkit QT and PyQT. The choice of these technologies has made our tool fairly generic as it runs without a glitch on Linux, Solaris and win2k. We have not tested it on other platforms but it should work on all the platforms which run python. Python is a really cool programing language and PyQT makes cross-platform GUI development really easy. We have developed fairly involved GUIs using PyQT, like a Topology Editor, Schematic Editor (to capture the design and topology of circuits) etc. I would strongly recommend python and PyQt to someone interested in developing cross-platform applications (with GUIs)
I don't understand why people even look at Makefiles anymore now that Ant exists. We've completely automated all of our builds and deploys across NT, Linux and Solaris with it, across different architectures and different locations.
I'm not going to expound on using Java, since it is fairly ubiquitous these days and if it would work for you, I'm sure you would have already considered it.
Delphi, C++ Builder and Kylix, together with open-sourced Interbase/Firebird database, make a perfect suite for cross-platform RAD development.
It fits everyting you need to do. Multi threaded, stable, and most of your clients are on solaris anyway.
It is quite suprising that you even have to ask.. or you simply already know the answer and jsut don't want to.
Here we have to develop a big tool for multiple platforms (lukily all Unix). It would be possible for us to use only gcc, but we decided to use two different compilers (gcc, IRIX) so that we can find compiler specific errors more easily.
We found that this is a good policy to decrease complexity (even though it may look counter intuitive)
I have basically the same question and have been thinking about Kylix/Delphi solution. Anyone with experience here please post some thoughts. No troll, just haven't had time to explore it yet. TIA. RAD is very important and Linux/Win are the most important OS's to me.
`for(int i=0;in;i++); for(int i=0;in;i++);' is the right way accounding to the c++ standard, the wrong way is `for(int i=0;in;i++); for(i=0;in;i++);'
Interesting. It makes sense that gcc is optimized for portability, but how much slower is it than VC++?
If the user chooses to go the VC++ route because the code compiled is faster than gcc then he will need to spend about $800 for each Visual Studio workstation. Alternatively he could save $800 bucks per developer and invest that money in faster hardware. Plus save programming time because he is able to target only one compiler's syntax.
Without seeing your app, I can't really tell how feasable it is, but more and more stuff is going the direction of 'thin-client'. If you rewrite as a web-based app, you could move to two platforms (Windows and "RedHat" Linux).
Sell a preconfigured server for an extra 5 grand.
And for those sites that refuse to install either one of the platforms internally, charge them to access an 'extranet' farm of servers working of https.
Check out ACE (adaptive communication environment)... C++ libraries which are cross-platform (ACE support WIN32, *NIX, Os X, BeOS, many RTOSs, etc), it is fast, the american military uses it... etc, etc, etc... do a search on google - it pops right up... Have fun....
You're joking, right? Perhaps I'm a little behind the times, but I was under the impression that GCC used a register based architecture where VC++ uses a stack based architecture. While GCC might spit out some average performing code with the default options, using -O3 will produce very fast running code. I've compared the performance of code compiled with GCC vs. the same program written in assembler, and at its best, GCC is only 50% slower than hand coded assembly, which is very good considering that some very well respected compilers will produce code that is 10 times slower than hand coded assembly.
I've also looked at the assembly language output of VC++, and it's a joke. VC++ often inserts large sections of extraneous instructions into the code. I've managed to follow function calls in VC++, and it is not uncommon for a function call to have prolog and epilog code of several dozen instructions. Interestingly, GCC uses a register based schema, and I can actually follow the code pretty easily, in spite of the fact that it uses the AT&T syntax. GCC just produces cleaner code.
The society for a thought-free internet welcomes you.
You could use Mozilla as your application framework for the front end as they have already worked on the cross platform issues. Then, link to your own specialty libraries or use the NSPR libraries to handle your datatypes.
What is wrong with the second example? i would have to be declared previously of course.... but what's wrong with it?
VC++'s code is faster I believe the contrary. Evidence?
Have you considered java? Sounds insane, I know but Java3D seems to be coming of age and I've seen some pretty impressive large data visualisation demos written in it. It saves you a lot of headaches with cross platform development issues.
I realise that most people think of Java only as a server side technology but Sun has been putting a lot of effort into making it more appealing to the scientific programming community. You should really give it another chance.
Yours truly,
You know who, eh? :-)
Your pizza just the way you ought to have it.
...although maybe on a smaller scale. I am building a monitoring / control application for the space industry. It currently stands at 160,000 lines of C++ (and only C++ - there is no trace of C or of any scripting involved), and works just fine under HP-UX (with aCC), Linux (with gcc), and Windows (with Visual C++).
;-)
One thing that has hit me was the differences in the various STL versions (the one with aCC is rather old and differs significantly from the others). A solution is to use your 'own' STL - just standardize on one and use it on all the platforms you support.
Another difference is graphical output between X and win32. This I worked around by having a sufficiently powerful abstraction layer; writing it was actually surprisingly easy. The major advantage is having applications that are 99% identical no matter what platform they run on. The major disadvantage is having to write all of my own controls, and occasionally running into differences in the event model.
As a rule I try to keep my #ifdef as deep down as I can. I will only allow #ifdef in libraries; never in applications. This limits the damage done by different platforms to the library code - still a significant chunk of code, but already far less than the entire project.
I have one file that attempts to compensate for all compiler quirks. It contains most platform-specific #includes, defines types available in some runtimes but not in others, contains required pragma's for each compiler, and #defines commonly supported (but differently named) functionality (for instance, strnicmp ()) into a fixed, essentially project-specific naming system.
I will just about never call _any_ OS or libc function directly. Instead I will always use an indirection layer in one of the libraries. This gives me three advantages: I can subtly modify the interface to the function (for example, to allow better type checking); I can use exceptions for error handling instead of returning error codes; and I can compensate for platform differences.
On the whole I found developing for three platforms at the same time challenging, but not impossible. It certainly helped keep my code clean of platform-specific unpleasantness, and by extension simply clean. Obviously more care is required than if you are supporting a single platform but a competent programmer will have no trouble doing it.
Someone else suggested having a person per platform. I strongly suggest you do not do that, since this will tend to increase divergence between platforms. Instead, appoint someone who is responsible for the entire abstraction layer across all the platforms. Make him the only person who can call OS and libc functions, and have him write proper and useful C++ interfaces to whatever you need. Then write everything to run on that layer.
It is not necessary to first have the entire layer up and running before you can use it. If you are starting with existing code, just make sure you have some idea of what your abstraction layer is going to look like and then simply add code whenever you need it.
Whenever you abstract some function, be sure to take the time to replace _all_ occurrences of that function, and one day you will come into the office and realize you have become 100% platform independent.
One final tip: Visual C++ actually supports the forward slash as a directory separator in #include directives. It sure helped me clean *my* code when that was pointed out to me
While I'm not officially responsible for the build process at my workplace, I've taken that responsibility as we've been porting our code to a new operating system. Here are some things we've learned that may help you.
We recently switched from Make as our build tool to Jam which has worked great. Like you, we didn't have the option of using GCC on every platform, and Jam made it easy to configure all the operating systems we're interested in using with the fewest headaches. After using Jam for quite a while now, I think all of the developers and I are very happy with the decision to axe Make. Honestly, I can sympathize with your effort to use Make to do all your compiling since we gave it some effort before switching to Jam. Try Jam - you'll be amazed at how much simpler your build process becomes.
Whether or not you use Jam (though we use Jam to do this), setting up nightly builds, capturing the output, and sending status emails with the results makes bug finding much simpler, especially on multiple platforms. Part of the nightly builds include built in testing. If any of the tests fail, we know we've broken something in our code.
Another suggestion... Look for a threading wrapper package like CommonC++ or ZThreads. Both are fairly well developed now and make programming multithreaded applications for multiple platforms pretty easy. For multiplatform GUI tools, try FLTK. It's tiny compared to WxWindows or other bloated GUI wrappers, plus it's easy to use.
"Corrupting our youth one mind at a time"
I've worked with it quite a bit and I must say it is wonderful.
Presently it supports Windows, Mac OS, Linux, and BeOS. A little work would be required for Solaris and Irix - it has a small amount of assembly to do atomic arithmetic, that's used by the reference counted smart pointers, but that should not be hard to do.
I have started writing a tutorial called The ZooLib Cookbook.
Request your free CD of my piano music.
The problem is that i is declared within the scope of the for loop, which means it shouldn't be available outside of the loop. With the second example, even though i is declared in the for loop, it's declared outside of the scope of the loop, which is not what C++ says should happen. (IIRC, that's how the standard used to be a long time ago, and then the standard changed. It's hard for a compiler written before the standard change to support the new changes in the standard ...)
I do not know why noone considers Java as performant.
.NET is language-independent, supposedly platform-independent, being an open standard and all, and performant, as its compiled and not runtimed.
I have a few words / acronyms...
1. JIT. As in Just-In-Time compilation. Meaning Java software approaches native speed as time goes on.
2. JNI. As in Java Native Interface. Ok, so you have a couple C++ libraries that really have to be as fast as they possibly can be, without necessarily incurring the wrath of the platform demon by being written in assembly. That doesn't mean that the 90% of your code that doesn't vastly effect the performance of your system ALSO has to be written in C++.
3. Silicon. As in what chips are made of. Including chips that run Java. Though these are really targetted at the embedded market, to have your coffee machine run Java or whatever, a high-performance version is available. It plugs into your PCI bus. And runs Java there instead of in the main processor.
Oh, not exactly on-topic, but insert obligatory note of how
I am disrespectful to dirt! Can you see that I am serious?!
I don't know if the original poster meant managing their current codebase of C++ or going for something new.
:)
But if productivity is a factor, one should seriously look into Smalltalk.
A few URL:s to have a look at:
www.whysmalltalk.org
www.cincom.com (VisualWorks Smalltalk)
www.squeak.org
www.exept.de (Smalltalk/X)
Squeak is certainly cross-platform... it's difficult to find something it doesn't run on
VW is less portable but fater and commercially supported. Also more expensive.
(There are other not-so-cross-platform dialects.)
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
Use GNU make on all platforms. Don't try to write makefiles that work with whatever make incarnation is available on each platform. And make sure you read the documentation on GNU make till you really know what a powerful tool you have at your disposal!
Go out and download and install Java's sdk. Also, take a look at jama.
All this talk of gcc for cross platform. If he's writing code that requires all that big iron, he's using c++ [or c - arguably faster, but nastier] because he needs that speed. Thats why he is using native compilers, and not compiling in compatability mode.
To help with the complexity of building, try ant. Ant is great.
Dont even mention using assembler for speed.
Yay me!
You need five essential tools.
Qt is all you need to build your UI. It is also all you need for a decent, dropin STL replacement.
Fortran is your language to make things fast. Unfortunately, this is a weak point on Linux. But I would give Intel's compiler a try.
Gcc is the only C++ compiler you need on all your Unix platforms.
MSVC6 or MSVC not.yet is your choice on Windows. It is not as good as KDevelop but it works.
KDevelop is your IDE on all Unix platforms.
Add Cervisia and WinCVS for you source code management and you are in business.
Now go code.
Drop C++, or use GCC to precompile it to C.
Then feed that C through whatever. Or switch to Objective-C.
Visual C++ is supposedly also a pretty bad compiler, and MS as usual screws the standards.
Try looking at compiler alternatives. Metrowerks follows the standard quite strictly.
Well, first and formost, if you're looking to speed things up then why don't you hire more staff?
Secondly, why not hire more staff?
Thirdly, I think that hiring more staff would help.
Our project is quite big, uses intesively AI algorithms, DD.BB., caches, etc. and the performance is great.... and if it doesn't run enough always can use JNI...:-)
:-)
To get cross-platform compiling can use ant, no am not kidding go and take a look and will see all things it can do for you
That is what I found in my last job where we had a bunch of C++ heads, and we were primarily windows with ports to solaris. C++ was so full of trapdoors it's no wonder our company went under.
I was faced with the multi-platform development problem a few years back. I utilized some tools from a company called Codefast. There was/is a book from O'Reilly where the process is described and an arcane set of the tools was included.
I found these tools and framework very useful. You can have automated builds, makefiles can be generated for "thousands" of different os/compiler environments, etc. Check them out at codefast.com
Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications.
So what you're saying is:
You've coded it in Java, used native methods where applicable, optimized it, ran it, and it was too slow on every single hardware configuration known to man.
Or are you just guessing?
If you posted on Slashdot hoping we'd help you, give us the details. How "not an option" is it?
-... ---
I still prefer Tcl (with Itcl for object-oriented programming). It's the easiest software environment to work with for me. I also use websh and dtcl extension for apache (tcl.apache.org).
Using TCL you'll have a very compact and clean code.
I prefer turbo prolog. Not many people know about that one.
And the turbo c++ ide was a classic!
graspee
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
MKS Toolkit does a terrific job of integrating a Unix ksh-based CLI with WinNT/2K/XP, and couples closely with IBM DB/2 so that you can run DB/2 UDB scripts as you can under AIX. It is expensive, but worth it if you can afford it.
Qt is a very, very nice cross-platform development library. Another option you could look at used to be Neuron Data's Elements Environment, but they renamed the company (www.blazesoft.com) and I don't know if they still sell EE as a seperate product (Advisor is a repackaging of their rule-base software, which was built on EE.)
There are also the ever-present Rogue Wave class libraries, but I don't think they'll address your GUI requirements. However, if you use it to split out the core application functionality from the presentation (GUI), it might be helpful.
A solid set of macros with compiler/platform detection directives can help a great deal for porting code, though many people prefer to use sed or perl scripts instead (ala config.) Macros have the advantage of dealing with portability more consistently, and localize the changes for platforms to the headers and migration binding code (usually done as a base library.)
Using cross-platform libraries such as xml.apache.org libraries, IBM's ICU (Unicode support), et. al. can also make your code much more portable without requiring extra work after the initial coding.
There are also various open source projects that provide portable thread libraries, portable GUI toolkits, etc.
I do not fail; I succeed at finding out what does not work.
Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications. Read: "We don't want to learn Java" No Java programmer who read that believes you. The answer is that what you can learn to do in Java in 5 DAYS won't be fast enough, but if you're willing to either hire a good contractor (for gods sake ask to SEE something he's built though), or take 8 weeks or so to get GOOD, you can EASILY do this in Java...Unless of course you are doing special effects for ILM, in which case I humbly apologize, and I've got some questions about the next movie.
Nothing great was ever achieved without enthusiasm
for some odd reason, Borland's Kylix 3 comes to mind... I just got a copy installed here a few days ago and want to find out if the claims made for it are true. If so, it would seem to fit your situation
C|N>K
Hi. I'm not usually much of a poster to this site, but since I spent the last
three years of my life doing exactly what the original poster asked
about, I'm going to make an exception.
First my credentials. What we do is write design software for
engineers. Much of the code is intensive numerics, where performance
is critical. There is also a fair bit of Gui work where we don't care
nearly so much. Our target platforms are Windows, Linux and five
flavours of Unix. We had no restrictions as to language, except that
it had to be something we had a reasonable change of finding
developers to work in, (so no Prolog or Haskell). The project is
question was intended to go to a big installed user base.
First, PERL. We investigated PERL and ended up using it extensively
for scripting, but frankly it won't do the job for intensive
numerics, when there are a million dot products to calculate.
Second Java. We initially thought Java was our best bet for UI, and
possibly the rst. Unfortunately it turned out that Java's performance
is not up to it either. It may look fine on Windows and Sun, but some
platforms were ten times as slow as the Windows implementation. That
was the sort of performance hit we could not take. Admittedly this was
three or so years ago. It took us only a fews hours to run a simple
numeric Java program on all platforms, and there were several where it
couldn't cut it. (Are you listening IBM?).
We toyed with a split between Java and C++ for the numerics, but it
would have taken a lot of work. A class can practically be only one
language, and the application didn't split nicely into 'numeric' and
'non-numeric' classes.
We finally settled on C++ and like several posters went for GCC in
order to get maximum portability. Obviously this is not possible on
Windows, and we went with VC6 on that. In practice the number of times
we found code that would run on one but not the other was very rare,
with a big exception I'll come to later. This has worked pretty well,
but GCC is not built for speed. We recently tried porting to the HP
native compiler, and got a better than double speedup. However that is
the sort of hit can can afford to take if it gives us full portability.
There are some restrictions on GCC. Using shared libraries with C++ is
very tough on some Unix platforms. And the native STL on VC6 has some
incompatibilities with the GNU STL, which we fixed by going to STLPort
on Windows.
When we discarded Java, we picked up on Qt as an alternative GUI kit, and have
never looked back. It's powerful, truly portable and very cheap. We
have a few issues, and we don't use the really cutting edge features,
but on the whole it probably saved us man years of effort. In my
opinion its easier to use then Swing, but that's just an opinion.
We also considered writing two separate versions, one for
Windows and one for Unix. Unfortunately that would have essentially
doubled the amount for work necessary, and have done it for ever,
since we were pretty certain the codes would never have converged. We
needed to have exactly the same look and feel across all platforms,
and no-one wanted to settle the hundreds of disputes over whether the
'Windows' or the 'Unix' way was the right UI.
I mentioned a big exception a while back. Early on in the project we
took a strategic decision not to permit multi-threading. We did split
the GUI and the numerics into separate processes, so effectively this
gives us two threads. We've never had a problem doing this, and it
simplifies the code a lot. If you can do this too I'd recommend it.
I suspect that it reduces the differences between GCC and VC6
enormously. We wrote our own classes to isolate the differences in
socket programming between GCC and VC6.
Makefiles? Don't know. We have a hulking great set of Makefiles, hand
coded, driven by hand coded Perl scripts, and both are a nightmare to
maintain. Anyone with better ideas, please let us know.
If you need to reply, call me "Engineer".
The second example was coded for a flaw in the implementation of the standard in VC6: variable declaration in for loops was not limited to the scope of the for block (as the standard specifies). If you tried to compile the first example in VC6, you got a compile error claiming i was declared twice.
VC.NET implements the standard correctly.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
As far as makefiles go, cmake looks promising. It seems to be a generalized Imake replacement. I haven't used it, but looks interesting. It is now part of the cygwin toolchain.
as far as tools go, look at cygwin. My company uses gnumakefiles on NT and UNIX, with generalized Makefiles for each project, and platform specific build rules in universal gmake include heeaders. We use ACE for a lot of the cross platform C++ stuff, a lot of our things are servers so we avoid the cross platform GUI stuff.
Caveat Emptor (Let the buyer beware)
1: Use the Visual C Runtime as much as possible for your Windows code.
The MSVCRT contains many calls that can be substituted for Win32 calls. The beauty of the library is that the MSVCRT was designed to look as much like unadorned C++ code as possible. For example most functions return longs istead of HANDLEs. This can be most helpful for cross-platform code.
2: Use FIBERS instead of threads for Windows.
Fibers were included in Win32/Win64 to make porting UNIX apps to Windows NT easier. They are basically lightweight threads that manage their own scheduling, memory, and concurrency. While this may seem like an insane suggestion, this is the method used by the SQL Server team at MS to get maximum performance.
This may be a good way to approach your problem because using fibers allows you to write your multithreaded routines specifically for *NIX, avoiding Win32 specific code.
3: Use the development utilities included with Visual Studio to get insane performance boosts on the NT platform (30-40%) without changing a single line of code.
Specifically, you want to look at rebase and bind.
By default all DLL's are loaded at memory address 0x1000000. If this actually happens, Windows will have top calculate the offset of every function call contained within any DLL at load time - a huge performance hit. Rebase.exe recalcuates the DLL memory address during development.
Bind serves a similar funtion, nailing down the addresses of each function in your code. Good for a 10-15% performance gain.
4: For Windows, pay most attention to DLL loading, startup, shutdown, and unloading.
Perfecting your code in this area can save you some serious CPU cycles at runtime, and, best of all, most of this code can be isolated from your other, cross-platform code.
For some Win32 tricks that will improve performance on the NT platform, check out Developing Apllications for Windows, 3rd Edition by Jeffery Richter (MS Press). Has some great stuff on tuning and perfecting.
Intel has a great compiler which is a lot faster than GCC or VC++ on x86 and ia64. It's even faster on my Athlon ;)
Would a cross-platform SDK with a C API do, instead of C++? C is more efficient than C++ for many purposes and much nicer for integration.
You might want to take a look at Probatus Spectra SDK. It provides many standard and advanced functionalities, as well as many helpful high-level frameworks for networking, globalization, and so on. A comprehensive cross-platform compatibility layer is an integral feature of the SDK.
You mentioned that you need especially threading. Probatus Spectra SDK provides a very nice cross-platform API for threading. For example, it cross-implements the conditional variables in Unix threads and thread events in Windows.
It also has an excellent build system based on a framework of makefiles that hides all platform-dependent issues.
The currently supported platforms are Linux, Solaris (Forte compiler), HP-UX, IBM AIX, Tru-64 and MS Windows (VC++ and Borland C++ Builder compilers). Both 32- and 64-bit platforms are supported for Solaris,
Definitely check out:
FLTK - http://www.fltk.org/ - light-weight
cross-platform C++ GUI toolkit with
OpenGL support, etc.
Boost - Portable, peer-reviewed C++ libraries
including threading support, etc.
I print, therefore I am.
Microsoft hired Herb Sutter a while back and has become quite committed to producing a fully compliant C++ compiler. VC7 is a huge step in the right direction and VC7.1 (due out probably within the next 6 months, and approximately $30 to upgrade from VC7) will iron out almost every remaining issue, including partial template specialization. I haven't been watching gcc as closely but when VC7.1 comes out it will probably surpass gcc in terms of standards conformance.
It's not VC++'s code that isn't portable, it's some of the language extensions MS added for Windows-specific stuff like COM. Since any cross-platform project has to encapsulate platform-specific code anyway, this isn't much of an issue in the grand scheme of things.
If speed of execution in Java is the problem, compile it to native, it still will not be as fast as well written C (overhead such as the GC and OO).
Wow, I should not post when knackered.
All the posts recomending you change languages aside, we're in the same boat as you. Multiple compilers over multiple platforms. Rewriting code is simply not an option.
We're actually moving from a complex system of Makefiles to tool very similar to Ant.
You grab Eclipse and starting writing Java. (Eclipse is also written in Java ;)
Honestly, I would use Visual Studio only as a deveopment environment -- but NOT rely on it. The other platforms will be easy enough to just use whatever text-editor the developers are comfortable with.
I tried Intel's compiler for the first time today on Windows, and it's far superior to the one that comes with VC 6.0... it integrates nicely with the IDE (remember, the IDE is just an IDE, the compiler is a command-line utility) and -- in my case (fourier transforms, MP3 decoding) it produces code that is a LOT faster (though compile time is slower, output is larger...)
Point being, there is no reason (ever) to tie yourself to visual studio. It's a glorified text editor, really, and as long as you keep it that way (stay away from MFC et al) then it won't introduce any problems with cross-platform programming. I personally run a couple of (private) cross-platform projects, and the best advice is to treat code as code. Don't rely on any of VS's magic, just use it as an environment that lets you edit text and compile with the push of the F7 key.
NGWave - Fast Sound Editor for Windows
to run on massively parallel machines? It does have threads, but that's only part of the solution. This would also mean throwing out all their existing code unless they wanted to use that terrifying Java-Native C integration. I don't think the problem was ever an issue of language so much as addressing their compilation problems.
Hi!
I have good experience with:
Qt/qmake - GUI Makefile Builder
ACE+TAO - CORBA
I use VC6 under Windows, gcc 2.95 - 3.2 under Linux and Irix C++ 7.3 under Linux.
Best regards
Erik
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.
Check out WxWindows. http://www.wxWindows.org
I have Borland C++ professional builder and looked at the Kylix solution. IMHO it is not cross platform and we all know that MSFC and IBM's Visual Age libraries are intended to lock you in before you start.
So far WxWindows looks good. It gives good Windows/Unix/Max cross platform support.
Check out DEV-C++ for a Windows Gui builder. Unfortunatly DEV-C++ is written in Delphi. It needs to be ported to C++ and WxWindows then it too will be a cross platform development gui-builder.
Good luck.
I seriously question whether your claim is true.
I work on a serious cross-platform app at present. We build on something like 15 different platforms, from the latest Metrowerks CodeWarrior on the Mac and VS.NET on Windoze to antiquated HP-UX things and God knows how many Solaris builds.
Today, I wrote a singly linked list class. I wanted it to be generic, so I defined it all using macros. Am I insane? Not at all. Several of our compilers don't support even basic templates properly, and if you look up STL in the help, you'll find no match. You can't get more modern compilers on some of these platforms, and even if we could, we're supplying to other development companies and are constrained to make our code work on whatever compilers they develop with.
I could have written everything much more cleanly using templates, in much less time, or even faster still just used std::list, but then it wouldn't have built on something like half of our compilers. These things get confused when you combine overloading and overriding sometimes (what's the using keyword, anyway?) so more advanced techniques are right out of the Window.
Boost is a fabulous thing. I sincerely hope that several parts of it make the next C++ standard, and fix up some of the glaring gaps in the current one. But while it's intended to be written in standard C++, and as time goes by it will become more widely useful, you could never call the sort of code they use "portable" in an industrial engineering sense at present. Portable amongst recent compilers on popular platforms, yes, but outside that scope, it's an academic toy that is of no practical use.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Like he said , if i is declared previously, then there's nothing wrong. If you have
int i;
for(int i=0;in;i++); for(i=0;in;i++);
Then you're fine. The compile might warn you that the second declaration of i shadows an existing variable, but that's all.
(Me, I can't get over how ";in;" is supposed to be valid...)
Think about Point #2 in this context. How many programs have you tried that you are surprised to learn are Java? If you said none, you probably aren't looking hard enough. (Hint: Look for the java.exe file in the installation directory.) You tend to recognize Java apps by their distinctive look. The distinctive look has problems with perceived performance. As such, many good programmers change it to use a non-standard look.
After you visit jGoodies, you should understand more of what I mean.
As for Point #1. I don't know enough about MFC to be 100% sure, but I believe that Windows automatically handles repainting when you are populating complex objects such as tables. (e.g. You'll tend to notice large tables in SQL Server Enterprise Manager paint nothing in the table as you scroll. Instead, you can watch the text filled in after the fact.) Swing (the Java GUI toolkit) requires the programmer to make these optimizations. Why? Because that's who *should* be doing it.
What if for some reason, I want to design a scrollable table that is fast enough when pulling data over dial-up connections? Under Java, I might design it so that the data doesn't display until the user stops scrolling, or I might display partial data. Under MFC, do I have much choice? Not without jumping through a great deal of hoops.
Notice how Microsoft writes new components every time they have a new piece of software (e.g. Office toolbars, Outlook shortcut bar, etc.). They do this to improve performance in their programs. Java programmers shouldn't have to rewrite GUI components, just data models. However, few and far between is the programmer who actually does this.
BTW, another spot you might want to visit is
Swing Sightings. You can find links to all kinds of well written Java programs.
If you'd like to try a Java program that uses native components instead of Java Swing, try Eclipse. While I personally don't like it, it should help you understand the perceived problem a little more.
Javascript + Nintendo DSi = DSiCade
We use the following tools in our VTK (vtk.org) and ITK (itk.org) projects. Both these systems are cross-platform and are used by some pretty heavy hitters like the National Labs and National Library of Medicine. The systems are also quite large and complex.
s ults-Nightly/Dashboard.html. Notice that we test nightly (actually continuously) on many different platforms and compiler combinations.
+ CMake (www.cmake.org) manages the build process in a cross-platform manner. Using simple configuration files, it produces a native build environment (e.g., Makefiles, workspaces, etc.) on Unix, Linux, Windows, Mac. That way you can use native development tools on each platform. CMake is becoming pretty popular; it's available from cygwin, Debian, etc.
+ The testing process is managed by DART (http://public.kitware.com/Dart/HTML/Index.shtml) and an example Dartboard can be found here http://www.vtk.org/Testing/Dashboard/MostRecentRe
+ We use CVS for source code control
+ VTK provides cross-platform 3D graphics, image processing and visualization. ITK provides image processing, segmentation and registration.
+ We have created a C++ class that encapsulates threading details and use it in a general fashion. Both ITK and VTK use this. (VTK also encapsulates distributed parallel processing such as MPI. We have used it on a 1024 processor National Lab Machine to process nearly a petabyte of data.)
+ Tk (Tcl/Tk, Python/Tk, C++/Tk) work okay for the GUI. Qt, FLTK, and wxWindows are also candidates.
+ We like to create hybrid compiled/interpreted environments. That is a C++ core, which is automatically "wrapped" into language bindings for Tcl, Python, Java, etc. We now have a tool called CABLE that can wrap arbitrarily complex C++ code into Tcl (soon Python). See http://www.kitware.com/Cable for more information. Applications built with the wrappers are pretty portable.
-W
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.
A wonderful alternative to make is Jakarta Ant. It's java based, but there are ways to get it to work with C/C++ files and compilers. You can create an entire build/test/deploy process with Ant.
Who said Freedom was Fair?
I would suggest you look at CMake: http://www.cmake.org. It does exactly that. You type simple CMakeLists.txt files, which contain your build process and then CMake will generate your native build process. Currently it supports Linux, SGI, HPUX, Free BSD, Solaris, OSF... unix like operating systems, it supports gcc on just about any platform, Mac OSX with make and gcc (CodeWorrior on the way), Windows supports Borland c++ 5 makefiles, Visual Studio 6 and 7 project files and nmake. So, as you see it supports a variety of different build systems. And you do not have to really change the project too much. At least not the source code. Some project built with CMake include VTK, ITK, ParaView. CMake is also being considered for several other open source projects.
Using cross platfrom libs can save you lots of time. For GUI you can use QT, GTK, or fltk.
c pp.ht ml
threads, file I/O, etc.. Common c++
http://www.gnu.org/directory/libs/cpp/common
Common C++ manages threads, synchronization, and network sockets by offering portable C++ classes that abstract these services, as well as supporting "serial" I/O, daemon specific event logging, object serialization (persistence), block/record/page/ oriented file I/O, and configuration file parsing.
Check out http://www.paulgraham.com who has some very good articles about choosing a language. He makes a good argument that python/java are slowly reinventing LISP...
if you can break out your high-speed numerical pieces into small bits of code, it's relatively easy to call them from perl.
s/perl/Java/g
Just junk food for thought...
For the hevily computational stuff use C++ native libraries if the java "prototype" doesn't work for you everything else (persistance, interface, brokering) use Java.
Hi there, I work at a company called Intrinsic Graphics in Mountain View, CA. We have a cross-platform C++ API that can be ported to any OS. We are currently focused on the video game industry, but if you're interested in potentially using Alchemy for oil and gas we can discuss how that would work. Alchemy's roots come from SGI's Performer Visualization software, and can most likely be tailored to work for your needs. Cheers, Grady
You might want to give XWT a shot. You write all your business logic in whatever you need (C++, Java, Perl, Fortran, whatever), exporting the functions you need to use as XMLRPC or SOAP connections. Then you write your user interfaces in XWT. Native clients for Linux and Win32, with everything else supported by a Java 1.2 RE. It's fast, scalable, configurable and truly multiplatform.
Use Java. That's what it's for.
There were teething troubles early on, but most of that has been ironed out. Things run really, really, well, even large applications.
(Look, "Art Of Illusion" is a 3D modelling program written entirely in Java. It runs fine on my PII-300MHz _laptop_).
You get access, not only to SGI, Windows, Linux, AIX, Solaris, but just about any other platform with a JVM. And, Java is really nice to program in to boot.
If you really must use C, use C/C++ for the "back end" (so you can use gcc for everything, even Windows), and just use Java for the GUI.
It is not a "flaw" in VC6. The current C++ spec itself allows for either implementation though the non VC6 version is preferred. And the reason for THAT is that the older specs all did it the VC6 way and the final 3.0 spec breaks old code! There is an appendix in the 3.0 spec covering this issue. I suggest that if you care, you check it out.
This stuff is done for real. At IBM I worked on a very large project that compiled on AIX (several distinct versions that we were sensitive to) Solaris, Windows NT, Linux, HPUX, and supposedly OS/400 although I never actually built the OS/400 piece nor have I seen it operate. First things first, you need good coding conventions, don't let some punk break them either. Secondly you have to design some abstractions and build some foundation classes; or buy a really good set or downlaod some good free ones, I've heard positive things about ACE. This is mostly a problem with windows any more, back a few years you might support win16, win32, PM, and UNIX now it's pretty much just POSIX and Windows. You need to abstract the machine stuff out. Threads, possibly strings and such (Unicode vs. non-unicode..) possibly basic types (big endian vs. little) networking code.. A rule of thumb is that on this kind of project you should never talk to the OS directly without something in between, it's a huge effort to make that OS abstraction layer or learn the ins and outs of an off the shelf one but it's worth it, even if you pay with a little performance. Nothing sucks more than coding away on AIX building some cool classes and adding some cool new stuff, then checking it in and finding that it doesn't compile on any other platforms.. and you've got to figure that crap out ASAP to make a deadline. If you build one from scratch, as IBM usually does or did, you can tune some things for your application; your OS abstraction layer can be a great "helper" or "utility" layer.
Typically well coded C and C++ can go from compiler to compiler pretty easily. Then you can use Pro64 on Mips, ACC on sparc, Intel C on Windows for performance critical portions of code. You have to be smart about it though and use some good conventions. The biggest rule would be avoid MS Visual Studio which is by far the most non-standard setup out there and if you do use it don't use their projects unless you have to. Some good make files with some good rules can help make this pretty easy. I don't know why more people don't do it but look at the Linux kernel's rules file. I have a Rules.make that I've built up and it includes things like different options for debug builds, profiled builds, and optimized builds, sets up some common rules for compiling C++ code and C code and what have you. My makefile include that file and then they are usually pretty short, generally not much more than a list of .cxx files and a library name.
Then it's easy to make sweeping changes too. I think a good build
system, one that will last should usually take a day or two to kind of
put together pretty early on in a project, unless you can carp some
good stuff from another project. The goal is a flexable and reliable
build system that you don't have to worry about. Far too often people
start cobbeling a build system together and then after 6-9 months it's
broken and britle and hard to change because so many things have been
changed and added through out the project. Put some effort in up
front, consolidate your rules in to one place, use some environment
variables to control some build switches. Use some shell scripts to
figure out various things, not hundreds of lines of Bourne shell code,
just little bits. Do this until AAP is ready and rocking and then use
that. Also, if it needs to be said, use GNU Make; it runs damn near
everywhere and it's pretty good at what it does the 15 minutes it
takes to learn it will save you hours and even days worth of time in
the long run.
I'm a huge advocate of a solid and strong build. Mozilla is a project that festered for weeks or maybe even months becuase you couldn't build the damn thing when it went open source. Building code is something that can be done so well by tools that if you're worried about it then you need to fix the build. Building software is hardwork so take the pieces you can out of the equation, the build is the first one.
Next, I assume you've abstracted out the GUI from the meat. If not, make this job one if you wish to have any chance in hell against your one platform competitors or even your mulitplatform competitors when you get down to it. View/Data Model and client/server: learn it, live it, love it. Or switch to a web based interface, lot's of people do it.
While we're on abstraction. If you guys are really serious then you're probably going to have machine specific components. Look at /usr/src/linux/include and /usr/src/linux/arch for a starting point of
reference. I would envision a project like this have a set of small Mips,
Wintel, Linux-x86, etc. directories. Everything else can probably be
compiled with GCC and then in those directories you'd have your
assembly and machine specific compiled code.
Lastly, you want to have a staged check in process. People hate not being able to commit code but at the same time you don't want them to commit code for real until it compiles on all of your platforms. Honestly, I don't know of a really good way to do this. Set up a build lab, do nightlies against the real code. Do nightlies against the "staged" code. Then have some kind of weekly merge meeting. That's how I've seen it, it's time consuming and somewhat painful. You bite off too much and you're spending a shitload of time merging stuff.
try elisp as emacs has been ported to almost all platforms
gcc 3.2 is generally superior to VC++ emitted code,
in my experience.
Mingw32 is the target of choice if you don't want
to license Cygwin.
-I like my women like I like my tea: green-
On portable programming: remember the adage "only the paranoid survive". Assume that language-defined libraries will pobably not behave exactly the same on different platforms (e.g., threading). Rather than using such a library directly, write your own library around it, and code your application in terms of your library. Then, when you port it to the next platform, the only platform-specific changes should be in your library, not everywhere you used the library.
On choice of language: C is probably the ultimate in terms of portability. You might code difficult sections in C. C++ can probably be written just as portably, but I would suggest that you restrict developers to a known-portable subset of the language features, especially with regards to class inhertitance and the "standard" library (whatever the old STL is called now). If one of your programmers creates something that "surprisingly works", expect it not to work on any other platform.
As for RAD: that is a tough one. I've had good success with wxPython (Python is fantastically easy and powerful, and wxWindows provides a very nice set of widgets). There is also a wxDesigner tool for creating dialog boxes (and interestingly, it emits perl, python or C++, your choice). I haven't used it, but I would expect it to be well worth it (it's non-free). The rest of the common GUI development stuff (connecting buttons and menus to action functions) is trivial to code by hand in wxPython.
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
The identifier in was previously declared. Because it was initialized as nonzero, the first loop is still going. (And going, and going,...)
Actually, it's not like anybody on Slashdot has ever figured out how to write a less than sign. As you know, what he meant almost certainly was:
(For the record, you have to use <. Even if you choose "Plain Old Text". Don't let them fool you--it isn't all that "Plain Old".)lisp.
ac
You might use Java for the interface and use JNI (Java Native Interface) to attach computation and rendering modules onto the VM.
I know of several games that use Java interfaces and then run a real time simulation written in C++.
Maybe you could build on a third-party threading lib?
It seems you have two issues: having a managable build environment, and finding different compilers that agree on what c++ is.
There is an utility, CMake (do a search), which is a CrossPlatform make tool. You set up some high level specifications (which files belong to which object, etc.) and it generates the platform specific make files (or VisualStudio projects) automatically. I have used it a little bit, to develop the software for linux and windows, but don't know if it would meet all your needs.
As far as getting all your compilers (and headers, and libraries, etc.) to agree, the easiest solution would be to use the same compiler on each platform (gcc). To address some comments others have posted: for numerical applications running on Windows (at least the ones I compile), gcc by far outperforms VC7. It is a much more agressive optimizer, and has optimizations for P4 that VC does not yet have.
Of course you could add the line:
#define for if(0);else for
inside a test for VC6 in your standard crossplatform header, then you can define those loop variables wherever you want.
sig's not here
Go to java.sun.com and you'll find the 64 bit VMs designed for Sun's big iron. These VMs are the ones that take ultra busy J2EE servers to task.
Javascript + Nintendo DSi = DSiCade
Turn it off.
If you have some very time critical sections of code, try turning on the optimizer for just those routines - but otherwise you're just asking for trouble.
It has binding for many GUI libs, including wxWindows. There is also bindings for SDL and OpenGL :-)
If your worried about speed, write an extension module, or try inline C (weave) or use Psyco to genererate optimised code specifically for your data...
a ^= b; b ^= a; a ^= b;
Try the Apache Portable Runtime Project.
I work work for an oil and gas exploration company. We are starting on a project to take all of the windows geophysical systems off of windows and go with a Linux solution. Even last year we were trying to move all of our applications off of unix to Windows. Now were are considering the opposite.
I've been doing this graphical dataflow programming for a few years and there really isn't anything like it.
You can resurrect a dead open source project named the Internet Virtual Machine.
That's what I was after.
As someone else pointed out, the problem being demonstrated was that in the original (with semicolons included, and both statmenets the same, ie: i initialized within the statement), vc++ would complain about i being reinitialized on the second one... when it shound't, as i is already out of scope.
I consiter myself resonably well tuned into the computer/IT/geek sceen, but I have to admin to for a long time conciously filteing out any news of Java - probabaly since 1.1. About 8 months ago I tried and after a week was margionaly sucuessfull (not all either Suns or my fault..) installing a "enterprise" class Java application. A major part of the problem was getting the right (out of date) JRE. So could someone please explain to me the magic word that I apparently need to know to get what I would have though would be a "Get Java Here" button click away to download the right JRE? Neither "jre" or "jre" exist on the front of java.sun.com
Java's gui code is free from heavy licensing fees..
Qt on the other hand..
Don't Tread on OpenSource
You're confusing C and C++ libraries.
glibc is the GNU C library, and the system library for most Linux platforms. The C++ library is libstdc++-v3, which is completely separate.
The MS 6.0 compiler used the most recent version of Dinkumware's C++ library at the time. I don't know what they used for 7.0, but Dinkumware has continued to update and improve their libraries. They even had bugfixes for their headers that MS hasn't included with 6.0, so you could patch them yourself.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I love perl, for one page, quick-n-dirtys. But it's 'more than one way to do it' aproach leads to confusion and strife in larger projects.
May I suggest a look at Python?
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
I have been programming C++ professionally for over 10 years on many Unix and Windows platforms (Sun Forte, MS Visual Studio, etc), and I can tell you that nothing comes close to ProjectBuilder, InterfaceBuilder, and dozens of other tools on OS X. The good news (for those who always think everything Apple must be expensive) is that they are absolutely free, so save that $2500 for Visual Studio.NET and buy yourself a decent G4 TiBook with a real OS and all those free tools.
With GCC 3.1, you can programming in mixed C / C++ and Objective C / C++ in the same file or project. ProjectBuilder provides the best IDE and CLI for building multiple projects with dependency and multi-targets and multi-phases, apart from editing source files, icons, graphics, sound, document, etc.
InterfaceBuilder is the only tool on earth that actually allows you to design and test professional UI with virtually no user code.
Kylix 3 supports C++ code as well as Pascal. I haven't tried it yet but it should work.
http://borland.com/kylix/index.html
Of course, you'll have to port any C++ Builder VCL code to CLX.
We accomplished this by employing perl/gnumake for the build environment and relying on the ACE library for portablity: http://www.cs.wustl.edu/~schmidt/ACE.html
Our product ran on Solaris (32 & 64 bit), Win200, WinNT, Win95, Win98, Linux and AIX.
ps. I like OO. But I hate the toolkit. It's just weird!
"What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?" Support for threads and network programming are not yet part of Standard C++ Library but does not mean that these libraries cannot be used right now. I recommend first to check www.boost.org. Also, to maintain maximum reusability of C++ code across different platform I suggest checking following General-purpose third-party libraries: - Rogue Wave Threads - Objectspace Thread Classes - Ace Thread Classes - John Harrington Thread Classes - Allan Kelly's Class Templates - Bio-Rad's Thread Classes
And Qt is soooo much easier to use :) The heavy licensing fee is something I'm willing to pay when do commercial development with a toolkit that makes my task substantially easier.
If you are doing geographical stuff, maybe ArcIMS (GIS software in Java), ...
ArcPad (for handheld PC) and all that is related to GI Networks would save you a LOT of work
Esri new product line is very young (ArcGIS 8.0, ArcIMS 4.0, etc.), has still many bugs and sometimes, the object model make you hit your head on the wall, but despite all this, I think it is the best and most complete GIS software suite available right now).
ESRI
ArcGIS
ArcPad
ArcIMS
ArcObjects online
Intelligence shared is intelligence squared.
Try the solution that has been successful for most of the GNU projects. Take a careful look at GNU's automake and autoconf packages. You'll find them at the Program Build Automation section of the GNU software directory. In addition to the reference manuals from GNU, you'll want to read through the book Autoconf, Automake, and Libtool
which is the only book I've found on the subject.
I've just started using these tools in the last couple of months, replacing a complex and brittle hand-coded multi-platform makefile system. To be perfectly honest, there isn't enough tutorial information for setting up a new project. But once you figure out the magic incantations that your software needs, autoconf seems to do a nice job of detecting incompatibilities and passing them through the make system to your code. Automake generates the thousand-line makefiles replete with targets for all, clean, install, etc. All I have to do is list the source code files for a given module or library. These tools will do the rest.
That isn't to say that my code became instantly portable. After we got a small application working on HP-UX, we just configure/make'd on Windows. Everything compiled under mingw, but the Windows crtl has different ideas about little posixy things like user names. So we had to add some portability code based on the checks that configure performs for us.
Overall, I'm looking forward to not messing around with makefile systems much any more, and concentrating on the more interesting bits of software development.
Check out Runtime Revolution, a cross-platform JIT compiled smalltalk-like programming environment based on 10-year old engine technology from MetaCard. It compiles to very small standalones and works on just about every platform(from website):
68K and PPC Macintosh systems running MacOS 7.1 through 9.X, with a separate Carbon engine for use with Mac OS X. The Win32 engine runs on Windows 95, 98 and NT and Windows 3.1 systems with the Win32s library Nine popular UNIX/X11 platforms are also supported: Solaris SPARC, Solaris x86, DEC Alpha, SGI IRIS, HP-9000/700, IBM RS/6000, SCO ODT, BSD UNIX, Linux Intel, and LinuxPPC.
One of the best things about it is the robust IDE which looks and acts the same on *all* platforms. You can build and debug on any platform you wish!
I used it to build ButtonGadget in only a couple of weeks. Would've taken me months using C++ or VB --and would be most difficult to make cross platform.
It also has a great and supportful user community. Check it out.
.. but isn't that what's autotools are for?
Produce Makefiles with automake, and configure them with autoconf.IMO that would work great on a huge pile of different platforms with different compilers...
Hello, I suggest Python (http://www.python.org). It's cross platform, has good UI support (I recommend wxPython, http://www.wxpython.org/) and is easily extendable with c/c++ modules. (See http://www.boost.org/libs/python/doc/index.html for example). Pluse it has a very good mathematical library (http://numpy.sourceforge.net/) which is cross platform as well. Write most of the logic in Python and only the time critical section in c/c++ (ANSI C will be best cross platform solution for this). HTH. Miki
-- Miki Tebeka The only difference between children and adults is the price of the toys.
gcc is built for portability, not speed. VC++'s code is faster
This is no longer true, vanilla Microsoft Visual C++ is not faster than GCC anymore. There are compilers which can do much better than GCC on certain platforms, but Visual C++ isn't one of the, usually.
In addition, unless you've got some real-time applications which scratches at the limits of the currently available hardware, machine code quality doesn't matter a lot. If you use a compiler, you've already made a compromise in terms of effort vs. speed, and maybe you can shift the balance even further and concentrate on features which directly benefit your customers instead of dealing with cross-vendor compatibility issues.
I recommend looking at the ICU4C (International Components for Unicode for C) libraries, which are available at http://oss.software.ibm.com/icu/. ICU is a set of thread-safe cross-platform open source Unicode libraries. The project has some examples of how it builds and tests on multiple platforms.
It's being used by many other projects and companies. For example, it works very well with the Xerces C++ project. The ICU readme.html has the list of platforms that can build ICU.
Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications.
I think hundreds others has already answered to that particular claim. I'm not a defender of Java, but I'd recommened you to try writing some persistent Java object and rate its performance, rather than judging its performance by some run-and-exit programs.
You'll see the difference.
I hope you're joking... Pick the version of your choice, then download the appropriate JRE.
Then you could use standard gcc on all platforms.
http://www.paulgraham.com/avg.html
Hi,
I have some experience with larger codebases and I don't think that the tools are the problem.
I think most likely the problem is with the project management.
The politic would be simmilar to the one used in my firm: "Change only to fix bugs. Change only your parts."
This leads to a codebase that works. But it also leads to a maintenance nightmare as only code is added but older code cannot be reviewed.
Keep in mind: in a code review you change working code to make it simpler, more understandable and easier to handle.
The only solution to this is a BIG change where every developer has to touch every file. In this way he can change all the little things he always wanted to change but never was allowed to.
In the end every change will lead to a multitude of new bugs, but I think re-implementing a big chunk of your system would be worse as it will lead to a big chunk of untested code.
For references look at other re-implementations and then think about the time it took. Windows NT (4 years?) Netscape (3 years) Mac OS (how long?)... So again. You need the rights to change old code and then start doing it.
From the website
"tmk is a Swiss Army Knife for automating all kinds of tasks, e.g. in software development and systems administration. Like the traditional make utility, it is based on checking whether certain tasks have to be performed because files have been modified. This way, you can automatically recompile all programs that depend on a certain file, or distribute data onto machines that are not yet up to date. In addition, tmk has a lot of features that make has not. Most importantly, it provides higher levels of abstractions than make does. This is achieved through platform-independent commands and modules, and via the powerful configuration subsystem that allows to set up tmk for different platforms and sites."
Douglas Schmidt's Adaptive Communication Environment (ACE) is a fantastic pattern based os abstraction library. You can get a copy of it at cs.wustl.edu. It will provide you with abstractions for threads, IO, configuration, etc and it runs on every platform imaginable. It also support many compilers. You can use the built in make system as well to do cross platform compiling. Another good cross platform build system can be found in the mozilla source code. You can grab a copy of it at mozilla.org and see how they handled cross platform compiling. It uses nspr, another pretty good os abstraction library.
We use the 'understand C++' tool (www.SCITools.com) to provide a window into 1.5 million lines of C and C++ code. You configure this tool by telling it the subdirectory trees of your source code, and this tool builds a database of every file, object, line of source. It then provides both textual and graphical navigation tools for your code, including dependency trees.
It has an integrated editor with syntax highlighting, and shows what code is #ifdef'ed out.
I don't work for the company, but I've found the tool very useful. For your purposes, it should help locate where mods should be done, and what mods to do differently based on your different compilers and platforms. There are versions that run on Windows and Unix -- I use the Windows version, and 'point' it at my Windows and DEC VMS code.
I interpret this guys question to be "How can we make our existing C/C++ code easier to deal with across platforms". It's easy to suggest a change of language to be the answer to all problems, but the fact that most of you are missing is that this guy's company has spent a lot of money to develop, test, and debug the code that they have now. Throwing it all out to change to another language is not the smart thing to do, and will set them back at least a year or more.
Hi
If you are R Smallwood as identified in the link
at the top of the post, I'd love to give you more info.
I've been working on systems exactly like this for the last four years, and while ours isn't the only system that works, it does work. You can at least learn from some of it.
First Credentials. We also write engineering applications for Windows, Linux and Unix, deliver to hundreds of clients who pay us millions of dollars. Our systems work exactly the same on all our platforms, give or take.
Java: When we tested Java the problem was speed. On some platforms it was OK, but on others it was ten times slower. Maybe Java can be fast, but on our applications it wasn't. Splitting the code between Java and C++ would have made it two complex, and most of the non-GUI would have had to be C++.
We do use Qt, and have had great success.
We use GCC on all platforms except Windows, (where
we use VC6) and it works fine. There are some issues if you want to use shared libraries. We test-compiled the code on the native HP compiler and the speed doubled, but we can live with that.
We took a stretegic decision not to allow multithreading. We split to GUI and numerics into two processes which effectively gives us two threads. If you can do the same it might be helpful.
The actual cases where we have code that worked on one platform but not another were tiny. We have macros to handle the few extra directives that VC6 needs. The exceptions to this were sockets, where we wrote classes to isolate the differences. You could probably do the same with threads.
Thinking about Design Patterns is helpful, but saying 'use Facade' or whatever doesn't solve the main problems. Design Patterns solves problems at approximately the class level, not the application.
Writing two separate codes is only going to work if you can afford to double your resources, remembering that you will have to double your maintenence effor too, and then either accept that the user interface wil be different for both versions or endlessly arbitrate between the 'Unix' and 'Windows' way of doing things.
I have a similar problem. I'm the lead architect for an industrial computer-vision system for a company large enough that we haven't been able to choose a single environment. As a result our system has to compile and run with Windows XP, Linux and Solaris. The first thing is to create a build system that can simplify the build process. This we did using GNU make on Cygwin. For those that like the Visual development tools, we have a make option that generates dsp and dsw files for Visual. We also have a cross platform i/o threading library that gives a common interface fro the application, that hurts a bit, Windows is clearly the LCD, although it does have some performance perks in certain cases. But what really hurts is the lack of ansi c++ capability in visual. My solution? I'm waiting for the ansi compatible version of the intel compiler to come out in the 1st quarter of 2003 and then we'll use it on both Linux and Windows. We'll jettison the use of the Solaris native compiler and use GNU g++ instead. That should solve the worst of our problems. There is also a large, growing and amazingly successful (at least in terms of convincing the suits) movement to just go with Linux here. That's all I can suggest for now.
I just discovered MinGW thanks to some earlier posts on this thread and decided to install it on my work machine to compare VC++ compiler and g++.
.sigs are for woosies
My most intensive calculation is a home made implementation of AES (raijndal?) so here goes:
(g++ is compiling with -O3 and VC++ is set to "Maximise Speed")
VC++
encrypt 2.50 MB/s decrypt 2.12 MB/s
g++3.2
encrypt 2.17 MB/s decrypt 1.77 MB/s
close but not there yet. keep in mind gcc3.2 from my tests on the same algorithm on GNU/Linux is ~10% slower than 3.0, but i don't know how to install 3.0 on MinGW yet.
IMHO gcc3.0 kicks ass in portability and is pretty damn good in speed, just as long as they fix the regression from 3.0 to 3.2
and i almost forgot:
.net framework, the fact that it eats more ram than mozilla and its SLOWWWWW performance on my machine, I had to throw it out. .rpm format).
.sigs are for woosies
executable size:
VC++: 1138688 Bytes
g++3.2: 994705 Bytes
compile time:
VC++: 21s
g++3.2: 76s
So there you go, gcc is SLOW but is pretty damn good and FREE whereas VC++ is faster but EXPENSIVE for a poor broke lad like me.
Also i checked out VC++7 but due to its reliance on
As a last note, i did try out icc from intel and was not too impressed with it, it basically had the same performances as gcc-3.0, costs much more and was the worst pain to install on debian (it's distributed in
Mozilla is a platform. It's possible to write all the GUI stuff with XUL and encapsulate C++ code in components that would be called from the GUI.
Get by with what you have for one more year then switch to Java, opimize your code, and throw more hardware at it.
Neil
If you are developing cross-platform, give CodeWarrior a try http://www.metrowerks.com Its available for Windos, Mac, Unix, and embedded systems. If you get used to it, very hard to give it up. Comes with a built in class hierarch browser, a class browser to view class/method/field level code, numorous ways to navigate (for instance control-clicking a class or method anme brings up a menu listing all methods that match the method name or to view the class herarchy, etc), custom color coding, etc... their website dosent give justice to it. I've been using it for about 10 years and wouldnt give it up for anything. Even bought my own personal copy when I was forced to use other IDEs (not without trying), so I can work without having to think about the mundane issues like file management, or what file I saved a class, etc. They also have a very impressive C++ framework (PowerPlant) which I used many years back, and its now availbale for doing cross platform development, but that needs a site licence. CW can compile C/C++/Java and objective C. For cross-platform code, have you given Java a try? Java Swing is pretty good and easy to make GUI applications. http://www.metrowerks.com/MW/Develop/Desktop/defau lt.htm
Mahesh.
Sounds like Java too me, with browsers as a front end. You can do some really wonderful stuff, and it won't take a long time to build with Java IDE's that are around for free.
.Net implementation, it would cost way too much.
.Net tools alone will save you the cost over the long run they will have to endure to maintain thier systems.
Java also is fairly easy to add multiple machines (spread out your Virtual Machines) to get more processing power out of commodity PC's. There isw simply no way your competitors could scale thier code on an equivalent Windows
I gurantee you if you proceed along those lines your competitors investment in
Java 1.4 compiler technology (Virtual Machines) is very very good. If you are using numerical processing and large array types the effort you pour into C++ is simple not worth it.
I am skeptical of your claims that Java is too slow. I suspect you haven't really used it for much of anything lately, because the slow excuse is an old one.
You can go into any Barnes and Nobles book store and literally get a small stack on numerical procedures in Java and how to build distributed processing systems with Java, right off the shelf.
If you don't know how to do it, let me know (reply), my company does these seemingly impossible things with Java everyday.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.