пт, 15 нояб. 2024 г. в 15:58, Klemens Morgenstern :

Would you also suggest automatic conversions or just stick to sqlite::value ?

To be honest, I'm not sure. Automatic conversions would also have to rely on deduction, which would again inhibit the use of templates and overloaded functions.

I think you're right. I didn't really like the context idea in your previous code example, but I think this can be rectified: instead of a context object, you can pass in a tuple that gets forwarded to the constructor of the function. ... create_aggregate_function("my-prefix", 42);

First, I realised that there's no need to put any additional shared data into SQLite-managed memory, as you can always just add a reference member to the callable and store that shared data on your side. Second, I assume the point of this approach is to avoid copying the callable object, and also support non-default constructible callables. My approach uses the original callable as a kind of prototype, from which it copies new objects for every operation. To be honest, I don't think there should be any difference in performance between my approach with copying and yours with constructing. Ergonomically, I think mine is better. Yours may be looking more straightforward to users. One idea came to my mind. It's sometimes hard to determine which parts of the SQLite C API are supported by your library, and what specific components do it. So, I think you need a dedicated list of all SQLite C functions with comments like "supported via sqlite::backup", "supported via sqlite::mutex", "not supported because an analogous function X is supported ", "not supported because deprecated by SQLite", etc.