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?"

Comments

Question

[SimonK]

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.

Err, you told us didn't you?

[mainframe_uk]

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.

Can it be browser based?

[Ami Ganguli]

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.

A more comprehensive approach

[Anonymous Brave Guy]

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. ;-)

Re:A more comprehensive approach

[interiot]

So, write your own cross-platform library since none available is taylored to your own needs. ?

From someone who has used ACE professionally

[Christopher Bibbs]

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.

Re:From someone who has used ACE professionally

[RalphTWaP]

Absolutely,

As someone using ACE at the moment (well, in another screen). I can say that I've never found a more well-constructed cross-platform middleware package. You can find it here. In addition, the DOC group's TAO package provides a CORBA implementation on top of ACE that works really well for... well, those CORBA things *grins*.

One drawback when using any middleware package that I've seen is that you have to buy in pretty heavily to the package, somewhat adopting the development philosophy of the package's designers. With ACE that hasn't been as much of a problem (For instance, it provides a method of dispatching QT events) mostly because the underlying design is heavily pattern based.

On other fronts, I also continually find the Boost libraries to be very useful. They can be found here.

Probably the last thing to consider is that if you vary your development platform, you are likely going to be changing your C/C++ implementation--and they are not all created equal. Personally, I've found that the cross-platform availability and easy integration of the Dinkumware C/C++ libraries are pretty much worth the middle-of-the-road costs involved. Dinkum's located here.

Re:You have the answer

[matzi11a]

((buy more Mhz) && (save on dev time) == save on cash)

Re:Ummm... POSIX? BSD Sockets?

[Sir Runcible Spoon]

It does. However, things that run in the POSIX subsystem are unable to use those nice POSIX calls to access anything that is outside the POSIX subsystem. This typically includes everything, even bog standard features of the OS. When I was trying to port a UNIX app to NT some years ago, POSIX did not include some basic things like signals and common socket stuff, it certainly didn't give you any graphics. Consequently the POSIX subsystem at that time didn't provide them or even the WIN32 equivalent.

There was a rumour that MS didn't want anyone to use the POSIX subsystem. It seemed to be there simply to get a tick against the "Does it comply with the POSIX standard?" checkbox on corporate/governmental buyers requirements list. Once the sale is made, the POSIX subsystem is of no further use.

We eventually ported to the WIN32 subsystem using a toolkit called NuTCracker. It sort-of worked, but we eventually ended up doing a native port by abstracting out all the OS sprecific stuff.

There are other options to be considered. There is UWIN - http://www.research.att.com/sw/tools/uwin/. There is also the CYGWIN stuff (which seems to include OpenGL) which you can get at http://sources.redhat.com/cygwin/ (you might also need the extra CYGIPC at http://www.neuro.gatech.edu/users/cwilson/cygutils /V1.1/cygipc/ to do ipc).

Re:wxWindows

[rs_nuke]

A year back when trying to find out if I should choose QT or wxWindows, I noticed very poor reliablity with QT, I did experience several cores just by compiling the samples that came with QT on all *nix plateforms. (Solaris,HP-UX,IRIX,DUX) I remember my Solaris box often cored after playing with QT widgets... However, QT was _rock_solid_ on Linux, and windows.

wxWindows is far more a complete set GUI and more including I/O, networking, ODBC (database)! The nices part about wxWindows is the native look, of other *nix apps, on the unix world, which come with Motif R1.2 or better, using the Motif build of wxWindows gives a nice native look, and smaller executables! By linking with already found Motif libraries DSOs! I recalled some sample QT examples were like several megabytes! On non-x86 *nix boxes.

For someone that has been working with wxWindows, and tried QT, by far, I think wxWindows wins hands down. I don't know why it isn't as "famous" as QT.

My .02cents...

Yup, only way to code for the future.

[Medievalist]

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

anything other than java... Why?

[llamalicious]

Are you being simlpy forced to write code outside of Java because your employer/underwriter believes Java will be too slow for implementation, please remind them that the speed of Java applications with a good JVM and JITC can be as fast as C++ with well written code.
If that's their major concern, I would recommend building it in Java from the start.