Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Windows Technology

Platform Independent C++ OS Library? 310

Posted by timothy from the one-to-rule-them-all dept.
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?"
This discussion has been archived. No new comments can be posted.

Platform Independent C++ OS Library? More

Platform Independent C++ OS Library?

Comments Filter:

  • JAVA (Score:3, Insightful)

    by Anonymous Coward on Sunday October 11, 2009 @03:23PM (#29712573)

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

    • Re:JAVA (Score:4, Interesting)

      by HiThere ( 15173 ) <charleshixsn@@@earthlink...net> on Sunday October 11, 2009 @04:25PM (#29712903)

      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.

      • One thing that appears to be a requirement is this must be a library for C++.

        • There are C->Java converters.
          But if you need interoperability and work on multiple platforms, there is nothing like Java.

          You can use JNI if you have to rely on C code, but virtually every library you could need has been programmed in Java.

          • Re: (Score:3, Insightful)

            by Jeremy Visser ( 1205626 )

            One thing that appears to be a requirement is this must be a library for C++.

            There are C->Java converters.

            Let's play spot-the-difference!

      • Ruby, Python, even some dialects of Basic would work.

        For emulating embedded hardware on Windows? This is clearly a new definition of the word "work" that I wasn't previously aware of.

  • Qt (Score:5, Insightful)

    by Anonymous Coward on Sunday October 11, 2009 @03:25PM (#29712587)

    Nokia QT rocks...

    • Re:Qt (Score:5, Informative)

      by KirstuNael ( 467915 ) on Sunday October 11, 2009 @03:35PM (#29712647)

      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.

      • Re: (Score:3, Interesting)

        by Doppler00 ( 534739 )

        Qt is okay for networking applications, but in my experience Boost has much, much better performance, not to mention better support for things like multicast without creating some hacks. Qt ends up using a lot of Qt specific classes internally to create buffers and network functions, so it ends up being slower than Boost which seems to act more as a wrapper than anything.

        • Re: (Score:3, Informative)

          by TemporalBeing ( 803363 )

          Qt is okay for networking applications, but in my experience Boost has much, much better performance, not to mention better support for things like multicast without creating some hacks. Qt ends up using a lot of Qt specific classes internally to create buffers and network functions, so it ends up being slower than Boost which seems to act more as a wrapper than anything.

          But does Boost provide behind the scenes threading?

          One of the things I've noticed with Qt is that they went out of their way to make the best possible performance. There's a lot of Qt classes (such as QTcpSocket) that implement threading behind the scenes so the performance is really hard to impact your application with (not impossible but a lot harder).

          Additionally, while there are a lot of things you do need to use the Qt classes for, it's typically very easy to convert many of those classes to and

    • Re:Qt (Score:4, Informative)

      by Anonymous Coward on Sunday October 11, 2009 @03:50PM (#29712735)

      Point for point:

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

    • Re: (Score:2, Informative)

      by morgan_greywolf ( 835522 )

      Or GTK. Or specifically, gtkmm. Recent builds of GTKmm and Glibmm include stuff for handling sockets (Gtk::Socket). threads (Gtk::Thread, Gtk::Mutex, etc.) and IPC (GTK::Plug). Don't forget the GIO stuff, too.

      • Re:Qt (Score:5, Interesting)

        by jmv ( 93421 ) on Sunday October 11, 2009 @04:30PM (#29712941) Homepage

        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.

        • > The only thing I found a bit annoying was that it didn't integrate well with the STL.

          Is there anything that does? Boost has some alternatives to STL classes, and I'm sure Qt has as well.

          STL has a nice API, but that's about it.

  • Boost? (Score:3, Informative)

    by piojo ( 995934 ) on Sunday October 11, 2009 @03:26PM (#29712595)

    I know Boost has threading support, but I'm not sure how much. Have you looked at that? (It also has a bunch of other useful libraries, perhaps Filesystem being pretty useful for cross-platform work.)

    • Re:Boost? (Score:5, Informative)

      by Homburg ( 213427 ) on Sunday October 11, 2009 @03:34PM (#29712645) Homepage

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

      • Boost ... is the basis for the threading capabilities in the forthcoming revision of the C++ standard.

        It's probably the other way around, see the Boost thread documentation [boost.org]. In any case, it's much easier than using pthreads' C API, and I think the feature set is approximately the same as pthreads.

  • many choices (Score:2, Interesting)

    by Anonymous Coward

    NSPR [mozilla.org], APR [apache.org], boost [boost.org] system, threads

  • Qt (Score:5, Informative)

    by Anonymous Coward on Sunday October 11, 2009 @03:27PM (#29712599)

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

    • Use Qt.

      Seconded.

      Note: you can also use just QtCore, without QtGui, if you don't need the gui parts.

    • Re: (Score:3, Informative)

      by Lord Kano ( 13027 )

      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

  • Pthreads (Score:3, Informative)

    by SoftwareArtist ( 1472499 ) on Sunday October 11, 2009 @03:30PM (#29712613)
    I've used Pthreads successfully as a cross-platform threading library. http://sourceware.org/pthreads-win32 [sourceware.org] 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).

    • Re: (Score:3, Interesting)

      by QuoteMstr ( 55051 )

      pthreads-win32 is excellent, but regrettably, LGPL licensed. It's interesting to note how complex it has to be to give you POSIX semantics [wustl.edu] --- pre-Vista win32 threading primitives are fundamentally flawed [msdn.com].

      Vista, on the other hand, gives us brand-new innovative 21st-century Microsoft technologies like condition variables [microsoft.com].

      • Re: (Score:2)

        by bcmm ( 768152 )

        pthreads-win32 is excellent, but regrettably, LGPL licensed.

        What is wrong with LGPL?

        • The license is more complex than the GPL. It's more difficult to understand and is easier to lead to ambiguity.

          For software developers writing closed source programs without access to a legal department, it can be daunting to determine if you have complied with the subtle LGPL requirements to keep your source closed.

          If you're developing GPL applications with LGPL libraries, you have nothing to worry about.

  • Qt or GLib (Score:3, Informative)

    by ciroknight ( 601098 ) on Sunday October 11, 2009 @03:32PM (#29712623)
    Qt's "Core" library is a pretty solid platform shim. Plain GLib is also (somewhat easier to port due to no C++ ABI differences, but no native C++ api makes it less attractive to you).

    Either one is an exceptional choice.

  • TBB works wonders for threading (Score:5, Interesting)

    by Wrath0fb0b ( 302444 ) on Sunday October 11, 2009 @03:32PM (#29712625)

    Intel Thread Building Blocks (http://www.threadingbuildingblocks.org/ [threadingb...blocks.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.

  • Boost (Score:5, Informative)

    by aePrime ( 469226 ) on Sunday October 11, 2009 @03:33PM (#29712633)

    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.

    • Re:Boost (Score:5, Informative)

      by mls ( 97121 ) on Sunday October 11, 2009 @03:51PM (#29712743)

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

      • You beat me to the suggestion.

        SQLite [sqlite.org] is a very powerful SQL database engine that is highly powerful and comes in a single < 500K library. No server needed.

        Interfaces to it exist for most modern languages.

        Documentation for the C/C++ API is here [sqlite.org]

        A more C++ friendly wrapper for SQLite is on CodeProject [codeproject.com]

  • I've had great experiences with ACE. I found ACE to be dependable and extensive. You don't even have to use the higher level design patterns to get the platform independence.

    If you're targeting *only* Windows and Linux, then Qt may also be a good option. I'm not sure if you can strip out the GUI stuff if you don't need it.

    • Re: (Score:3, Interesting)

      by mallan ( 37663 )

      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.

    • QT allows use of just the core libraries, so that's not a concern. Why do you talk about "only" targeting Windows or Linux, though? QT runs on OS X, WinCE, and other platforms as well. For example, if Skype runs on it, you can bet QT does too.

      • Skype is on PSP, is QT?

      • I've had the impression that ACE supports more exotic platforms, but your question prompted me to check what platforms Qt will run on-- how long has Qt supported VxWorks? I guess a lot has changed recently. I suppose an in-depth comparison of ACE and Qt is warranted. Still, I have enjoyed using ACE.

  • As someone working on a massive project... (Score:5, Informative)

    by QuoteMstr ( 55051 ) <dan.colascione@gmail.com> on Sunday October 11, 2009 @03:43PM (#29712689)
    I'm working on a rather large cross-platform C++ project at the moment. Here are a few tips:
    1. Use Boost [boost.org]. 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 [nongnu.org] 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.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

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

    • Re:As someone working on a massive project... (Score:5, Funny)

      by Anonymous Coward on Sunday October 11, 2009 @03:57PM (#29712765)

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

    • Re: (Score:3, Informative)

      by Pseudonym ( 62607 )

      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.

      Agreed, but you left out one crucial reason: If you use Boost today, this maximises your chances that your code won't need very much

  • Boost ( http://www.boost.org/ [boost.org] ) is good I also hear nice things about POCO http://pocoproject.org/ [pocoproject.org]

    • Re: (Score:2, Informative)

      by Profane MuthaFucka ( 574406 )

      No, POCO is not very good. The documentation is poor, and it's buggy.

      • Re: (Score:3, Informative)

        by gbjbaanb ( 229885 )

        agreed, I used POCO for its email classes, and while it worked its documentation was somewhat out of date or incomplete. Still, I could figure out what was needed. what I didn't like was their adherence to the 'one true OO way' of developing libraries, too much of an exception hierarchy just isn't good.

        I didn't try the other parts and am probably not likely to. If boost had some general purpose classes (instead of mostly algorithms and general purpose classes) then I wouldn't have even looked at Poco.

  • wxWidgets might work (Score:3, Informative)

    by Beached ( 52204 ) on Sunday October 11, 2009 @04:01PM (#29712785) Homepage

    wxWidgets (aka wxWindows) does windowing, sockets, thread. I am not sure about DB, but I think it does. I haven't used it for DB yet.

  • As others have said BOOST is good. Also, I really didn't care for ACE and eventually gave up on it.

  • http://www.nullsoft.com/free/jnetlib/ [nullsoft.com] From the guy who initially made Winamp, he also made a lib called JNetLib which is a piss easy to use cross-platform C++ socket library. It also has pre-made classes for things like HTTP/HTTPS, to help speed things up, or to simply give you an idea of how to use the library. It is licensed under the BSD license, so you are basically free to use it for whatever you would like, commercial or otherwise.

  • Cygwin or UWIN (Score:5, Interesting)

    by jdb2 ( 800046 ) * on Sunday October 11, 2009 @04:10PM (#29712831) Journal
    If you want "close to the metal" POSIX API compatibility then there's Cygwin [cygwin.com] which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN [att.com] which supports most of the POSIX spec.

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

    jdb2
    • Cygwin does terrible things with its DLL and explodes in certain evironments.

    • Cygwin is a huge pain. Yeah, it sort of gives you a POSIX environment, but good luck getting anything to actually compile under it without hours of frustration.

    • Re:Cygwin or UWIN (Score:4, Informative)

      by TheNetAvenger ( 624455 ) on Sunday October 11, 2009 @09:40PM (#29714779)

      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.

  • Zoolib at Source Force [sourceforge.net] under the MIT open source license. It has a flat file database format, exists for multiple platforms, has platform-independent thread and mutex classes, graphical user interface toolbox, thread-safe reference counted smart pointers, file access, TCP networking. You can ask the main developers Andy Green or Michael Crawford to port it to a new platform that isn't supported yet, but it supports all of the platforms listed on the source forge page.

    The Zoolib Cookbook can help you get started. [goingware.com]

    The flat file database support is designed in Zoolib so that you can email someone the database file and they can click on it and open it up as an email attachment.

  • Sorry, C variants aren't trendy... (Score:5, Funny)

    by CptNerd ( 455084 ) <adiseker@lexonia.net> on Sunday October 11, 2009 @04:13PM (#29712849) Homepage
    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.

    • I'd give anything for mod points right now. :)

    • Re: (Score:2, Interesting)

      by Trepidity ( 597 )

      C++ has a lot of properties, but "simple" is hardly one of them. 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. Parsing C++ is actually not only not context-free, but undecidable, in general. It takes a heroic effort to determine whether A f(B,C); is a function declaration, or a call to a constructor. Static resolution rules are horrifically

      • Re:Sorry, C variants aren't trendy... (Score:4, Funny)

        by JustNiz ( 692889 ) on Sunday October 11, 2009 @06:10PM (#29713671)

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

      • GP was being sarcastic?

        And maybe a little (more than a little?) critical of AJAX, et. al.?

        Maybe?

      • Re: (Score:3, Interesting)

        by cerberusss ( 660701 )

        C++ has a lot of properties, but "simple" is hardly one of them.

        We use Qt at my job for creating servers, daemons, interacting with hardware as well as doing GUI stuff. You don't really need to use the fancy C++ stuff, it's OK to just use the Qt classes and be done with it. Our code almost looks like Java, so simple.

  • Yu left out one #ifdef (Score:3, Insightful)

    by tomhudson ( 43916 ) <barbara.hudson@b ... m ['son' in gap]> on Sunday October 11, 2009 @04:14PM (#29712853) Journal

    #ifdef __BSD__

    BSD and linux are different in some aspects when it comes to sockets. Made it a real PITA to code on linux, runs perfectly, then won't compile on BSD without a few more includes and some extra code.

  • Just use POSIX (Score:2, Insightful)

    by Anonymous Coward

    That handles all the things you mentioned, and you can compile pretty much all the same code natively on Linux or using Cygwin on Windows without having to bother with #ifdeffery at all.

  • Boost and sqlite (Score:4, Interesting)

    by rudedog ( 7339 ) <{dave} {at} {rudedog.org}> on Sunday October 11, 2009 @04:35PM (#29712963) Homepage

    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.

  • Apache Portable Runtime (Score:4, Informative)

    by Jester99 ( 23135 ) on Sunday October 11, 2009 @04:37PM (#29712985) Homepage

    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.

  • SQLite for database (Score:3, Interesting)

    by PizzaFace ( 593587 ) on Sunday October 11, 2009 @04:50PM (#29713061)
    SQLite [sqlite.org] dominates discussions of embedded databases these days, but Berkeley DB [oracle.com] still has fans who don't need SQL. There are a lot of comparisons on the web.
  • *ducks*
  • Duh, Qt!

  • Another couple of options (Score:3, Interesting)

    by EvilIdler ( 21087 ) on Sunday October 11, 2009 @05:50PM (#29713513)

    There's always wxWidgets, which you can compile into your program if you feel like it. Quite liberal.
    It's not a mere library, but a full framework, like Qt. I find the wx runtime to be smaller than an equivalent Qt program most of the time, and the Mac version of Qt's dylib bundler sometimes makes some stupid decisions which bloat the app by 50MB. wxWidgets (statically linked) gives me a 1.7MB executable for a Hello World-ish program.

  • The Java repliers are right on the mark. Trying to use app-independent portability layers ensures apps of any complexity will suck. By "suck", I mean "compromised at every turn by lowest-common denominator design decisions". Your app will end up using threads on an O/S designed to make multi-processing beautiful (Linux), or end up using multiple processes on an O/S designed to make multi-threading beautiful (Windows). It'll be clueless about the nifty GUI features that exist on a Mac but not Windows, and vi

  • Java, Perl, and WxWidgets... (Score:3, Insightful)

    by taoboy ( 118003 ) on Sunday October 11, 2009 @06:50PM (#29713933)

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

  • dito.

  • And a rock solid but simple embedded database to emulate flash memory.

    This part I don't understand... flash is a hardware solution to persistant storage. An embedded database is a software solution to structured storage of data. The two are completely orthogonal.

    Ignoring the flash part, I have used sqlite on several embedded projects (set top boxes) and it has done the job. Depends on your requirements though - is the priority speed, space, ease of use/API, etc?

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close