On Sat, Mar 22, 2008 at 7:37 AM, Daniel Pfeifer <daniel@pfeifer-mail.de> wrote:
Hi Jeff,
[...] 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.
Ok, but I don't think SOCI does that. It uses operator<< on an SQL statement to bind variables -- the variables can be input or output depending on what you're doing.
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?
No, but I'm not clear that there's much of a disadvantage -- a few extra instructions is very likely to be totally overwelmed by the cost
I don't want to start a discussion about soci here. I just want to point out why I would prefer a different approach.
That's fair, but the discussion will come up. You need to have reasons, and you do, why you are going a different direction. As it stands, I haven't seen enough examples of your proposed interface to understand the contrast. In particular, I'd like to see how you are going to bind user defined types (eg: boost::posix_time::ptime), STL collections of objects -- or say a Boost.Multiindex collection of values, bulk operations, etc. Jeff