-2

I am doing some work using generic C++ on Ubuntu using open source tools. I am on 12.04 LTS - default compiler does not support the C++ 11 standard. (Eventually I will upgrade, but not now)

I'm using GTK+/GTKMM for my GUI work but I need database support and I don't know where to turn - of course there is no database support in native C++.

My databases of choice are SQLite and PostgreSQL. I know Qt has good database support, but I want to avoid using Qt for several reasons (In particular, I don't want to bind everything to the large, specialized, quasi-proprietary Qt framework).

What generic open source libraries are out there that provide support for the database access I need? (I don't really want to write my own database layer...).

Cole Tobin
  • 9,206
  • 15
  • 49
  • 74
Vector
  • 10,879
  • 12
  • 61
  • 101
  • Both databases have at least C interface libraries that allow you to talk to the database. Is there any specific reason you can't just put a thin abstraction layer over the libraries and use that? – Timo Geusch Aug 03 '13 at 20:42
  • @TimoGeusch - no specific reason at all. Will have to look into it. Post it as an answer. – Vector Aug 03 '13 at 20:43
  • @Vector: your question is actually very interesting. You can use [libdbi](http://libdbi.sourceforge.net/) which supports your drivers (sqlite and pgsql), but unfortunately it does not have support for prepared statements – mvp Aug 03 '13 at 21:25
  • @mvp - there are 3 votes to close, so I guess not everyone finds it interesting. But libdbi looks like maybe the perfect solution for me. Post it as an answer (before the question is closed... :-)) – Vector Aug 03 '13 at 22:03
  • 1
    This is very good question which does not have perfect answer. It would be nice to have universal versatile database library for C/C++, but there is none at the moment, thus there is no possibility to attract opinionated answers. – mvp Aug 04 '13 at 18:08

1 Answers1

2

You can use libdbi which supports your drivers (sqlite and pgsql, there is also support for mysql, freetds(mssql), oracle, db2, etc).

Unfortunately, there is one catch: libdbi does not have support for prepared statements :(

mvp
  • 111,019
  • 13
  • 122
  • 148
  • Prepared statements is not a priority for me right now. Small datasets, simple queries - mostly I just need SQLite for the moment for local, structured persistence. I have some other things in mind for PostgreSQL, but again not large datasets and complex queries where prepared statements might be so important. – Vector Aug 03 '13 at 22:33
  • Wow, seriously? That makes it totally unacceptable for any real world use to me, not for performance reasons but because parameterized statements are vital for security. This question: http://stackoverflow.com/q/11267397/398670 suggests that SOCI might be a better option but I have no experience with that. – Craig Ringer Aug 04 '13 at 11:25
  • @CraigRinger - are you confusing **parameterized** with **prepared**? Two entirely different things: Prepared statements means that they are pre-compiled on the server so that they don't have to be generated on the fly on the server side each time they are executed. Parameterized statements are more secure because you don't have to pass the entire SQL statement into the server - just a name and the parameters. Parametrized statements don't have to be prepared AFAIK, nor do prepared statements necessitate parameters. – Vector Aug 04 '13 at 20:26
  • @Vector I should've made that distinction more clear. I don't care (much) if it supports prepared statements so long as parameterized statements are supported. I tend to assume that most people incorrectly equate parameterized with prepared, though, so if someone says "no prepared statements" that usually means "doesn't have any support for taking parameters and placeholders in SQL execution". I think this error probably came from PHP and from Java, both of which offer no user-visible way to get parameterized stmts w/o preparing them. – Craig Ringer Aug 05 '13 at 01:46
  • @Vector So ... if it supports parameterized statements (in Pg, that'd mean using the extended query protocol with placement parameters) then it doesn't matter much if it knows how to do prepared statements. You can always do that yourself at the SQL level with `PREPARE` and `EXECUTE`. – Craig Ringer Aug 05 '13 at 01:47
  • @CraigRinger : " I think this error probably came from PHP and from Java" - I have not worked in either of those languages, so I don't suffer from this confusion. :-). "So.." Agreed - it's not much of an issue - that's generally how you use prepare anyhow - I never quite understood why someone would want to call prepare everytime they run something. – Vector Aug 05 '13 at 01:56