Daniel, Just as a prefix: I've been using Soci in a couple of projects now and I'm very satisfied.
[...] 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 something.
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. Regards Hartmut
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!
Daniel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost