Slashdot Mirror


Platform Independent C++ OS Library?

quench writes "Hello! I have been away from Windows and Linux application software for 5 years or so, doing mainly C-like embedded C++ programming. Now, I am about to start a project emulating embedded hardware on Windows. Been there, doing #ifdef WIN32 and #ifdef LINUX stuff, don't really want to go there any more. What I actually need is a platform independent lib covering Windows and Linux variants to handle sockets, IPC and threads abstractions. And a rock solid but simple embedded database to emulate flash memory. My reflex said, go for ACE and Berkeley-DB. Tell me, am I out of time? Am I missing something new and trendy, easier to use and better? Did time stand still?"

32 of 310 comments (clear)

  1. JAVA by Anonymous Coward · · Score: 3, Insightful

    This platform independent lib you are looking for is called JAVA.

    1. Re:JAVA by HiThere · · Score: 3, Interesting

      That's not really a bad suggestion. Ruby, Python, even some dialects of Basic would work.

      Also consider Pascal. There are dialects of Pascal that have strongly attempted to be identical across platform boundaries.

      Additionally, anything that's running on a virtual machine would be a reasonable consideration. That includes qemu and xen, not just Java, Python, etc.

      What's at question are "What are the requirements??". Without knowing that, there's no way to know which, if any, of these suggestions are reasonable. Given that the initial language is C++, I'd expect that Pascal is the best replacement, with Java a close second. But if speed isn't a limiting factor than the other suggestions should be given consideration.

      Of course, what he's asking it probably more readily answered by something like FLTK, but it's hard to know, since we don't know exactly which features he needs to be handled by his library. FLTK is platform independent, and callable from C++, but pretty much only handles the graphic interface. If that's all he needs, then it's a good answer, but we don't know what his needs are.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  2. Qt by Anonymous Coward · · Score: 5, Insightful

    Nokia QT rocks...

    1. Re:Qt by KirstuNael · · Score: 5, Informative

      I concur. My Qt-powered multithreaded and networked (TCP&UDP) application is compiling and working nicely in linux, osx and win32 without any os-specifc #ifdefs.

    2. Re:Qt by Anonymous Coward · · Score: 4, Informative

      Point for point:

      - sockets
      - IPC
      - threads abstractions
      - Database. Well, not quite so simple, but Sqlite3 as backend is available.

    3. Re:Qt by rtfa-troll · · Score: 4, Informative

      OP didn't say anything about UI, as you'd surely know if you had bothered to read the summary:

      QtCore has more or less nothing to do with UI.

      --
      =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
    4. Re:Qt by Lord+Kano · · Score: 3, Informative

      It's LGPL (So it's free for commercial projects as well)

      I'm sorry to nitpick, but this is an important distinction. You can use GPL code in a commercial project. I don't think that there's any dispute that RHEL is a commercial product. LGPL allows you do use code in proprietary projects.

      LK

      --
      "Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
    5. Re:Qt by jmv · · Score: 4, Interesting

      I've once attempted to use Gtkmm for a new project. While the API is generally well designed, I found that the documentation for many features was totally inexistant. Even more annoying was the fact that some components were either buggy or not wrapped (from C Gtk) at all. Combined with the fact that components get created and deprecated at a huge rate, you don't even know what you should be using. Overall, I've had a really bad experience with Gtk (and especially gnome) development. I've only tried using Qt a little bit and so far I like it a lot. I've never done GUI with it though. I've used the "platform independent system library" part for things like threads, sockets and the like. The only thing I found a bit annoying was that it didn't integrate well with the STL.

    6. Re:Qt by digitalunity · · Score: 3, Funny

      Mono on windows isn't there yet.

      --
      You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
  3. Qt by Anonymous Coward · · Score: 5, Informative

    Use Qt. It's LGPL (So it's free for commercial projects as well), is well documented and offers a ton of abstractions (including sqlite).

    http://qt.nokia.com/

    And tool support is excellent as well (Visual Studio Add-In, Eclipse Plugin and a standalone IDE called QtCreator).

  4. Pthreads by SoftwareArtist · · Score: 3, Informative

    I've used Pthreads successfully as a cross-platform threading library. http://sourceware.org/pthreads-win32 is a quite good implementation for Windows, and it's built into Linux (and all other POSIX compatible OS's, such as OS X, as well).

    --
    "I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
  5. TBB works wonders for threading by Wrath0fb0b · · Score: 5, Interesting

    Intel Thread Building Blocks (http://www.threadingbuildingblocks.org/ is (are?) fantastic. Open source (GPL), works on any ISO-compliant C++ compiler and is fairly intuitive. It allows both high-level (parallel_for) and low level (task-based) parallelism. Particularly useful are the concurrent containers, since it saves you from reimplementing these basic structures.

    1. Re:TBB works wonders for threading by Wrath0fb0b · · Score: 3, Informative

      From the FAQ - http://www.threadingbuildingblocks.org/wiki/index.php?title=Licensing:

      TBB is available under the common OSS license GPL v2 with the libstdC++ Runtime Exception. This is the same license used for a variety of well-known OSS applications including MySQL, NetBeans, and the Linux kernel.

    2. Re:TBB works wonders for threading by PCM2 · · Score: 3, Informative

      You're quoting from the commercial license. TBB is quite explicitly dual-licensed. If you don't like the terms of the commercial license, you have the option to use it under the terms of the GPL v2.

      --
      Breakfast served all day!
  6. Boost by aePrime · · Score: 4, Informative

    Boost has libraries for each of these three: sockets through the ASIO library, IPC through the Interprocess library, and threads through the threads library.

    http://www.boost.org

    The only thing that Boost is lacking for which you asked is a database library.

    1. Re:Boost by mls · · Score: 4, Informative

      SQLite databases are small, powerful and platform independent and might be a good choice to fit your database needs. The code is public domain.

      --
      -mls
  7. Re:Boost? by Homburg · · Score: 4, Informative

    Boost has pretty strong threading support, which is the basis for the threading capabilities in the forthcoming revision of the C++ standard. Boost also has cross-platform IPC and socket libraries. It would be a good choice for the OP, I think.

  8. As someone working on a massive project... by QuoteMstr · · Score: 4, Informative
    I'm working on a rather large cross-platform C++ project at the moment. Here are a few tips:
    1. Use Boost. It's a very liberally-licensed, high-quality library from the people who created the C++ language itself. It contains a ton of cross-platform libraries that do lots of useful things, from threads to regular expressions to writing testsuites and parsing command-line options. If Boost provides a piece of functionality, there's very little reason not to use its version.
    2. See rule #1.
    3. If you need cross-platform code that isn't in Boost, at least use the following approach:
      • Create a common interface definition
      • In separate files, implement the interface in terms of various platforms' primitives
      • Keep platform-specific code out of the rest of your program; if you can help it, don't even include platform headers in most of your program
    4. Use autoconf to handle platform idiosyncrasies. There are a ton of available macros to help detect things about a build platform.
    5. Write testcases. You should write tests for all your programs, but it's especially important to do it for cross-platform code because it's easy to break something and not notice.
    1. Re:As someone working on a massive project... by Anonymous Coward · · Score: 3, Insightful

      Use autoconf to handle platform idiosyncrasies.

      Ugh. Autoconf & automake are the most horrible things I've tried to use in recent times. These tools are far from simple and what works with newer versions of the tools isn't even compatible with older versions. The syntax is antiquated and there are multiple ways to achieve the same thing each with different pitfalls.

      Somewhere there is a meteorite set to strike autoconf. I hope it gets here soon since it's about 20 years late...

    2. Re:As someone working on a massive project... by Anonymous Coward · · Score: 5, Funny

      it is all well and good, but he cannot even read options 3,4 and 5 because of your recursion!

  9. Re:Apache Portable Runtime by boilednut · · Score: 5, Informative
    From the wikipedia articel:

    APR was originally a part of Apache HTTP Server, but has now been spun off into a separate project of the Apache Software Foundation, and is used by other applications to achieve platform independence. The range of platform-independent functionality provided by APR includes:
    * Memory allocation and memory pool functionality
    * Atomic operations
    * Dynamic library handling
    * File I/O
    * Command argument parsing
    * Locking
    * Hash tables and arrays
    * Mmap functionality
    * Network sockets and protocols
    * Thread, process and mutex functionality
    * Shared memory functionality
    * Time routines
    * User and group ID services

  10. Re:ACE is great! by mallan · · Score: 3, Interesting

    Qt has been modular since ver 4, so you don't have to include the GUI components if you don't want to. The API is clean, elegant and consistent, plus the documentation is great. I don't have anything bad to say about ACE or Boost - they're both high quality toolkits - but if I had to choose just one toolkit to use for the rest of my life, it'd be Qt, hands down.

    --
    "Good people drink good beer"
  11. Cygwin or UWIN by jdb2 · · Score: 4, Interesting

    If you want "close to the metal" POSIX API compatibility then there's Cygwin which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN which supports most of the POSIX spec.

    Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder* ;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.

    jdb2

    1. Re:Cygwin or UWIN by TheNetAvenger · · Score: 3, Informative

      If you want "close to the metal" POSIX API compatibility then there's Cygwin

      Ok, but this is borderline 1990s thinking or a bit insane...

      You would be better off telling the person to just use the SUA of NT and develop a full *nix OSS solution and ignore Win32. As this is effectively what you are getting with Cygwin, except the SUA of NT is a full BSD subsystem that DOES RUN AT METAL 'so to speak' and doesn't have all the horrible 'kludges' of Cygwin.

      I mean seriously, I think people forget that NT does a very good V5 and BSD Unix already, that is far beyond POSIX compliance and yes even beyond Cygwin crap.

      ----

      To give a good answer to the OP, it would help to know what they are doing a bit more, as just knowing if they ware writing GUI or non-GUI code makes a BIG difference in picking a common or easily portable library. Also performance, what kind of performance do they need? Depending on what they are doing I could recommended truly using the SUA or Java or *gasp* .NET via Mono or QT or a ton of other solutions that do work and work well. Hell they might be doing an application can should be shoved into something like Silverlight.

  12. Sorry, C variants aren't trendy... by CptNerd · · Score: 5, Funny

    Unfortunately all the trendy cool kids are using Java these days, and only web-based applications are worth working on if you want to keep up with the times. The days of small, simple client-server apps are over, old hat, out of date, archaic. Nowadays you need to implement a web application using AJAX, web services, Struts and Spring and Hibernate, and you have to do it using Agile methodology. If you aren't linking in at least 100 Java class libraries, you don't have a "real" application.

    C++? Too simple.

    --
    By the taping of my glasses, something geeky this way passes
    1. Re:Sorry, C variants aren't trendy... by JustNiz · · Score: 3, Funny

      >> It's got so much stuff munged into it that the spec contains literally hundreds of pages special-casing bad interactions between features, and it takes a gigantic effort just to determine the type of an expression.

      Yeah I'm so glad Java came along... oh wait...

  13. Re:C++ is so old school... by cbhacking · · Score: 3, Informative

    It's mostly because they aren't answering the OP's question, and aren't contributing any useful information to the discussion. Compare the posts above with the following:

    From what I've heard, one of the best cross-platform libraries for C++ is QT, (originally developed by Trolltech, now by Nokia). It's available either open source (LGPL) or commercially, and while best known for its UI toolkit also provides an extensive library of other functions. Wikipedia has a long list of things it has been used for, and other information.

    On the other hand, if you're not too wedded to C++ specifically, Java, C#, or Python might be good alternatives. Syntax-wise, C# and Java are extremely similar to C++, and all three have extensive libraries (built in) that provide the functionality you're looking for. They're also cross-platform (with C# you'd need to stick with stuff Mono can do, but that's still pretty extensive) and you don't even need to re-compile. Speed-wise, both Java and C# are nearly as fast as native code for most applications today, as are certain Python run-time environments. If you need explicit memory management for something, you can even do that with C# (although at that point it may be better to stick with C++).

    --
    There's no place I could be, since I've found Serenity...
  14. Boost and sqlite by rudedog · · Score: 3, Interesting

    For most cross-platform stuff, boost will do what you need. boost::thread will handle all of your threading needs.

    boost::filesystem for manipulating pathnames; boost::datetime for date and time operations; boost::format for typesafe printf style I/O.

    It also has boost::asio for sockets and boost::interprocess for IPC. I know nothing about them, but to judge from the quality of the rest of the boost library, they are probably very good.

    For database, use Sqlite. It's a solid relational database stored in a single file, and you can even access the database from the command line for ad-hoc queries/debugging/whatever.

  15. Apache Portable Runtime by Jester99 · · Score: 3, Informative

    You say that you're writing a lot of "C-like" embedded C++. Are you doing fully OOP style coding and using 'new' and 'delete'? Or are you mostly taking advantage of conveniences like namespaces, scoped variable declarations, etc?

    If your code is really more C-ish, you could take a look at the Apache Portable Runtime (http://apr.apache.org/). The APR is the library that Apache httpd is based on; they cover most system-level utilities (sockets, files, etc) you could need in a portable way. The APR is more 'C-like' in that a file descriptor is an opaque handle which you pass in to functions like apr_file_puts(), etc., rather than doing the C++ thing of file->puts()..

    But if you're ok with the syntax, it's Apache licensed (corporation friendly), well tested (httpd is pretty ubiquitous after all) and actively maintained.

  16. Re:C++ is so old school... by Profane+MuthaFucka · · Score: 5, Informative

    Yes, QT is really excellent, but it's worth it to look at Boost as well.

    Want a database? Why use Berkeley when there's SQLite?

    Portable sockets? QT and Boost both have them.

    Portable file ops? QT and Boost both have them.

    Data structures? QT has a bunch, but STL is what you should learn.

    Windowing lib? QT works on both Windows and Linux. You may be tempted to use WXWidgets, but don't. Despite the fan boyz, you'll find that library to be buggy as shit, and impossible to debug. Sorry, that'll probably get me marked as a troll, but it's true.

    And QT on Windows comes WITH the MinGW compiler for Windows package. You don't need to use any other tool than gcc on Linux, Mac, or Windows.

    --
    Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
  17. Java, Perl, and WxWidgets... by taoboy · · Score: 3, Insightful

    ...are ones with which I have the most experience. WxWidgets IMHO is the best 'close-to-the-metal' API, with the most available constructs to allow me to implement in C/C++ the Perl prototypes I develop. But most recently I've been noodling with Java to develop a high-availability platform, and I regularly run multiple jvms in Windows command shells to build stuff out, and then take the classes unchanged to a ttylinux-SunJRE-based cluster I run with VirtualBox.

    I'm not a Java advocate by any means, but you can't ignore the portability...