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

Kylix?

[Ubi_NL]

Why not write the whole thing in Delphi, which is -apparently- source-code compatible with Kylix. All you need to do then is recompile...

Use XPCOM + XUL

[rfmobile]

Good morning! Write your program as a XUL application! Say what? Yeah, that's XUL (pronounced zool) ... The folks that earlier suggested NSPR are on the right track but they stopped short of taking advantage of the cross-platform GUI aspects of mozilla. Design you UI using XML - that's XUL. Write modular components in C++ using XPCOM - a cross platform variant of COM. Compile and deploy to just about any platform that mozilla runs on - and *that* my friend is a lot! The bulk of your app can be defined using a few text files (XUL compatible XML tags with some Javascript). You might not even need to write *any* C++ code. Besides the docs available directly on mozilla.org, here's a link to some stuff I wrote: http://www-106.ibm.com/developerworks/webservices/ library/co-xpcom/ Enjoy.

Re:You have the answer

[tbone1]

Unless the specs are that it is to be written in C/C++.

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.

Re:You have the answer

[statusbar]

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

Re:And why can't you use Java?

[mvw]

Java meets all of the requirements you listed:

• Cross Platform

Which means it will run with all promised features only on Win32, with some drawbacks under Solaris, with other drawbacks under Linux (where it has a strange status between supported and unsupported) and is not supported at all under *BSD. The situation for Mac is not known to me, Jave seems to be available lately.

• Portability without changing a line of code (or recompiling for that matter)

Both is not true in general. Only non GUI programs, using only established APIs have a change to run without modification, so much for source compatibility. For byte code it turned out, that while the byte code it self might be stable, other stuff changed so much over time, that you are forced to recompile old classes (I had this experience with many security related APIs).

• Multi-threading

Multi-threading is still a complicated matter under Java, perhaps it is a bit easier because one just deals with one implementation per plattform in general.

But implementation is still different. Under Win32 you get preemptive multitasking, under other implementations (like Solaris up to certain revision) you have only cooperative multitasking. So you are still forced to stray yield() or sleep() into your loops.

I found debugging multithreaded apps under Java complicated as well, not too much help from the JBuilder IDE I used, and I was not able to detect certain stall conditions with JProbe's threadalizer. (Blame it on me or the tool :) I had to work things out with classic printf style debugging that gave me a hint, what thread was doing what.

• Network I/O

Berkley sockets are quite standard, be it UNIX or Win32 (WinSocks) that is not that hard.

• In addition, you can get security, high availabilty, and scaleability with far less effort and platform-dependence than a C/C++ solution.

I think that statement is bullshit. It largely depends on the experience of your programmer what is easier to use.

In my experience Java is still unforgiving. Good code runs well, but you will feel it if you run sloppy or bad code, be it speed or memory wise. Under C/C++ there is a certain margin of tolerance in that area. Alas you have to grok pointers, which seems to be seen as a problem todays.

On the good side Java has some large standardized libraries and nice development tools. I also believe that the average Java code is more modern, because it uses these modern libs.

Both approaches C++/QT/NSPR whatever or Java might lead to a working solution. Each has its strongnesses and weaknesses. (And there is other stuff, like functional languages :)

Again I would take the experience of the crew as the deciding factor.

Regards,
Marc

Re:You have the answer

[Novus]

Oh dear. What a load of FUD. I hope I'm not feeding a troll here.

Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.

Just-in-time compilation is roughly equivalent to compiling, then executing; this is hardly an uncommon scenario with C programs, is it?

It requires a virtual machine, so it will always be more bloated than c.

Again, this is untrue. Java can easily be compiled to native code.

As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.

Closed source is admittedly harded to port, but GCC isn't enough to provide a homogenous environment. E.g. GUI libraries vary a lot between e.g. Windows, Unix and Mac. These are highly cross-platform in Java.

There are "feature-rich" libraries that can be linked to in c also.

This part is quite true. However, the standard Java libraries are more feature-rich than the corresponding standard C libraries.

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.

Ease of use is an advantage to experienced programmers, too (as anyone who's spent ages chasing memory leaks can attest)!

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.

Actually, considering the existence of third-party implementations like Kaffe, Sun probably can't close Java completely even if they want to!

Paying for software

[dwsauder]

Why should Trolltech give their software away for free? How are they supposed to feed their families?