Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Portable Coding and Cross-Platform Libraries? 531

Posted by Cliff from the multi-platform-development dept.
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?"
This discussion has been archived. No new comments can be posted.

Portable Coding and Cross-Platform Libraries? More

Portable Coding and Cross-Platform Libraries?

Comments Filter:

  • A little known library is SFL (Score:3, Informative)

    by Hougaard ( 163563 ) on Thursday November 15, 2001 @07:51AM (#2567977) Homepage Journal
    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..
  • The GNU Compiler (gcc/g++) runs on so many platforms so it should solve a lot of portability issues. CommonC++ is a GNU library for threading and I also believe it can handle network IO.

    Now, I always heard that NT is supposedly Posix compliant so it might not be terribly difficult...
    • GNU Common C++ certainly does abstract network I/O (sockets) as well as threads, serial I/O, XML parsing, and logging. There is also a supplimental RTP stack for it (ccRTP). It compiles native under win32 as well as under posix targets. It recently has had a very extensive rewrite, and is still recovering from that.
    • At least when I tried it a few months ago, CommonC++ did not compile correctly under Windows. Its configure script did not even work out of the box, failing to detect Cygwin and Visual C++. It compiles fine on Linux, but the Win32 support seems to have been neglected for a while.

      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.

  • ACE ADAPTIVE Communication Environment (Score:4, Informative)

    by n-tone ( 535094 ) on Thursday November 15, 2001 @07:54AM (#2567984) Homepage
    ACE [wustl.edu] 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.

    • 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)

      by Christopher Bibbs ( 14 ) on Thursday November 15, 2001 @08:37AM (#2568089) Homepage Journal
      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 (Score:5, Insightful)

        by RalphTWaP ( 447267 ) on Thursday November 15, 2001 @09:55AM (#2568316)
        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 [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].

      • Indeed.

        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)

      by irix ( 22687 ) on Thursday November 15, 2001 @11:38AM (#2568886) Journal

      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.

    • I have used ACE and TAO (the ACE CORBA ORB) for a number of projects.

      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)

    by SimonK ( 7722 ) on Thursday November 15, 2001 @07:55AM (#2567988)
    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.
    • Just don't use VC++'s "features" such as many of the wizards. Don't use MFC for UI development- use something like Fltk, WX, etc. And, don't use COM/DCOM if at all possible, using CORBA or XPCOM when you need something like that.

  • Err, you told us didn't you? (Score:5, Insightful)

    by mainframe_uk ( 228734 ) on Thursday November 15, 2001 @07:55AM (#2567989)
    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.
    • Right. Serial port stuff is another issue. Most of the serial port stuff that I've seen written was either written years ago, or based off of stuff that was written years ago. What you'd have to do, more than likely is either find a serial port library that wraps around OS functionality, or write one yourself.

      '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. :)
      • Even if the serial stuff was written years ago, is that such a problem? What difference is there between a serial port 10 years ago and a serial port now? My guess is not a lot, other than perhaps faster baud rates, but I don't think even that has changed in about 5 years (how long have we had UART 16550?).

        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.

        • Some libraries compiled for Win98 serial ports will not work with Win2000 serial ports. The API sucks and is overly complex (hey, it is micro$oft!) - also, the API does not deal with 16550 directly. AND-, at 115kbaud, the NT serial driver WILL lose data bytes, even on a dual pentium. So you gotta EXPECT dropped bytes. No one usually notices this because they are usually using PPP which handles the re-send for you.

          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)

    by Lumpy ( 12016 ) on Thursday November 15, 2001 @07:55AM (#2567990) Homepage
    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.

  • wxWindows (Score:3, Informative)

    by Anonymous Coward on Thursday November 15, 2001 @07:56AM (#2567996)
    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.

    • Re:wxWindows (Score:4, Informative)

      by joerg ( 55054 ) on Thursday November 15, 2001 @08:47AM (#2568122)

      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)

        by rs_nuke ( 193165 )
        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...

    • Re:wxWindows (Score:3, Informative)

      by erlando ( 88533 )
      And it has the IMO great advantage over Qt in that it uses native widgets where possible. Qt draws its own widgets afaik.

      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)

    by reachinmark ( 536719 ) on Thursday November 15, 2001 @07:58AM (#2568001) Homepage
    We have our own API that we used to support on both unix and NT. It was originally developed on IRIX, and we made extensive use of the C++ Standard Template Library which made things a bit easier when porting to NT.

    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)

    by machingo ( 262492 ) on Thursday November 15, 2001 @07:58AM (#2568002)
    Check Netscape Portable Runtime [mozilla.org], (just one of the many projects [mozilla.org] that are part of Mozilla. This library provide cross-platform threading, IPC, network/file IO, and dynamic linking, among other things.
  • would be a good place to start for the threading and networking parts. from what i've seen, it looks like a well engeneered package (and you'll have a hard time finding a better tested library :-). http://apr.apache.org/ [apache.org]
    • Not really... Netscape Portable Runtime [mozilla.org] is at version 4.1. The APR came about with the development of Apache 2.0 (still not out of beta yet). NSPR had been tested and used since before Mozilla started development. It's been the cross-platform glue that put Netscape Communicator on so many different kinds of computer.

      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)

    by eske ( 211780 )
    Well if you are using qt for GUI why not use the
    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)

    by sql*kitten ( 1359 ) on Thursday November 15, 2001 @08:02AM (#2568010)
    You need SourcePro [roguewave.com] 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.
    • Didn't they get the old zApp class libraries (mostly GUI) as well? They don't seem to be pushing C++ stuff much on their website (traitors!) so I can't tell.

      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)

      by Teancom ( 13486 )
      We have used .h++ for years around here for our main inhouse app. We decided just yesterday to remove all remaining dependencies and go to straight stl. Why? Because .h++ is not source-code compatabile with SourcePro, they provide no migration path, or even a "porting howto" (all according to our account rep). So we are faced with either spending the time and energy porting from .h++ to SourcePro, or spending the exact same amount of time and energy porting to the stl, with the side benefit of making our app linux compatable.

      Which reminds me, their linux port *SUCKS*. The latest and greatest .h++ will run on Redhat6.2, with gcc 2.95.2, the stock kernel, and *thats* *it* (not even perfectly, there are serious bugs). Any other platform (we've tried mandrake 7.2,8.0,8.1;debian2.1,2.2;redhat 7.0,7.2) will segfault/core dump. Their next release, due January, will run on redhat 7.1. I have no doubt that it will fail to run on anything else. So it really falls down wrt cross-platform compatability.

      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 .contains the various names. It doesn't work on linux. Flat-out returns the wrong value. And that's on redhat6.2. Any attempt to use their string class will immediately seg-fault. I'm seriously disappointed, in case you couldn't tell.)

  • This is wrong (Score:3, Offtopic)

    by Nicolas MONNET ( 4727 ) <nicoaltiva AT gmail DOT com> on Thursday November 15, 2001 @08:06AM (#2568022) Journal
    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.
    • Ever thought about that one, hm?

  • Kylix? (Score:2, Interesting)

    by Ubi_NL ( 313657 )
    Why not write the whole thing in Delphi, which is -apparently- source-code compatible with Kylix. All you need to do then is recompile...
    • Not necessarily. If you use ONLY Delphi/Kylix libraries, that's probably true. As soon as you make a raw Win32 API call, forget it. Dollars to donuts says the thing won't compile under Kylix. I have no practical experience trying to get Delphi apps to compile on Kylix (yet), but based on what I know about writing other stuff cross-platform, and combining that with my knowledge of Delphi, that's my story and I'm sticking too it. :)
      • The thing is, almost all the features desired are already handled in the class framework for Delphi (the exception being Serial communications, which really are quite simple under Win32, which leaves writing your own cross-platform class(es) to handle it, or finding someone elses and porting them or using them). About the only time you'd ever use a Win32 API call is for a feature that wasn't implemented that you needed, and that's what {$IFDEF ...} is for.
      • That's true about Win32 calls, but that's not as big a problem as it might appear. Especially for business-type apps that don't need exotic hardware access, the VLC wrapps the OS quite nicely. And chances are that someone wrote a component to do what you need, and that this component will show up in Kylix sooner or later. I'm pretty sure many of the Delphi serial port components will be available under Kylix, if they're not already. The socket components already are.

        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.

        -
    • Whichever person with moderator points modded this Off-Topic, please shoot yourself, and spare us more of your idiotic moderation skills. Suggesting Kylix is a completely fair stance.

  • Can it be browser based? (Score:5, Insightful)

    by Ami Ganguli ( 921 ) on Thursday November 15, 2001 @08:08AM (#2568025) Homepage

    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)

    by Anonymous Brave Guy ( 457657 ) on Thursday November 15, 2001 @08:11AM (#2568036)

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

    • Absolutely right. Otherwise, you're at the mercy of an unknown factor. This is what software engineering is all about.

      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.
    • So, write your own cross-platform library since none available is taylored to your own needs. ?
      • No. Abstracting your code provides you many things. Only ONE of which being the ability to cross compile easily. It also allows you to cross compile using DIFFERENT libraries on the SAME OS. Or even provide different networking capabilities. It makes alot of sense, really..

    • Yup, only way to code for the future. (Score:4, Insightful)

      by Medievalist ( 16032 ) on Thursday November 15, 2001 @11:59AM (#2569024)
      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

  • And why can't you use Java? (Score:5, Informative)

    by Anonymous Coward on Thursday November 15, 2001 @08:16AM (#2568045)
    You clearly point out that you have prior experience with Java. Java meets all of the requirements you listed:
    • Cross Platform
    • Portability without changing a line of code (or recompiling for that matter)
    • Multi-threading
    • Serial I/O
    • Network I/O

    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?



    • Exactly the same arguements could be used for Perl..

    • Re:And why can't you use Java? (Score:4, Interesting)

      by mvw ( 2916 ) on Thursday November 15, 2001 @10:33AM (#2568503) Journal
      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

      • Eh, a JDK exists for FreeBSD, and if that isn't good enough, the Linux one'll run just fine. There's even a port for it.
      • Sorry, dude, Linux is fully supported and the Linux JDK is distributed by Sun. You must be thinking of 2 or 3 years ago when the Blackdown JDK was originally built with support from Sun but by outside developers. Who still work on the JDK as far as I know, but there is an in-house team at Sun as well (and I haven't seen any of the parallel track Blackdown-Sun releases since JDK 1.2.2).

    • Depends... (Score:3, Informative)

      by Svartalf ( 2997 )
      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.
  • It seems to me that you're looking to prototype on the NT platform, and construct the production environment on Unix. Tcl/TK is a wonderful tool that promotes rapid application development, and multi-platform (nt,unix, mac, etc). Whether you're aware of it or not, all of the major industry players have been using Tcl/tk in their products, Oracle with oratclsh, IBM with wscp (their tcl/tk interface to websphere), Vignette with the tcl/tk interface. Also, considering that Ajuba has placed TclPro in the open-source community, you can DL the Unix & NT version's for free. The really nice features of TclPro, is that it contains the tclcompiler (to byte-compile your tcl/tk code), and the tclwrapper (to wrap your code into a binary executable). Most of Tcl/Tk's libraries are cross-platform, though there are specific's to both arena's, (i.e. IPC on Unix & Registry calls on NT).
    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 - It has been my experience that since various operating systems handle threads differently, your thread behavior will be slightly different on each OS, however, the threading code will remain the same. This code should be portable with no problems as long as you do it in a standard (ANSI, ISO that is) kind of way. The only problems that may come up are timing issues, but these are easily solvable (like a day of labor for a real brain stinger), and rarely come up as long as you didn't do anything unorthodox.

    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.
  • Check out SWIG [swig.org], the Simplified Wrapper and Interface Generator.

    "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

    • SWIG looks like it'll be great when it's done.

      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."
    • Sip has NO documentation, but it has the advantage that it's used for the Python Qt bindings. It's reasonably easy to use, though it really could do with some documentation.

  • Use XPCOM + XUL (Score:2, Interesting)

    by rfmobile ( 531603 )
    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.
  • I wrote a non-GUI background app for my company that runs on about six flavors of Unix and VMS as well. I ported about 60% of it to Windows as a knock-off project to help solve a customer problem. Writing portable code is possible, but difficult.

    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:

    /* AIX documentation is incorrect and its threads don't follow the standard, we have to explicitly declare that the threads aren't detached and can be joined. Worse, they use the nonstandard "PTHREAD_CREATE_UNDETACHED" constant instead of the standard "PTHREAD_CREATE_JOINABLE". */

    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.

  • This is a cross-platform C lib and networking runtime. It's production quality and free. See mozilla.org for more info.

  • portable CORBA and threading: omniORB (Score:3, Informative)

    by matthew_gream ( 113862 ) on Thursday November 15, 2001 @09:56AM (#2568322) Homepage
    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.
  • Why not just start out on Unix? I mean, think about what you are saying. Develop on NT, test on NT for 12 months, run on NT for 12 months...then switch to Unix. Why not drop the superfluous OS and go straight to Unix? If UI is an issue, build a portable UI (in Java or whatever) they can run wherever they want.
    • Here's one.. write the original app for Linux (or BSD or whatever) and then use VMWare or something when it needs to be deployed on NT/2k. You get the benefits of being able to run on multiple platforms and only writing the code once, while only slightly extending the testing cycle.

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

  • 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.

  • A lot of people have been suggesting Java, and just as many have been debunking it.

    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)

    by twdorris ( 29395 ) on Thursday November 15, 2001 @10:47AM (#2568554)
    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.


    • 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.
  • The way I see it you are going to be using either Java or a .net language. Microsoft's roadmap for .net includes a CLR that runs on Unix.
  • Of course it may not be up to you which language to write the software in, but if it is, then seriously consider using another language. C++ is a fun language, but isn't particularly suited for threaded programming nor for high portability. And for most programming tasks, correctness is much more important than raw execution speed. With this in mind, I would suggest using a language other than C++.


    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.

  • 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 provides a good, cross platform STL implementation, with toolkits that build upon it. ObjectSpace's C++ Toolkits [objectspace.com] cover multithreading with mutexes, semaphores, reference counting, communication with streams, pipes, sockets and files. They also provide some useful tools in terms of time and regexp.

    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.
    • But why use STL if you're already using Qt ? Qt already includes several container classes, and their cost per instance is considerably smaller than that of STL
      • My main point was that ObjectSpace provides the toolkits for doing multithreading and communications I/O.

        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.
  • Assuming you are writing in C++, which seems likely given that you are using Qt.

    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.
  • If you (or the client) are determined to go pure C/C++, Qt already provides almost everything you are asking about, except serial port support. So you have two choices: Go with Qt all the way and find a third party library or isolate dependencies to make your own mini-library to handle serial port access. Or go with one of the other perhaps more comprehensive toolkits mentioned here (ACE, etc.) which I know little about.


    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.

  • ...except maybe the serial IO. It certainly handles threading and network IO correctly, and serial IO isn't a hard thing to encapsulate and not much code to write twice (I don't know what the Win32 network interface looks like, so I can't comment much more about it).

    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).
  • But Qt 3.0 has fairly good cross-platform threading and networking libraries, in addition to its GUI stuff. See http://doc.trolltech.com/3.0/network.html [trolltech.com] for networking docs and http://doc.trolltech.com/3.0/threads.html [trolltech.com] for threading docs. Since you're already learning the "Qt way," you might as well use it for these features too.
    --JRZ
  • QT has a socket code, I think it has thread code, and much else. If you have already decidede to use QT as the GUI, I'd suggest using them for everything else. It should be cross platform compile okay.
  • I work on a medium-sized (~50-100K LOC) cross platform commercial application.

    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++ :-( was very unhappy about Unix-like end-of-line sequences. We check out on each platform, and keep them in sync more or less "by hand" (carrying files or patches from one to the other).

    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.
  • We use the same C++ foundation classes in ACE on WinNT, Win2k, Solaris, IRIX, HP-UX, and Linux. ACE is also supported on VxWorks, AIX, and a dozen other weird variants of *nix. It's a comprehensive real-time, networking, threading, and platform abstraction library. The stuff works great. Makes all platforms act the same. Takes a little work to get it compiled at first, though.

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

Slashdot Top Deals

The best defense against logic is ignorance.

Close