Slashdot Mirror
Portable Coding and Cross-Platform Libraries?
Bradee-oh! queries: "My brother and I were just commissioned to develop a large energy management system for a few big college campuses in the area. It will be written in C/C++. We know that in 6 months, when a preliminary test system will be installed, it will be running on NT/2000 servers. The software will be tested on NT for up to 12 months and a final version will run on NT a year after that. We also know that around that time, it will shift to *nix servers, and we're expected to account for that in development. The question is, what sorts of cross platform libraries will make this as painless as possible? I've never made it a point to code for 2 platforms at once in any language other that Java. Aside from the GUI, which we've already agreed to use QT 3.0 for, we specifically are looking for cross-platform libraries for multi-threading, serial port I/O, and network I/O."
"Ideal libraries would be open source and free, though those aren't as important as tested/stable/reliable. What are your recommendations? Anyone have experience writing for multiple platforms at once with threading, serial I/O, and network I/O all in mind? The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?"
You have the answer : Java has all what you need.
From www.imatix.com (The makers of the Xitami webserver).
SFL is a great library for doing portable low-level stuff such as network etc..
ACE is an open-source framework that provides many components and patterns for developing high-performance, distributed real-time and embedded systems. ACE provides powerful, yet efficient abstractions for sockets, demultiplexing loops, threads, synchronization primitives.
I've never tested this framework but it seems very good. I know several companies which use it and which are happy with it.
Your choice of Qt is a good start, but be sure to use GCC, all open source libs that exist on both sides, and adhere as closely to the ANSI standard as you can. If you do the footwork now and gather the libs and other files needed now for both sides AND keep cross compiling on both platforms as you go.
Dont think you can make it under NT and then 2 years later that it will compile on *Nix magically, you need to test every step of the way.
Oh and be sure you have the libs that are identical for both platforms and freeze them before you start. nothing kills a cross platform project faster then changing libs and finding later that the libs you built for on platform X are no-longer compatable with platformY's libs.
Do not look at laser with remaining good eye.
wxWindows (http://www.wxWindows.org) supports quite a few platforms, is open-source, has been developing since 1992, and might be probably exactly what you're looking for.
GNU Common C++ certainly does abstract network I/O (sockets) as well as threads, serial I/O, XML parsing, and logging. There is also a supplimental RTP stack for it (ccRTP). It compiles native under win32 as well as under posix targets. It recently has had a very extensive rewrite, and is still recovering from that.
I realise that the STL isn't on the same level of cross-platform libraries that you were referring to, but it does aleviate some problems - and it's damn efficient too. Stream's, the way the STL uses them, can be quite an effective way of abstracting I/O.
The biggest two problems we had was threading, and serial I/O. Threading, thanks to NT's posix libraries, wasn't that much of a pain - but we did need to write our own thread interface classes, one NT specific and one unix specific. Serial I/O was a little more tricky, but both came down to the same basic approach of treating the serial ports as files.
I think the conclusion we came to was that it was a good idea to highlight the major differences first, and create your own wrapper classes around the OS specific methods. This way your main program is platform independant, and porting is kept to the wrapper classes.
And of course, if you use the Cygwin environment, you shouldn't have any problems at all porting to another GCC platform.
Only one warning: watch out for tricky C++ template uses, not all compilers support all features (e.g. Visual C++ lacks partial template specialisation amongst other useful features).
Check Netscape Portable Runtime, (just one of the many projects that are part of Mozilla. This library provide cross-platform threading, IPC, network/file IO, and dynamic linking, among other things.
would be a good place to start for the threading and networking parts. from what i've seen, it looks like a well engeneered package (and you'll have a hard time finding a better tested library :-).
http://apr.apache.org/
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
Well if you are using qt for GUI why not use the
qt 3.0 network tools.
se the doc for qt 3.0 http://doc.trolltech.com/3.0/
I know that there is no IO mod but g++ have som you can use!
What rimes on recursion What rimes on recursion What rimes on recursion What rimes on recursion
You need SourcePro from Rogue Wave, formerly Threads.h++ etc. It provides a high level, easy to use C++ API for cross platform application development. Even if you're not going cross platform, the Rogue Wave stuff is excellent, provides loads of useful classes for threading, database access, network protocol handling and more.
I was under the -- perhaps misguided -- impression that Win NT offers a POSIX subsystem. Combined with Qt (which does threads, IIRC), the serial port access is covered by POSIX, and network APIs are like UNIX (give or take a WSAStartup()/WSACleanup()).
Right. Serial port stuff is another issue. Most of the serial port stuff that I've seen written was either written years ago, or based off of stuff that was written years ago. What you'd have to do, more than likely is either find a serial port library that wraps around OS functionality, or write one yourself.
:)
'nix and NT handle serial ports very differently, and I doubt that such a library exists. Writing one should not be too difficult because serial port stuff is really basic anyways...you have data going in and data going out, it doesn't get more complicated than that.
My journal has hot
In addition, you can get security, high availabilty, and scaleability with far less effort and platform-dependence than a C/C++ solution.
Are you being forced to use C/C++ simply because of QT? Have you considered using QT in conjunction with Trolltech's QT AWT?
Use Common C++ for the cross-platform serial I/O, network I/O and threading support. I strongly suggest you use G++/cygwin rather than MS VC++ as the latter has all sorts of minor incompatibilities. G++ does too, but at least it's cross-platform. If you do decide to go with VC++, there's a few tricks you can use to make it closer to standard C++, such as #defining for="if (0) {} else for" (do it in the project pre-processor definitions if you don't want to #include it everywhere) which fixes the for-loop control variable scope problem in VC++. Any point where you do anything remotely Windows-centric when you're coding, at the very least put a comment, or put a #ifdef LINUX (or whatever) and flag an error when you try to compile on the other system, or better, figure out how to do it on the Linux system and write that in the #ifdef.
It's very important to keep in mind that the system will be ported, and soon, otherwise it'll be a huge project to convert it when the time comes. It is probably worth doing things slightly less efficiently from the win32 perspective (use G++) so that the system can be easily ported later.
Good luck!
Worst case scenario, put all the serial code into one file and use functions like open_serial_socket(), read_serial_data which call the underlying OS functions. When you move to Unix, swap out the file for the new version.
One good thing is that NT is in the loosest sense POSIX compliant. That means, all the stuff like sockets, etc, work almost as you'd expect from Unix.
Use something like QT for GUI, or glut if it's a predominantly 3D interface, and you'll have something that starts of being fairly platform independant.
Use STL instead of MFC for storage. You may have to roll your own file loading/saving stuff, but don't try and reverse engineer the MFC stuff afterwards - it's not worth the hassle.
I started off writing a network-based game targetted for Windows as while back. Pretty much everything was standard POSIX with OpenGL as the user interface. Before I started in earnest on the UI, everything ran under Unix - in fact, I wrote plug-in UI modules, as I eventually planned to back-port to Linux. That never happened, but I did have a text console UI. This made debugging very easy, as you can run lots of clients at once.
If you're after socket stuff, check out the source for Xpilot. Not C++ style code, but it uses a library that you can look at to see some implementation differences between Unix and Windows.
Definitely do daily builds on both platforms, gcc is good for cross platform use. You can even set up your Unix box to cross-compile your Windows binaries. If you target POSIX, you shold be able to isolate all the Windows/Unix stuff behind an abstraction layer early on and forget about it.
Good luck!
Check wxWindows out http://www.wxwindows.org/, cross platform gui, i/o. Works under *nix, win32, os/2, macos etc
hi!
i'd recommend wxWindows (http://www.wxwindows.org). that's a free (GPL, i think) cross-platform toolkit, or rather, a set of wrapper and supplementary classes.
meaning, it'll use mfc on windows for displaying your application, gtk or motif on unices, etc, etc...
the supplementary classes contain some network stuff, odbc client classes, yet another string class, config classes (using files or the windows registry), etc, etc.
the documentation isn't that terrific, though, so there's a lot of guessing. and i'd download the cvs version, as that is pretty stable and contains a lot of features you'll be missing in the stable tarball.
For portable CORBA and threading support, try omniORB (http://www.uk.research.att.com/omniORB/omniORB.ht ml). We use it for seamless portability between NT4.0 & Solaris components and its very effective.
-- Matthew - matthew.gream@pobox.com, http://matthewgream.net
actually the GUI part is the least of his worries. several toolkits take care of that problem easily (for example, QT, which he settled on). network i/o is cake too. the real hurdle will be serial i/o (very different on the two platforms, but a small, well understood problem space) and threading (hard to get right on one platform, much less two).
Seriously. Most folks on here think Java sucks, but that's typically because they haven't actually *used* it. I think perl sucks, simply because I haven't used it and don't know it well enough to be efficient at it. That's all too common. But take a closer look at Java... It's cross platform, multithreaded, scaleable ('cept that pesky GC thing, which can be handled reasonably enough with intelligent coding), and does all the stuff you're looking to do.
I used to code exclusively in assembly, then C, then C++, and now Java. Trust me, Java is a stable alternative that will solve MANY of these cross platform issues for you, if not all.
As an example, I have written a datalogger for my car. I coded everything under Linux using vi. It's a Swing based app that's multithreaded and uses the serial port to communicate with the car's computer. I never gave a second thought to cross platform support. I just coded to the Java APIs.
One day, a friend of mine wanted to run the thing on his laptop...which had Windows 98 on it. Sure enough, I put the files onto his laptop and it ran perfectly. This was not modified in any way and didn't even get recompiled! I just put the jar files from my Linux box onto this Windows laptop and away it went. I told him this "should" work, and sure enough, it did.
As for scaleability, I have also helped design a VERY large scale middleware Java RMI server architecture for a VERY large shipping company (it's a public company...you know them...I'm positive you've used them). This handles all user-based load from their VERY large website. We're talking millions of transactions a day here, not thousands. With proper attention to garbage collection, multithreading, and a distributed architecture, this system runs without flaw, 24/7.
So Java works in real world examples, it really does. Plus, it promotes code reuse so well, that I can't imagine suggesting any other solution for your problem.
If they're doing a lot of I/O device control directly with the app (Uh, this is an energy management system- which, by definition is going to be tickling things like Opto-22 panels, reading from sensors, etc...) then Java's only truely useful as a UI choice as they're going to have to come up with native interface code to drive the Opto-22 stuff.
They not only have to do network programming and serial comms, they have to deal with industrial I/O that may/may not have a serial interface. If it does all have serial interfaces, they're going to have to come up with APIs for those devices- which isn't always easy.
Java meets only part of the criteria- the ones they needed help with answers on. It doesn't magically meet the other criteria- what are they working with and what does the customer want. I suspect that Java doesn't make the grade here for some reason. I code in Java as well as C, C++, and Forth. I'd be using Forth or C/C++ for this sort of thing with maybe a CORBA driven UI coded in Java unless the customer requirements insisted on C/C++ for everything. Then I'd be using C/C++ because it's close enough to cross-platform to matter little if you pay close attention to your code. I know, I've been doing this sort of thing professionally for 7 years now.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas