Koen Deforche wrote:
> Would it be acceptable (for your use-case) to implement the
> sql_value_traits<> specializations to convert between a std::vector<>
> and void * so that the back-end interface (SqlStatement *) is not
> affected ? Or is the extra copy something that would hurt performance
Hi Koen,
I guess it doesn't matter how it's implemented in the
back end - I started out explicitly using std::vector<> but
it was clumsy, and the idea of converting from a natively
fixed size block to a std::vector<> and back to a blob
again in the backend seems just as bad. Neater might be
to implement void * in the back end, and then implement std::vector<>
on top of it.
[ I'm was just trying to map things like unsigned char blob[32]
in a concise way. Maybe my C++ skills just aren't up to it,
but I end up with something like:
typedef unsigned char uchar32[32];
const char *sql_value_traits<uchar32>
::type(SqlConnection *conn, int size)
{
return conn->blobType();
}
void sql_value_traits<uchar32>
::bind(const uchar32 v, SqlStatement *statement, int column, int size)
{
statement->bind(column, (const void *)v, 32);
}
bool sql_value_traits<uchar32>
::read(uchar32 v, SqlStatement *statement, int column, int size)
{
return statement->getResult(column, (void *)v, 32);
}
]
cheers,
Graeme Gill.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
