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?"
Why not write the whole thing in Delphi, which is -apparently- source-code compatible with Kylix. All you need to do then is recompile...
If an experiment works, something has gone wrong.
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.
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
You're comparing apples and oranges.
"We don't have method pointers, so we use the method name and reflection"
In C/C++, retrieving a function from a (previously unseen) DLL requires a method name too. In Java, reflection does this. However, once you have the method, Java can pass a reference to it around using the Method object, whereas C++ passes a function pointer.
"We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit"
Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time. There are usually better ways to achieve the same thing, in both C++ and Java.
"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need"
That is either a gross generalisation, or a bad understanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.
"Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
This is a criticism of bad Java programmers using an object-based technology. You could as easily say "Lets make everything a COM object, and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
Java and C++ are separate technologies, with different strengths. You wouldn't write Quake3 in Java, and you'd have trouble writing a cross-platform, easily deployable, non-memory-leaking business application in C++.
People who cannot understand a technology will do stupid things with it. This applies to both C++ and Java. The difference seems to be that mediocre developers have had more time to become decent C++ programmers than they've had to become decent Java programmers (since Java is newer). Good developers keep an open mind, and decide on a project-by-project basis what the most suitable language/technology is.
The Java GUI was deemed to be too slow for our needs. Also, the target machines did not have enough memory to run Java applications. Java programs we found required three times as much memory to run.
Redundant? You mean simple? Yes, we can't have programming languages that make our lifes as developers simple. And lets write the most complicated code possible and let someone else maintain it.
Ugly? If you are comparing it to C, its like comparing apples to apples. They use the same structure and style!
Error prone? Try creating a memory leak or mishandle a pointer in Java. What? You cant do that in Java? You mean the two largest causes of bugs dont exist in Java? And it comes with exception handling? Oh my!!!
I program in both languages. C is nice for speed and raw power. But if I wanted a robust, cross platform, and error handled code (not free of bugs, but these bugs are not caused by Java but generally by us error prone humans) I would turn to Java. I have also been a huge fan of Java-C cross usage (many purist Java programmers may leave me here) using JNI and GCC (MingGw for Windows). That gives me a best-of-breed approach, power of C with the scalability and control of Java. I love these two in concert!!
- 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.
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
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!
Why should Trolltech give their software away for free? How are they supposed to feed their families?