Hey Graeme,
2011/11/30 Graeme Gill <grae...@argyllcms.com>:
> 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
It think it's okay to do it -- it's just an additional copy operation.
> to implement void * in the back end, and then implement std::vector<>
> on top of it.
That would be possible too -- provided we can solve memory management
so that the backend remains responsible for the memory allocated for a
returned blob value of unknown size, or copies the blob into a
preallocated array in case the size is fixed. This will complicate
backend design a bit since he will need to keep track of returned
blobs until the statement is reset or the next row is fetched.
> const char *sql_value_traits<uchar32>
> ::type(SqlConnection *conn, int size)
Actually, you should be able to specialize this as:
template <std::size_t N>
struct sql_value_traits<(unsigned char &)[N], void> { ... }
Regardless of the rest of the discussion, this looks like the way to
go for the traits class !
Regards,
koen
------------------------------------------------------------------------------
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
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
