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?"
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.
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?
Crippled? Hmmm, I don't know if that is true. Java in itself is an elegant language which has some limitations due to trying to support such a wide range of platforms transparently. You have to know what you are doing, that is all...but that counts for any language.
Java code runs fast (really fast) in a lot of cases, mostly the only thing that "feels" slow is the GUI. You can really enhance responsiveness by including intelligent Threading. You can also avoid creating of throwaway objects, thus limiting Garbage collection.
For the GUI, just don't use Swing if you don't need to... AWT is enough for simple frontends, yes it is not perfect, but it is faster. I suppose it is even possible to write your own native implementation linking to, for example, QT libraries or W32 libraries. Not portable, lot of work, but speed ensure.
Some people tend to forget: using a vitual machine inherently takes some performance, but that is the price to pay for excellent multi-platform support. Note that it's still is better to do test on all the platforms you want to support, but the implementation is done once. Especially when using applications (not applets, because of browsers (non)support ), mult-platform Java applications tend to work astonishingly well in my experience.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
I've worked on several projects using the Java platform, where the portability was one of the the major issue. ...
I could also tell you that the major part of these applications were in a banking environment, where reliability and security were, of course, vital.
It included Threading, I/O , GUI,
The problem with Java is quite offen not the language itself, but the programmers which are not able to understand the basic
O.O. principles, and to keep the logic as simple as possible.
Furthermore, Java performances have been really improved since the version 1.0
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.
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
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
I didnt give a reason as i didnt think i would be questioned.
Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.
It requires a virtual machine, so it will always be more bloated than c.
As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.
There are "feature-rich" libraries that can be linked to in c also.
Java's only good point is its easy to program in, its the modern day equivalent of basic, or visual basic. Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.
Sun will never let java be really free.. they want to control it just as badly as any other large mega-corporation would, its just about money for them.