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.
Do you have a compelling reason not to use Java in this case ? It would seem to provide everything you require.
Even just writing portable C++ code can be tricky, especially if one of the target platforms is Microsoft.
QT covers the multi-threading and network stuff so you're down to just serial port stuff aren't you. If you use QT properly then you should be fairly ok.
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.
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.
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.
Writing cross platform GUI applications is hard. Writing cross platform GUI applications with multithreading and network stuff is very hard, but most of all hard to get right.
Hard = difficult = long = costly.
The question is, is the cost worth it? This application, from what you're telling us, is going to run on a few dozen computers at most. It's not a general purpose app, there is no added value in providing cross platform support.
Why switch platforms in the end? It doesn't make any sense.
But to answer your question, if Windows is really a transitional system, I would just develop on *nix, and run it on Windows with Cygwin. Might be even simpler to use XFree/Cygwin.
I'm not sure what you mean by "Energy Management System", but if the interface isn't heavily interactive, I'd go with a browser front-end. If you can, use Mozilla and XUL. It allows you to build really nice interfaces easily.
Browser-based apps aren't going to replace everything. Highly interactive things like word-processors, spreadsheets, etc. aren't suitable for browsers, but if the interface is form-based I think it's the way to go.
The obvious advantage in your case is that the interface code is painlessly cross-platform. You still have to worry about lower level stuff, but that's much easier to do properly if you eliminate the GUI.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
While cross-platform libraries will help, some things just work differently on different platforms, and you're unlikely to find a library covering everything so that all it takes is a rebuild to port.
As an alternative strategy, and one that's often easier in practice, I suggest you adopt the old programming rule of thumb: isolate anything platform specific in your code. If you're developing using C++, for example, define interfaces (probably via abstract base classes or in terms of templates) that represent the low-level functionality for serial comms, threading or whatever. Write all your higher level code in terms of those interfaces.
Then you just need to write the implementation behind them for each platform. This may be as simple as writing a few inline forwarding functions if your platform provides native APIs to do what you want. (Obviously I'm including any platform-specific or cross-platform libraries you have in the term "APIs", not just OS-provided functionality.) If, for any particular platform or library, there isn't a direct API to do what your interface requires, you can write a more complex routine in your implementation using the APIs that are available. It will still be isolated from the rest of your code, and nothing higher-level should need changing (or, hopefully, even rebuilding).
If you adopt this approach, the vast majority of your code will probably be 100% portable, because all it depends on is your own "middle level" APIs. Those can be implemented in whatever way is most convenient on a given platform, which might still include writing them in terms of a cross-platform library. The key thing is that most of your code isn't tied to anything platform-specific at all this way, and as such is immediately portable anywhere as long as your middle-level interfaces are sensible -- which they will be, of course, since you wrote them. ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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)
It is quirky, a pain in the rear, time consuming, but less so than other cross-platform libraries.
I've used it in projects that required common threading, interprocess communication, and a few other things across NT, Solaris, HP-UX, AIX, and Linux. I point out all of the UNIX-like platforms as seperate entities because they all have enough quirks that you can't expect any given library to work across the board.
Oh, and to everyone that has been promoting ideas like "just use gcc" or "just use straight c++", maybe you've never worked on a large scale, long term project, but gcc is not the best option for an app that needs to be highly optimized and writting everything in c++ from scratch is a waste of time (that's why we have libraries in the first place). I'm not flaming here, just pointing out that you need to look at the bigger picture.
And this is all too common, I'm afraid. I once had to implement a massive, heavy-fines-for-errors project that needed to compare massive associative arrays in C instead of Perl. Why? Because the boss didn't like Perl.
The Independent: Reverend Spooner Arrested in Friar Tuck Incident - ISIHAC, Historical Headlines
Actually, no, but he DOES already have the answer.
QT 3.0 supplies everything he needs for platform independent sockets, threads as well as the gui. Serial port access is easy enough on both platforms to do yourself.
My only suggestion is to have a spare linux box with a cron job that checks out the latest sources from cvs, compiles, and emails you the error messages. Then he will be notified as soon as he checks in some sources that only compile on the lame VC++ compiler. I do that all the time and it is much easier to fix the portability problems as you go instead of in one big chunk at the end.
--jeff
ipv6 is my vpn
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
ABG is right, and you should isolate core functionality from data access and user interface - this is critical to portability and leads to evolution of strong, mature systems.
You will note that many business systems written in COBOL as "code monoliths" now require extremely expensive support in the form of CICS compatibility and cumbersome, user-unfriendly security layers. And their interfaces are still "green-screen" or, in many cases, have actually lost function and ease of use through poor GUI integration.
Meanwhile, many scientific systems written in a modular fashion live on despite having their underlying hardware replaced and their user interfaces re-written repeatedly. I'm sure there are systems that started on PDP-11s, are now running on Alpha VAXen, and are planning ports to linux clusters. Some will have been fitted with very pretty web interfaces.
Write your core modules, where the work is done, in ANSI C. Write your data access routines in the most portable language available on your preferred platform, and keep the code entirely distinct from the core functionality and user interface. If you're already invested in something like Rdb, Oracle, MySQL, whatever, then leverage the expertise and investment you already have but make sure your API is callable from C. Don't be afraid to use a fast, simple data store like Berkeley DB or plain old flat files - cheaper is better. But be sure to define a data access API in any case (such as Replace_Leaf_Record() and Create_New_Root(), for example) and keep the code cleanly separated into modules.
Provide a "raw text" interface, written in C, and keep that as the base functionality canon. Use it to test the GUI, which you can write in Java or C++ or Eiffel or whatever (I'd say use your favorite, since you'll get prettier results if you enjoy using the language). Make sure the API for the GUI is entirely documented in the core code itself so that it can be seamlessly replaced when the fabled post-GUI interface finally appears.
--Charlie