From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-03-23 22:36:20
Just as a prefix: I've been using Soci in a couple of projects now and I'm
> > [...] the leading candidate [...] is soci.
> I know about that. SOCI surely is a great library with high
> potential. However, there are two things, that I disagree with it:
> 1) overloads of operator<< and operator,
> It confuses me to use operator<< to get information _out_ of
Hmmm. Operator overloading is always a matter of taste. But as Spirit shows
'it grows on you over time' In this sense I think that this argument
shouldn't be sufficient to start a new library effort.
> 2) Runtime polymorphy
> I agree that is is important to switch easily between
> implementations, but usually you don't need this flexibility at
> runtime, do you?
That's one point which makes Soci compelling for me in my projects. I want
to decide at runtime what DB backend to use.
> I don't want to start a discussion about soci here. I just want to
> point out why I would prefer a different approach.
> > 3 months is a short time. I'd suggest you pick a smaller number of
> > backends if you're going to propose this. The design should support
> > expansion to the others, but my sense is that 5 backends in 3 months
> > isn't doable.
> Agreed. It is good to know what is doable in a fixed timeframe and
> what is not. Now I'm spoilt for choice...
> Thanks for your reply!
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk