


Portable Coding and Cross-Platform Libraries? 531
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?"
A little known library is SFL (Score:3, Informative)
SFL is a great library for doing portable low-level stuff such as network etc..
GNU Compiler + CommonC++ (Score:2, Troll)
Now, I always heard that NT is supposedly Posix compliant so it might not be terribly difficult...
Re:GNU Compiler + CommonC++ (Score:2, Informative)
Common C++ not ready for prime time (Score:2)
As a whole, the CommonC++ design is pretty messy, relying on massive amounts of kludgy ifdefs and macros in the header files. I believe they are working on cleaning it up.
Other libraries I would consider:
ACE [wustl.edu]: threads, synchronization, sockets. ACE's design is not very object-oriented, but its probably the most extensively portability layer you will find.
IOLib [sourceforge.net], portable I/O (also includes identical ports for C and Objective-C).
ZThread [sourceforge.net] for threads.
Nescape Portable Runtime (NSPR) [mozilla.org], a C library: sockets/IPC, threads, synchronization primitives, layered I/O, ADTs/algorithms, portable shared libraries, logging, etc.
Re:GNU Compiler + CommonC++ (Score:2)
Since the two are completely isolated from each other, POSIX programs cannot make use of common Win32 services like networking, graphics, DCOM etc. All subsystems are implemented on top of the native, undocumented NT APIs (ntdll.dll).
Similarly, NT has an OS/2 subsystem which is capable of running OS/2 console programs. The original idea was that NT could expose different, swappable "personalities", of which Win32 is but one, but of course that potential has never been realized.
For more information, see Understanding Windows NT POSIX Compatibility [microsoft.com].
ACE ADAPTIVE Communication Environment (Score:4, Informative)
I've never tested this framework but it seems very good. I know several companies which use it and which are happy with it.
Re:ACE ADAPTIVE Communication Environment (Score:2, Informative)
I'll second the recommendation of ACE. In addition to ACE, The ACE ORB (TAO [wustl.edu]), Zen [uci.edu], their real-time ORB, and Jaws [wustl.edu], An Application Framework for High Performance Web Systems, are all worth a look. This stuff has been around for quite some time and has been ported to nearly every compiler-platform imaginable.
From someone who has used ACE professionally (Score:4, Insightful)
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 (Score:5, Insightful)
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 [wustl.edu]. 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 [boost.org].
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 [dinkumware.com].
From someone who also has used ACE professionally (Score:2)
And TAO that sits atop ACE, providing a real-time capable CORBA ORB atop it can't be beat either. Its use is less quirky than ACE and made possible a massively distributable financial and access control system that is in use at DFW International Airport and other locations. This system runs on both NT and Linux, with exception handling, etc. across both platforms working well.
Re:ACE ADAPTIVE Communication Environment (Score:4, Informative)
I (and my company) also use this library extensively in a number of C++ projects to do multithreading, socket communications and memory maps, just to name a few things.
It is open source, so it has the advantage that you can fix or patch bugs easily, and extend it if you want to.
Even if you don't use the cross-platform part of ACE a lot, the C++ abstractions for some common UNIX paradigms are great to have - for example you can turn a class into a thread, etc.
Re:ACE Hints / Tips (Score:2)
It works great and is incredibly portable. My only advice is to be sure to get familiar with the configuration of the entire package, like features and options and components before you settle on a given configuration for use in your project.
ACE+TAO are designed to run on a large number of platforms, and support C++ without exceptions, explicit STL template definition, and a number of other features which are really handy for some environments, but dont serve a default installation well.
Some of these options affect the way your code interacts with the library, and require you to write and/or compile your code accordingly. Obviously you do not want to get half way into a project and realize you need to change some configuration options, and then go back into your code and make the requisite changes to support these modified configurations. (This isnt a big deal, as everything is pretty well encapsulated, but it can cause headaches)
I'll give you a few examples of things that I ran across.
1. CORBA. I had used the TAO orb to compile IDL without native exceptions, producing stubs and skeletons that used a CORBA::Environment arguments in all methods to provide the hooks necessary to handle exceptions without using c++ exceptions. Later I switched to native c++ exceptions, and had to modify the function declarations and definitions to remove this now unnecessary CORBA::Environment argument.
2. I had built ACE with the 'no implicit templates' option, which required that all member templates be explicitly defined in the sources files where they were used for linking correctly. Later I switched to gcc 3.0.2 and started using implicit templates. I had to recompile ACE with this new configuration, and also modify my code to remove all of the explicit template definitions that I had added.
3. I had initially been building ACE + TAO with all components and features enabled. This led to very, very long compile times (I am talking 8+ hours on a dual PIII 550 w/ 512M of RAM!) It turns out a vast majority of the stuff being built I didnt need, like a number of the CoS services, the realtime CORBA stuff, and some of the ATM and other networking features. I was able to tweak a few settings in the configuration / build files and this cut my build times down to about an hour. This is a BIG time saver.
Question (Score:5, Insightful)
Even just writing portable C++ code can be tricky, especially if one of the target platforms is Microsoft.
Doesn't have to be... (Score:2)
I happen to have done extensive projects w/VC++ (Score:2)
Its all in what you do/don't do coding-wise. And, I'd probably have a few horror stories to swap w/the people on comp.lang.c++.moderated over VC++ because I DO this sort of thing for a living and have done so for 6-7 years now.
Err, you told us didn't you? (Score:5, Insightful)
Re:Err, you told us didn't you? (Score:2, Informative)
'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.
Re:Err, you told us didn't you? (Score:3, Informative)
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.
Re:Err, you told us didn't you? (Score:2)
But it IS easy to write your own anyways on both platforms. No big deal. RTFM
--jeff
--jeff
Usr Open source tools (Score:4, Informative)
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.
wxWindows (Score:3, Informative)
Re:wxWindows (Score:4, Informative)
wxWindows [wxwindows.org] has Networking support (socket I/O, ipc,... whatever you want), thread support, a rich feature set for GUIs and much more (unfortunately there is no support for Serial I/O).
You might even consider to drop QT in favor of wxWindows.
It is availabe for Windows, XWindows (GTK based), Mac and some other platforms. It is released under the LGPL.
Re:wxWindows (Score:3, Insightful)
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
Re:wxWindows (Score:3, Informative)
Also the Qt-license is very restrictive. wxWindows [wxwindows.org] has a license [wxwindows.org] explicitly allowing the library to be used for commercial purposes.
wxWindows runs on Windows, MacOS (9 and X), GTK(+). Work is underway to implement a universal version of the library to be run on embedded platforms.
wxWindows is open-source. Patches and contributions are highly encouraged. Also the mailing-lists are very active with several of the main developers taking part in the discussion.
At least use the STL.. (Score:3, Informative)
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).
NSPR (Score:5, Informative)
Apache Portable Runtime (Score:2, Informative)
Re:Apache Portable Runtime (Score:2)
Not to slight the APR, it's a well engineering library. However I still think that the ASF would have been better served by reusing (and improving) the NSPR than making their own.
So much for code reuse in free software...
qt 3.0 have it all (Score:2, Informative)
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!
Rogue Wave (Score:4, Informative)
Re:Rogue Wave (Score:2)
A few years ago I used zApp. I coded up about 250,000 lines of C++ on OS/2 2.1, then ported it to 16 bit Windows. The port took less than a week - IIRC, there was about 50 lines of platform specific stuff. Mind you, OS2 and Windoze aren't that different and I am a genius.
The old Tools/threads/stuff.h++ stuff sounds like what's needed for the non GUI stuff.
Re:Rogue Wave (Score:3, Informative)
Which reminds me, their linux port *SUCKS*. The latest and greatest
So, to summarize, if you happen to be running one of the "tier-one" plarforms, their libs are pretty decent. Anything else, even if it's listed as "compatable", and you'll be screwed.
(as a quick example of what I'm talking about, our app has different defaults depending on what it was called as, tc vs. frpt vs. etc, and it does a simple check of ARGV[0] to see if it
This is wrong (Score:3, Offtopic)
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.
Could be a _customer_ requirement... (Score:2)
Don't bet on it. (Score:2)
Java isn't a great systems language- it's a great applications language and doesn't pretend to be anything more. You can do systems programming in an applications language, but the results are often less than stellar and a rough beast to maintain.
This is systems level programming and you need more than an applications tool to do the work right.
Kylix? (Score:2, Interesting)
Re:Kylix? (Score:2)
Re:Kylix? (Score:2)
Re:Kylix? (Score:2)
The biggest argument against Kylix would be that it compiles only x86 executables. Rumors are that other platforms will be supported in the future (esp. MacOS X), but Borland doesn't comment on rumors. If however x86 Linux is all you need, you should very seriously consider Delphi/Kylix.
-
Re:Kylix? (Score:2)
Can it be browser based? (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:2)
Make sure your interface is designed to place the least possible requirements on the underlying library, or else you may find it difficult to substitute another later. It would be wise to look at a few libraries (say, Qt, Gnome, and Windows' own) and concentrate on their differences, just to get an idea of the range of possibilities. Then design your interface in such a way that it doesn't rule any of them out unless it really needs to.
I know it sounds like you're designing your own GUI library from scratch, but that's not the case. You're simply expressing your GUI needs in terms of an interface which can be implemented easily in terms of existing GUI libraries.
Re:A more comprehensive approach (Score:3, Insightful)
Re:A more comprehensive approach (Score:2)
Yup, only way to code for the future. (Score:4, Insightful)
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
And why can't you use Java? (Score:5, Informative)
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?
Re:And why can't you use Java? (Score:2)
Exactly the same arguements could be used for Perl..
Re:And why can't you use Java? (Score:3)
Re:And why can't you use Java? (Score:4, Interesting)
- 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
Re:And why can't you use Java? (Score:2)
Re:And why can't you use Java? (Score:2)
Why? (Score:2)
My own personal experience indicates that he's much, much closer to the truth than you'd like to admit.
Depends... (Score:3, Informative)
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.
Cross-Platform Tools (Score:2)
I'd suggest you start with modeling the product in Tcl/TK on the NT platform, ensuring you don't reference any NT specifics. Once you're happy with the model. Copy the code to your Unix system, confirm it still runs, then compile it up into a binary executable for distribution. BTW, there's some nice GUI IDE tools available for Tcl/Tk, I'm rather fond of SpecTcl, a GUI for building graphical user interfaces, that will also produce java & html output.
Good Luck!
Threading/Serial/Network (Score:2)
Network - Again, as long as you don't do anything funky, and just use portable ansi/iso code, socket programming shouldn't pose a problem. Dont' go below port 1024 if your program won't run with root permissions, as many *nix's will only let root access those ports.
Serial - Ok, this could be a nightmare, find a good library.
SWIG (Score:2)
"SWIG is a software development tool that connects programs written in C, C++, and Objective-C with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk, Ruby, Guile and MzScheme."
You can write your code as portable C++ classes, and then use SWIG to automatically read in the header file, and write out all the glue code to plug your C++ classes (or C libraries) into the scripting language of your choice.
-Don
Beware SWIG (Score:2)
However I recently downloaded the SWIG based OpenSSL Python bindings (mtcrypto) and on my first attempt the build failed because the SWIG syntax had changed between releases. I would advocate not using SWIG for anything important until it stabilises.
The SWIG homepage appears to back me up here: "
SWIG is currently in a state of redevelopment in which substantial parts of the system are being reimplemented. This work can be found in the SWIG1.3 series of releases. If you are concerned about stability or are a first-time user, you may want to download some variant of SWIG1.1 instead. Caveat--SWIG1.1 may not be compatible with recent releases of certain scripting languages such as Perl 5.6 and Guile."
Re:SWIG ... or sip (Score:2)
Use XPCOM + XUL (Score:2, Interesting)
If you haven't tried to port it, it's not portable (Score:2)
The key thing is that you must develop for at least three platforms from the start. My initial work was on Solaris, Linux, and VMS. This allows you to find (most of) the inconsistencies early and design around them before they get too embedded in the project to ever change.
You also need to identify what things are very likely to change across platforms (in my case it was threads, networking, and file I/O) and abstract those out from the start. Write wrapper functions and use them. Actually, I wish I had wrappered more of the output functions; as it is, the app's a little too dependent on ASCII. Given a few wrapper functions I could easily have supported EBCDIC and Unicode; now it'd be a bear to add that.
Stick with anything ANSI, and POSIX is good. C++ still hasn't finalized everywhere, not like ANSI C. If you write in ANSI C it works darn near everywhere. Windows doesn't do POSIX threads natively, but if you aren't doing anything really weird, wrapper functions can handle that. (All I needed was threads with default stack sizes, and mutexes.)
Not that all the Unixes are the same. AIX in particular has some non-standard silliness in its implementation of pthreads. A comment from my code:
A few #ifdefs can take care of things like that. But really, really, really: Port from the start!
For the GUI part of it, make a separate front-end app. Use something portable for that; a library or Java or whatever. Speed is hardly ever a problem for GUI front-ends. Just make it simple and reuse as much code as you can between platforms.
Use the NSPR - Netscape Portable Runtime (Score:2)
portable CORBA and threading: omniORB (Score:3, Informative)
Why make it cross-platform? (Score:2)
Re:Why make it cross-platform? (Score:2)
I guess you could work the other way, and start writing for NT, and making sure it runs under WINE, but since this is slashdot, I fig'd targeting Linux would work best (IE get modded up to a point where anybody will read it).
wrong question. (Score:2)
The correct question: "why are our requirements so f***ed up?"
Seriously - there is absolutely no reason to develop on NT, test on NT, and deploy on Unix, and there are a number of good reasons not to follow that path. If you're going to deploy on Unix, you can develop the system on Unix using cheap hardware and more-or-less free Linux or *BSD development systems. You are setting yourself up for about twice as much work as you need to be - just develop the thing on Linux or *BSD to begin with, stick with standard Unix portability guidelines (there are a couple of good *nix portability guides out there from O'Reilly, although at the moment I can't remember the associated cover animals), and call it good. Don't add extra portability into the plan that doesn't really buy you anything.
I could understand if you foresee a future need to port back to Windows, but absent such a requirement at the present, I really think you want to plan the easiest development plan that's consistent with your current deployment requirements. Just ditch the whole NT thing entirely, or if it's a matter of "well, we already bought you these NT boxes to use", then reformat them and install Linux or *BSD on them. Even in the worst case, moving *nix code to Windows will be less painful than moving Windows code to *nix - Unix is designed for portability somewhat, Windows is specifically designed to make it harder to port applications to other platforms. That is not where you want to start out from.
Also, if you do have to do the Windows thing, don't test on NT, test on 2000. In the 2-year timeframe that you're aiming for, nobody's going to want to actually run on NT. So if Windows must be in the picture, then develop on 2000, test on 2000, and deploy on 2000. Again, save yourself from some headaches that aren't necessary.
Common Lisp and Smalltalk - actually portable... (Score:2)
I know this is a C/C++/Perl/Java bigot crowd, so I'll keep this short.
What about Common Lisp or Smalltalk? Both are quite portable, and reasonably fast. Common Lisp can even be fully compiled to machine code. They both fill all of the other requirements.
Two notable implementations of CL are CMUCL [cons.org] (Free) and Allegro CL [franz.com] (free trial, commercial- but solid).
As far as Smalltalk, the notable implementations for your project are VisualWorks [cincom.com] and IBM's VisualAge for Smalltalk. Couple summers ago I worked at a shop which was heavily into VA/ST, and it was a pretty awesome system. Core of their business, and we're talking about a pretty big insurance company.
Java, baby (Score:5, Informative)
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.
Not so for some things... (Score:2)
Some definitions:
Systems programming: Driving hardware with software and/or providing interfaces to system resource (i.e. Your OS itself). This includes industrial I/O stuff like you'd see with an energy management system. It's often timing critical with delays causing no end to problems with things working let alone working right.
Applications programming: Just about everything else.
Just because Java does a bang-up job of doing one, doesn't mean it works well for the other. For an energy management system, down to even the UI, the results must always be predictable and consistent for it to be of any use. For the UI, there's some slack for things like GC causing a second or so delay- and at seemingly random intervals. Java's a decent candidate for that. The flipside is that the controls underneath the UI don't want, don't need, can ill afford random delays like that because you could get into oscillations of operation that burn up any advantage you had by the management system in the first place.
either Java or .net (Score:2, Funny)
Use a different language (Score:2)
I find it amazing that programmers spend so much time looking for good libraries, but don't stop to think about their choice of language and spend the same amount of time looking for a good language to use.
Cygwin? (Score:2)
Since it is going to a native UNIX environment, what about using Cygwin? Has anybody used this in a production environment which demands high-reliability?
For a GUI you could always use a web browser. I expect remote administration is probably a plus if it is going to eventually be running on a UNIX box... not that X doesn't provide similar functionality.
Of course the usual caution must apply that what the customer plans 1.5 years from now (i.e. going to UNIX) is not necessarily what they'll do... you could very well be stuck with Cygwin forever.
ObjectSpace C++ Toolkits (Score:2)
It's been a few years since I've used them, but I used them on solaris and hpux with both the proprietary compilers and gcc, and I know their headers had provisions for the MS compiler.
Re:ObjectSpace C++ Toolkits (Score:2)
Re:ObjectSpace C++ Toolkits (Score:2)
For example (IIRC), you can instantiate threads like this:
Thread t1 = new Thread("WorkerThread", &MyWorkerClass::run);
And things like sockets also have a nice OO abstraction that hides the platform (or posix) details.
I haven't used Qt, so I didn't know about the container classes, however, the other uses of ObjectSpace seem to fit the needs of this project quite nicely. Though, if no STL was going to be used anywhere else, this would add quite a bit of overhead.
STL and boost (Score:2)
First, make sure you are using the STL. Others have pointed this out already and they are right. Second, Qt provides much of what you want. It is pretty good that way. Third, check out http://www.boost.org/ which has several other very useful libraries.
An idea... (Score:2)
Incidentally, I really like Qt, and it's great for commercial projects but as a Free library apps you really want to be cross-platform but can't afford to pay their Windows licensing fees for, I have become increasingly fond of wxWindows.
It has it's quirks, yes, but its greatest stregth IMHO is a very nice, well supported Python API. I swear it's at least 3-4 times faster to build a GUI in wxPython than in anything I've seen in C++, even using GUI RAD tools (which only get you so far before you start having to hack at source). Just my opinion, anyway.
Qt already does everything you need... (Score:2)
Before looking into additional tools, look closer at what you're already using.
(On a personal note, btw, I don't use C++/Qt -- I prefer to use Python, which provides a sufficiently uniform interface for my needs, with its Gtk bindings, which are available on both the platforms you mention. Since these decisions are already made for your project, however, I'm not going to try to push them here).
Don't know about serial ports... (Score:2)
--JRZ
learn QT as it does most of that (Score:2)
Use CVS for cross platform source control (Score:2)
The original developer (1.0 was Windows-only) wanted to use SourceSafe; it's a Windows-based source control system, but he'd heard there was also Unix support. I'd tried to use it on my previous project; true for small values of "support".
We use CVS, checking out onto Windows or onto Unix, hosted on Unix. It just plain works.
FYI, we could not find any way to check out one copy of the source on one platform and build on the other. Visual C++
P.S.: I have no personal experience with ACE but have also heard good things about it. Commercial support is available from Riverace, if that's an issue.
ACE/TAO for massively cross platform applications (Score:2)
Expect to spend some time getting used to the toolkit, which ever one that winds up being. Every minute you spend initially studying example code, and learning the toolkit's way of approaching problems, is one less minute you will spend trying to beat their classes into doing something they weren't necessarily intended to do.
Unless you know what you're getting into up front, keep separate make strategies for Win and Unix. If you're feeling perky after a while, you may be able to migrate your windows build to the same makefiles as unix, but it'll take some work (and probably the cygwin toolset)
anything other than java... Why? (Score:2, Insightful)
If that's their major concern, I would recommend building it in Java from the start.
Re:NT vs Unix. (Score:2)
Just be glad its not the other way around and they're not migrating from Unix to NT.
Re:You have the answer (Score:2, Troll)
Re:exactly wrong (Score:2)
Re:You have the answer (Score:3, Interesting)
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 (Score:3, Interesting)
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:You have the answer (Score:3, Informative)
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.
Re:You have the answer (Score:2, Informative)
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
Re:You have the answer (Score:2, Informative)
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.
Re:You have the answer (Score:2, Interesting)
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 [kaffe.org], Sun probably can't close Java completely even if they want to!
Who needs speed of C in age of PHP? (Score:2)
Re:Just use the gcc, g++ (Score:2)
The current cygwin g++ compiler is not compiled itself with the appropriate flags to generate thread safe RTTI and exception handling code.
threads + cygwin + g++ +
unless you use -fno-rtti -fno-exceptions
Yes, this sucks.
--jeff
STL? Yeah, right... (Score:2)
Porting it to HP-UX was a headache; the STL's on the platforms differed in a multitude of subtle ways. AIX has been even harder (there may be something good about AIX, but I haven't run into it yet).
The STL seems to be about where C was when the ANSI spec first came out. It took several years before code was really portable...
Re:Ummm... POSIX? BSD Sockets? (Score:2, Insightful)
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/cygutil
Re:This community needs to embrace Java (Score:2)
Java has not much margin compared to C++. You have to code quite good Java.
Yes, the VM got faster. It is not the VM that is to blame all the time, expect for those occasions when native libs want to shovel data into the VM and back.
Trust on the garbage collection leads to memory bloat. The high level leads to the construction of deep nested objects that cost much time and memory to construct.
Not that it is different under C++, but people stick closer to the metal there.
Like you wrote, it depends largely if the developer is able to handle the tool.
Regards,
Marc
I'm not Java bashing, but Java may be a bad choice (Score:2)
An energy management system more often than not has to deal with industrial I/O systems such as an Opto-22 interface or a ModBus interface. This often requires system level coding resources Java doesn't provide in any way, shape, or form (because it's not part of it's model of how things should be). To claim that you can code those portions in C or C++ and interface them is silly- it's inserting needless complexity (in the form of having to support two differing languages and having to maintain interfaces suitable for JNI.) for no good reason. If you have to resort to using C or C++ for something, it's more often than not better to code the whole thing in one of those languages.
Coding the UI in Java is an arguable task. On the one hand, you've got the nice API designed for doing UI coding. On the other hand, you're back to adding needless complexities into the system in the form of multiple languages and RPC interfaces unless you're using CORBA between the UI and the energy management system engine. Again, you may be better off, based on my personal experience as a software engineer of 12+ years of experience in the industry as a whole, to code the thing entirely in the base language- it'd be simpler for the whole source tree.
And this doesn't even get into what the customer wants. If they want C/C++, then they get it.
Mozilla's Article is Old and Wrong (Score:2)
The Mozilla "C++ portability guide" is long out-od-date, having been written in early 1998 before the C++ Standard was even official. The Mozilla document makes many uneducated assertions that would lead to poor programming practices.
Any article that suggest the use of macros over templates is clearly no written by anyone who has worked with C++ in the last couple of years.I've been writing, publishing and preaching portable C++ for more than a decade, and I have substantial code bases that compile and run, with MINIMAL conditional compilation, on multiple platforms (hardware and software). What the Mozilla document advocates isn't portable C++, because they threw out almost everything that *is* C++.
Re:Qt 3.0 for Win32? (Score:2)
That's funny, because I get paid to develop an app for Linux and Windows which uses Qt 3.0. AFAIK Trolltech hasn't released a free version of 3.0 for Windows yet (although they should soon), but the commercial Windows version was released at the same time the X11 version was.